If you’ve tried to add “swap from Ethereum to Solana” or “move USDC from Arbitrum to Base” to an app, you already know the feeling. The on-chain part of your project took a weekend. The cross-chain part takes a month, and half of that month is reading documentation for SDKs that changed since the last time someone wrote a tutorial about them.
This post is a practical map of the options. It covers what actually happens when tokens “move” between chains, the three broad ways to integrate that into an app, a working example using an aggregator API, and the security questions that matter more than any feature list. There’s no single right answer, but there are definitely wrong ones, and some of them have cost projects hundreds of millions of dollars.
Tokens don’t really move between chains
It helps to be precise about what a “bridge” does, because it changes how you think about risk. Blockchains can’t read each other’s state. When you “send” USDC from Ethereum to Polygon, one of a few things happens:
- Lock and mint: tokens are locked in a contract on the source chain and a wrapped version is minted on the destination. The wrapped token is only worth something as long as the locked collateral is safe.
- Burn and mint: the issuer burns tokens on one chain and mints native ones on the other. Circle’s Cross-Chain Transfer Protocol (CCTP) works this way for USDC, which is why native USDC transfers avoid wrapped-token risk.
- Liquidity networks: the protocol keeps pools of the token on both chains. You deposit on one side, and a relayer or solver pays you out from the pool on the other side, then gets reimbursed.
In every case, something off-chain has to observe an event on chain A and act on chain B. That “something” might be a set of validators, an oracle network, a light client or a market of competing solvers. Whoever or whatever it is, it’s the part you’re trusting.
Why bridges are where the money gets stolen
Bridge contracts tend to hold large pools of locked value, and their security depends on verification logic that’s hard to get right. That combination has made them some of the biggest targets in crypto:
- Ronin (March 2022): about $625 million lost after attackers gained control of enough validator keys to approve fake withdrawals.
- Wormhole (February 2022): roughly $325 million, from a signature verification flaw that let an attacker mint wrapped ETH without depositing any.
- Nomad (August 2022): around $190 million, after an upgrade left a message check effectively disabled and hundreds of copycat wallets drained it.
The lesson for app developers isn’t “never use bridges”. It’s that the bridge you pick is a security decision, not a UX detail. When your users’ funds pass through someone else’s contracts, you inherit that risk even if your own code is perfect.
Three ways to add cross-chain transfers to your app
Option 1: Integrate each bridge or messaging protocol directly
You can talk directly to a specific protocol: CCTP for USDC, Chainlink CCIP, Wormhole, LayerZero, Axelar, or a chain’s canonical bridge. This gives you the most control. You know exactly which contracts are involved, which assumptions you’re trusting, and how messages are verified.
The cost is maintenance. Each protocol has its own SDK, its own way of tracking a transfer’s status, and its own list of supported chains and tokens. If you need five routes, you may end up with five integrations, and every chain upgrade becomes your problem.
This route makes sense when you have a narrow need (say, only USDC between three chains) or when you’re building infrastructure that other people rely on and need to own the trust model.
Option 2: Use a bridge and DEX aggregator API
Aggregators such as LI.FI, Socket/Bungee and Squid sit on top of many bridges and DEXs. You ask for a quote (“100 USDC on Arbitrum to ETH on Base”), and they return a route, an estimated output, fees and a ready-to-sign transaction. Some also offer widgets you can drop into a front end.
The trade-off is that you’re adding another party to the trust chain. The aggregator picks the route, so you need to understand which bridges it might use and whether you can restrict them. You also depend on its uptime and API stability.
For most apps that want broad coverage without a dedicated infrastructure team, this is the pragmatic choice.
Option 3: Intent-based swaps
A newer model flips the flow. Instead of choosing a route, the user signs an “intent” (I want at least X of token B on chain 2 in exchange for Y of token A on chain 1), and professional solvers compete to fill it. 1inch Fusion+ and Across are examples of this approach. The user often gets better execution and doesn’t need gas on the destination chain.
The catch is that it depends on a healthy solver market for the pairs you care about. For long-tail tokens or less popular chains, there may simply be nobody willing to fill the order at a fair price.
A working example: getting a quote from an aggregator
Here’s what option 2 looks like in practice, using LI.FI’s public quote endpoint. The request asks how to move 10 USDC from Arbitrum to Base. Amounts are in the token’s smallest unit, so 10 USDC with 6 decimals is 10000000.
const params = new URLSearchParams({
fromChain: "ARB",
toChain: "BAS",
fromToken: "USDC",
toToken: "USDC",
fromAmount: "10000000",
fromAddress: "0xYourWalletAddress"
});
const res = await fetch(`https://li.quest/v1/quote?${params}`);
const quote = await res.json();
console.log("Route via:", quote.tool);
console.log("Expected out:", quote.estimate.toAmount);
console.log("Minimum out:", quote.estimate.toAmountMin);
// quote.transactionRequest is ready to pass to a wallet, e.g. with ethers:
// const tx = await signer.sendTransaction(quote.transactionRequest);A few things to notice. The response tells you which underlying tool was chosen, so log it: when something goes wrong, you’ll want to know which bridge handled the transfer. toAmountMin is the amount after maximum slippage, and that’s the number to show users, not the optimistic estimate. And for ERC-20 tokens the user usually needs to approve the spender contract before the transfer transaction will succeed, so handle the approval step in your UI.
Always check the provider’s current docs before shipping. Chain keys, parameter names and rate limits change, and the LI.FI documentation is the source of truth, not this post.
Questions to ask before you pick a route
Whether you integrate directly or through an aggregator, run through this list:
- What verifies the message? A multisig of validators, an oracle network, a light client or an optimistic scheme with a challenge window? Each has different failure modes.
- Is the token native or wrapped on the destination? Wrapped tokens carry the bridge’s risk forever. Native issuance, like CCTP for USDC, avoids that.
- What happens if a transfer gets stuck? Is there a refund path, and does your app show users how to use it? Stuck transfers are the most common support ticket in cross-chain apps.
- Can you restrict routes? Good aggregators let you allow or deny specific bridges. Use that to keep users away from routes you haven’t reviewed.
- Has it been audited, and has it been exploited? A past exploit isn’t automatically disqualifying, but how the team responded tells you a lot.
- How will you track status? Build a status view from day one. Users will ask “where’s my money?” within minutes of a slow transfer.
Build vs buy, honestly
There’s a purist argument for going direct: fewer intermediaries, a clearer trust model and no dependence on a third-party API. It’s a fair argument, and for protocols and infrastructure it’s usually the right call.
For a product team whose value is somewhere else, like a wallet, a game or a payments app, spending months maintaining a dozen bridge integrations is hard to justify. An aggregator gets you coverage quickly, and you can always move a high-volume route to a direct integration later, once you know which routes your users actually use.
Whichever way you go, write down which contracts and trust assumptions your users are exposed to. If you can’t explain that in a paragraph, you’re not ready to put real money through it.
Disclosure: this post isn’t sponsored, and none of the projects mentioned paid for inclusion.
