Go to any DEX on Arbitrum and search for USDC. You'll find at least two: USDC and USDC.e. Same dollar. Same peg. Different contracts.
Now try to swap USDC.e for something. You might get a worse price than if you had native USDC, because the liquidity pool for USDC.e is thinner. Or the router sends you through an extra hop (USDC.e → USDC → your target token) and you eat the slippage twice.
This is liquidity fragmentation. And it costs more than most people realize.
The Problem: One Dollar, Five Tokens
When multiple bridges connect the same token to a chain, each bridge creates its own wrapped version. On Arbitrum alone, you've had USDC.e (Arbitrum's canonical bridge), and native USDC (issued by Circle). On other chains, you might see bridged versions from Wormhole, Multichain (before it collapsed), Synapse, and others, each with a different contract address.
They're all supposed to be worth $1. But DeFi doesn't care about your intentions. It cares about contract addresses.
Each version needs its own liquidity pool. Each pool competes for the same TVL. The result:
- Thinner pools everywhere. Instead of $100M in one USDC pool, you get $60M in USDC and $40M split across USDC.e, USDC.wh, and others.
- Worse prices for users. Thinner pools mean more slippage on larger trades.
- More complex routing. DEX aggregators have to route through multiple hops, each one adding gas costs and slippage.
- Arbitrage overhead. Someone has to keep these versions at parity. That's capital being deployed just to maintain a peg between tokens that represent the same thing.
What This Looks Like in Practice
Say you're building a lending protocol on an L2. You need to decide which USDC to accept as collateral. Native USDC? USDC.e? Both?
If you accept both, your collateral pool has two tokens and you need oracle prices for each. If you only accept one, users holding the other version have to swap first. Friction, gas, maybe slippage.
Now multiply this by every protocol on the chain. Every DEX, lending market, yield vault, and payment app makes the same decision. The ecosystem ends up with a patchwork of liquidity that doesn't compose cleanly.
I've seen this firsthand. Integrating with protocols that only accept native USDC means users bridging through the canonical bridge have an extra step. Some don't realize USDC.e isn't "the" USDC. Support tickets follow.
How Burn & Mint Fixes This
The fundamental fix is simple: if there's only one version of the token on each chain, fragmentation disappears.
That's exactly what CCTP does for USDC. When you transfer USDC from Ethereum to Arbitrum via CCTP, you get native USDC on Arbitrum. The same contract that Circle deployed. Not a wrapped version.
Lock & Mint world:
Ethereum USDC ──bridge A──► Chain X: USDC.e
Ethereum USDC ──bridge B──► Chain X: USDC.b
Ethereum USDC ──bridge C──► Chain X: USDC.c
Result: 3 pools, fragmented liquidity
Burn & Mint world:
Ethereum USDC ──CCTP──► Chain X: USDC (native)
Result: 1 pool, unified liquidity
Every protocol on Chain X integrates with one USDC contract. One liquidity pool. One oracle feed. Users don't have to think about which version they're holding.
USDT0 does the same thing for USDT through the OFT model. Wherever USDT0 is deployed, it's the canonical version. There's no USDT.e competing for liquidity. Just USDT0. If you bridge from Arbitrum to Optimism, you burn USDT0 on Arbitrum and mint USDT0 on Optimism. Same token, same contract standard, unified liquidity on every chain.
The Costs You Don't See
Fragmentation has costs that don't show up on a balance sheet but erode the system:
Capital inefficiency. Liquidity providers have to spread capital across multiple versions of the same token. This means each pool is shallower, which means worse execution for traders, which means LPs earn less. A negative feedback loop.
Integration burden. Every protocol team has to decide which token versions to support. Every version they add is another contract to audit, another oracle to configure, another edge case to handle. This is real engineering time spent on a problem that shouldn't exist.
User confusion. Most users don't understand why their USDC.e can't be deposited into a vault that says "USDC." They see the dollar sign, they see the peg, and they expect it to work. When it doesn't, the experience feels broken.
Arbitrage as a tax. Keeping wrapped versions at peg requires arbitrageurs. Their profit comes from price discrepancies, which means someone else is getting a worse price. The tighter the peg needs to be, the more capital is tied up in this unproductive work.
It's Not Fully Solved
Burn & mint models reduce fragmentation significantly, but they don't eliminate all the complexity.
CCTP only works for USDC. If you need to move ETH, WBTC, or any other token, you're still using lock & mint bridges and dealing with wrapped versions. The fragmentation problem is solved for one token, not the ecosystem.
USDT0 solves it for USDT but requires chains to adopt the OFT-based version. Chains that already have USDT through other bridges may end up with both USDT and USDT0 coexisting, which is its own kind of fragmentation.
And both models introduce different centralization trade-offs. CCTP centralizes control with Circle. USDT0 centralizes with Tether and depends on LayerZero's infrastructure. Whether that's better or worse than fragmentation depends on what you value.
My Take
Fragmentation is a hidden tax on the entire cross-chain ecosystem. It makes everything slightly worse (prices, UX, developer experience, capital efficiency) in ways that are easy to overlook because no single instance looks catastrophic.
Burn & mint models are a real improvement. Having one canonical token per chain is strictly better than having five wrapped versions competing for liquidity. But it comes with centralization costs, and it only works when the issuer is willing and able to operate the burn & mint infrastructure.
For now, the practical advice is: if you're building on a chain where both USDC.e and native USDC exist, default to native USDC. Encourage users to bridge via CCTP. Minimize your exposure to wrapped versions when you can. The fewer token versions in your system, the simpler everything becomes.
Top comments (0)