Stablecoin Swap API: USDC and USDT

When a product team says "we need a stablecoin swap API that supports USDC and USDT," they usually mean something simple: let a user send dollars on one chain and receive dollars on another, with the two tickers interchangeable. That sentence hides the hardest problem in stablecoin infrastructure. USDC and USDT are not single assets — they are families of tokens, each with multiple crosschain standards, multiple chain-specific implementations, and multiple liquidity venues that disagree about price. This guide reframes the problem as an interoperability problem and gives you a scoring framework for evaluating any USDC/USDT swap API against the three matrices that decide real coverage: standards, chains, and liquidity.

Stop asking "does this API support USDC and USDT." Start asking "which USDC, which USDT, which chains, and against which liquidity."

USDC is issued by Circle. USDT is issued by Tether. Both exist on many chains. That is where the simplicity ends. Each chain where these stablecoins exist may use a different token standard (ERC-20 on EVM chains, SPL on Solana, FA on Aptos, Sui object format on Sui). Each crosschain movement may use a different protocol (Circle's CCTP for native USDC, LayerZero's OFT for USDT0, Hyperlane warp routes for several emerging deployments). And within a single chain, the same nominal dollar can exist as two or three variants with different contract addresses and different liquidity depths.

A concrete example. If a user holds "USDC on Polygon," they might hold native Polygon USDC (issued directly by Circle, bridged via CCTP), bridged USDC.e (the older PoS-bridged variant with a liquidity premium), or USDC held inside a third-party bridge's wrapped representation. The three are not fungible onchain. A swap API that quotes "USDC → USDT" has to first decide which USDC it is reading from and which USDT it is delivering. The difference between USDC and USDC.e is not cosmetic — the two tokens can trade at slightly different prices inside the same chain's DEX pools.

So the evaluation question is not "support yes/no." It is a coverage score across three matrices.

Any honest review of a stablecoin swap API has to walk three matrices. Skipping one is how teams buy infrastructure that does not cover their users.

A "crosschain USDC swap" can run on any of several protocols, and each API picks a subset:

No swap API covers all of these. What you need to know is which subset the API uses for each corridor — and whether it can fall back to another standard when the primary is unavailable. A robust swap API should route "USDC on Arbitrum → USDC on Solana" via CCTP v2 (the cheapest, issuer-native path), while routing "USDT on BNB → USDT on Tron" via USDT0 or a liquidity bridge. Wrong choice means either slower settlement or unnecessary slippage.

USDC on Ethereum is an ERC-20 token at address 0xA0b8…eB48. USDC on Solana is an SPL token at EPjFW…tTDt1v. USDC on Base is a different ERC-20 contract from USDC on Ethereum. These are the same brand issued against the same dollar reserves, but at the protocol level they are different objects. A swap API must speak every token standard its chains require — ERC-20, SPL, FA, Sui object, TON jetton — and must know the canonical contract address for each variant on each chain.

The chain matrix is where "supported" gets slippery. Many APIs claim "15 chains supported" and then turn out to cover the EVM 12 plus Solana and Tron. That leaves out Aptos, Sui, TON, Hyperliquid, and an expanding list of non-EVM destinations where stablecoin volume is growing. The Aptos native USDC announcement is a useful marker for how quickly the matrix changes — a chain without native USDC one quarter can have first-class Circle support the next.

For each chain you care about, ask three questions: Is the chain supported at all? Which USDC variant (native, bridged) is the default read? Which crosschain standard is used to leave the chain? Any API that cannot answer those three cleanly is selling coverage that will break at integration time.

Even inside a chain where the API "supports USDC and USDT," the execution quality depends on which liquidity pool the swap hits. On an EVM chain with both USDC.e and native USDC, the two sit in separate Uniswap and Curve pools. Trading native USDC against USDT on one venue can give a different price than trading USDC.e against USDT on another. This is a price discovery problem, not an infrastructure problem — but it shows up as a number on the user's confirmation screen, so it looks like an API problem.

The Across analysis of stablecoin bridge fragmentation is one of the clearer third-party treatments of why this happens. Native and bridged variants split order book depth; prices drift apart during volatile windows; and automated market makers cannot rebalance across the variant gap without a swap layer sitting on top. A stablecoin swap API that only executes against one variant in a chain with three will fail silently for users holding the other two.

