The funding problem every crypto banking app hits Every self-custodial banking app faces the same drop-off. A user arrives ready to spend, save, or trade, and hits the hardest step first: get
Every self-custodial banking app faces the same drop-off. A user arrives ready to spend, save, or trade, and hits the hardest step first: getting money into the account at all. For COCA, that friction showed up twice over — once on the funding side, where stablecoins on one chain had no simple path into a COCA balance living on another, and once on the trading side, where getting $COCA meant more than just tapping "buy."
COCA's first attempt at in-app $COCA trading ran on a decentralized exchange pool rather than Aurora Intents — and it didn't hold up in production.
"One of our early interactions was built on top of an Aerodrome pool, and it wasn't working great. The problem was slippage; you're not getting the amount you expect, or the price impact is significant enough that you could pay twice what you should. To get a good price on a DEX, you need very high liquidity, and that grows organically over time. But our users need $COCA right now, today. That's why buy and sell $COCA was one of the things where we took a serious look at the intents infrastructure Aurora's been building." — Vasili Paulau, CEO, COCA
That's the real story: not a generic desire for "less friction," but a specific, failed first attempt that made the case for intent-based execution over routing-based DeFi.
On the deposit side, the problem was more familiar: identifying the correct network, bridging manually, and hoping nothing landed on the wrong chain. COCA wanted both problems solved the same way — make funding and trading feel like using a balance you already have, not navigating infrastructure.
The conceptual shift is the move from routing to intents. A DEX pool asks the user to accept whatever price and slippage the available liquidity gives them at that moment. An intent-based model inverts that: the user states what they want, and a network of solvers competes to deliver it — on cost, speed, and finality, not just whichever pool happens to be deepest. This is NEAR Intents.
"Your intention is that you'd like USDC on Coca to the tune of a thousand dollars, and you're going to pay for it with Solana. That gets broadcast to the solver network, which competes to be the one that secures that deposit for you. That competition isn't just about cost. It's also about speed, finality, and slippage." — Declan Hannon, CEO, Aurora Labs
COCA integrated two parts of Aurora Intents:
The first concrete expansion this unlocked was Tron support for USDT deposits — a network heavily requested by users outside the EU who rely on USDT day to day.
Deposit Addresses are a deposit primitive built on NEAR Intents:
[visual: a simple 4-step flow diagram here would break up this section nicely]
If something goes wrong, the deposit retries until it succeeds. If a system-level error occurs, funds are refunded.
"There isn't an instance here where the user is going to lose money. They are protected and they are safeguarded." — Declan Hannon, CEO, Aurora Labs
Settlement speed, tested live. Rather than quote a general benchmark, Aurora's own CEO tested the flow himself — topping up his COCA balance from another chain while standing in a checkout line.
"I actually tested this myself and was very pleased to see that it settled instantly or near instantly... I was in the queue, realized I hadn't topped up my card, and was literally able to do it. It was deposited and available for me to spend on my Coca card within about ten, fifteen seconds all in." — Declan Hannon, CEO, Aurora Labs
Aurora Intents funds the deposit into a user's COCA balance; it isn't involved in processing card payments. The card is COCA's own payment rail — Aurora is the means of getting money into the account in the first place, the same way a bank transfer moves funds between two accounts before a debit card is ever swiped.
End-to-end implementation usually takes a week or a few weeks, thanks to the API, monitoring tools, and dashboard provided to the integrator.
This isn't a standalone feature — $COCA is the mechanism behind COCA's tier system. Users buy and lock $COCA to unlock perks: subscription cashback (ChatGPT, Claude, Spotify, YouTube Premium), and cashback on card spend that scales up to 8% at the top "Elite" tier. Locking isn't spending — users can withdraw from a tier and get their $COCA back, along with any cashback earned along the way.
Before this integration, acquiring enough $COCA to move up a tier meant a trip to an external exchange. Vasili called this out directly as friction between a user's intent to upgrade and COCA's own loyalty mechanics — the thing driving retention was gated behind the thing causing drop-off.
COCA's stablecoin deposit support now spans:
All routed through Aurora Intents behind a single reusable address per user, per network. In-app $COCA trading shipped alongside it — users buy or sell $COCA directly against their USD balance, a shortcut around the old routine of buying on an external exchange and manually moving tokens back into the app.
None of that registers to users as infrastructure — and that's the point.
"They want their money to arrive safely and be ready to use." — Declan Hannon, CEO, Aurora Labs
Tron support for USDT is one of the clearest examples: heavily requested by users outside the EU who rely on USDT day to day, now live without anyone needing to think about bridging.
The next phase pushes past stablecoins entirely — Bitcoin, Ethereum, and other major assets are planned for both deposits and withdrawals, still routed through Aurora Intents. COCA is also testing early, AI-driven "agentic" payments internally, cautiously gated until user-confirmation steps are solid enough that funds can never move without explicit consent.
One address. Any deposit. No expiry. For COCA and Aurora, that's the point.
Building cross-chain? Check out Aurora Intents: https://intents.aurora.dev/?utm_source=cmc&utm_medium=article&utm_campaign=coca_case_study
$AURORA