Serious APIs score well on the liquidity matrix by doing three things: reading balances across all variants on a given chain, routing each swap against the deepest venue for the exact pair, and surfacing slippage honestly when a variant is thin. Treating every "USDC" equally is the giveaway that an API has outsourced the liquidity problem rather than solved it.

Here is a scoring framework you can run against any USDC/USDT swap API in a 30-minute review. Each matrix is worth 10 points. An API that scores under 20 is a marketing page; an API that scores over 25 is worth a pilot.

Most APIs score well on one matrix and poorly on the others. A bridge-native API scores well on standards and chains, badly on liquidity because it only routes through its own pools. A DEX aggregator scores well on liquidity, poorly on chains, because it lives inside a single chain. A solver-based intent API can score well on all three if it treats standards, chains, and liquidity as routing inputs rather than hardcoded assumptions. That architecture is what Eco Routes is built on.

Eco's stablecoin index lists seven dollar-pegged variants used across the network it routes against: USDC, USDT, USDC.e, oUSDT, USDT0, USDbC, USDG. Seven tickers, all nominally worth a dollar, none automatically fungible at the contract level. USDbC is Base's pre-native bridged USDC, USDG is Paxos-issued, oUSDT is an OpenUSDT effort aimed at crosschain interchangeability, USDT0 is the LayerZero-native USDT. Each exists because some piece of infrastructure did not exist when the chain launched. The swap API's job is to hide that history, not pretend it never happened. For a deeper breakdown of how these variants coexist, the multi-stablecoin fungibility explainer covers the ledger mechanics, and the digital dollars primer frames how this generalizes beyond USDC and USDT.

A short field guide to the three protocols that show up in most swap-API routing decisions:

CCTP v2 burns USDC on the source chain and mints it on the destination. There is no intermediate wrapped token, no bridge contract holding inventory, and no third-party liquidity. Settlement happens in seconds for fast-path transfers with attestation speedups. See Circle's CCTP v2 developer docs for the exact mechanics. The tradeoff: CCTP only moves USDC, only between Circle-supported chains, and only via Circle's own attestation service. If Circle does not support a chain yet, CCTP does not help.

Tether partnered with Everdawn Labs to launch USDT0 on LayerZero's OFT standard in early 2025. Native USDT is locked on one chain; USDT0 is minted on destination chains via cross-chain messaging. This is fundamentally a lock-and-mint design sitting on LayerZero's messaging layer, described in LayerZero's stablecoin future post. It handles the chains CCTP does not and gives USDT the same "native crosschain" experience USDC has. The tradeoff: trust shifts from Circle to Tether plus Everdawn plus LayerZero's verifier set.

Chainlink's Cross-Chain Interoperability Protocol is a neutral messaging layer that can carry USDC and USDT alongside arbitrary tokens. Documented in the Chainlink CCIP documentation. Several institutional integrations use CCIP because the verifier set and risk management are spelled out in detail. CCIP is more general-purpose than CCTP or USDT0 and is often used as a fallback or for regulated flows.

A swap API that hardcodes one protocol is locking itself out of the other two. An intent-based API that treats each protocol as a routing option can pick the best one per corridor. Both CCTP and LayerZero are provers Eco Routes integrates with. Eco orchestrates across them rather than competing with either, so the design choice is which prover to target per route.

The three matrices interact. A user wants "USDC on Ethereum → USDT on Solana." The API has to decide: route USDC Ethereum → USDC Solana via CCTP then swap USDC → USDT inside Solana via a DEX? Or route USDC Ethereum → USDT Ethereum via a DEX then bridge USDT Ethereum → USDT Solana via USDT0? Different fees, different settlement times, different slippage profiles, different failure modes. Picking the right one needs live pricing and live liquidity data.

The intent-based architecture hides this behind one request. The caller signs "send 10,000 USDC from Ethereum, receive at least 9,990 USDT on Solana." Solvers — independent market makers staked into the protocol — compete to fill the intent by choosing whichever combination of standards, chains, and liquidity venues gives the best total price. The user sees one quote and one settlement. The Solver eats the routing complexity.

This is the approach Eco Routes takes. If you want to abstract the standards/chains/liquidity matrix behind one API, the Routes quickstart is where integration starts. Routes exposes a CLI for local testing and a REST API for production, running across fifteen chains with the seven stablecoin variants treated as native inputs and outputs. It is not a bridge and there are no "Fillers" — onchain execution is coordinated by Solvers.

Stablecoins are supposed to trade at a dollar. They usually do. They sometimes do not. When a bridged variant loses liquidity on a specific chain, its price drifts — USDC.e trading at $0.9985 while native USDC on the same chain trades at $1.0002 is normal during thin weekends. An API that quotes against one variant and executes against the other introduces a slippage surprise.

The healthy way to price stablecoin swaps is to read all relevant pools, quote the best executable price, and surface the specific variant the user will receive. A Circle post on the bridged USDC standard explains why Circle has been pushing for a single canonical bridged variant per chain — the less variant sprawl, the less peg divergence.

Until the market consolidates onto fewer variants, swap APIs have to treat peg divergence as a routing signal, not a bug. The stablecoin liquidity networking writeup covers how pooled liquidity networks let Solvers smooth small divergences across chains rather than letting them show up on user confirmation screens.

A fintech team we worked with integrated a popular bridge-native swap API to move user balances between Ethereum, Base, and Solana. On paper it supported USDC and USDT on all three. In practice, about 18% of swaps routed "USDC" that turned out to be USDC.e on Base, hit thin pools, and delivered 30-50 bps of unexpected slippage on the destination leg. They switched to a solver-based intent API. Same corridor, different outcome: native USDC read on Base where available, USDC.e routed through a deeper Curve pool, and the delivery variant normalized on Solana. Support tickets dropped to near zero. The lesson is not that bridges are bad — it is that the three matrices interact, and a single provider that only covers one will leak value somewhere.

A checklist you can run against any swap API vendor, pulled from the three matrices:

Most of these answers are hard for a vendor to fake. The test swaps are the honest ones — anything the API cannot do in a sandbox, it cannot do in production. The native route explainer covers how intent-based routing changes the test because the API picks the route instead of your team hardcoding it.

Stablecoin swap APIs overlap heavily with stablecoin payment APIs. If you are building a checkout that takes "any stablecoin on any chain" and settles to a single variant for the merchant, you are running a swap API under the hood on every transaction. That integration pattern is covered in the stablecoin payment gateway writeup. The broader ecosystem signal is that the stablecoin market crossed $33 trillion of transaction volume in 2025 according to Circle's stablecoin data, with USDT and USDC together at roughly 93% of circulating supply — concentration that sharpens rather than simplifies the interop problem.

A stablecoin swap API lets an application exchange one stablecoin for another, optionally across chains, through a programmatic interface rather than a manual UI. Good swap APIs handle multiple stablecoin standards, multiple chains, and multiple liquidity venues behind a single request, so the caller does not have to manage CCTP, LayerZero, or DEX routing themselves.

Native USDC is issued directly by Circle on the chain where it lives and moves between chains via CCTP's burn-and-mint protocol. USDC.e is a bridged representation — original USDC is locked on Ethereum while a wrapped token circulates on the destination chain. They are not automatically fungible and can trade at slightly different prices. The fungibility across stablecoin variants article covers practical implications.

Solutions that route USDT natively across chains typically use LayerZero's OFT standard via USDT0. Solutions that need a neutral messaging layer across tokens use Chainlink CCIP. Intent-based APIs like Eco Routes use both as routing options depending on the corridor. See the Eco Routes vs LayerZero writeup for architectural detail.

A same-chain USDC to USDT swap runs through a DEX or aggregator against a liquidity pool. A crosschain USDC to USDT swap involves at least two legs — a crosschain move and a token conversion — which can happen in either order. The swap API picks the order and the route. A good API quotes the total price including both legs, not just the conversion leg.

At minimum: USDC and USDT on Ethereum, Base, Arbitrum, Optimism, Polygon, and Solana. Realistically: add USDC.e variants on the chains that have them, USDT0 for LayerZero-native USDT routing, USDbC on Base for legacy liquidity, and whichever newer dollars your user base holds (USDG, oUSDT, PYUSD). Seven-plus variants is now table stakes, not an edge case.

Stablecoin swap is not a USDC/USDT problem — it is a standards, chains, and liquidity problem dressed up as a two-token question. Score all three matrices.