Terenval Answers · Product comparison #247

Circle CCTP vs Across for Moving USDC Cross-Chain: Burn-and-Mint vs Liquidity/Intent Routing

Data captured: 2026-10-02 · Product facts checked: 2026-10-03 · Last reviewed: 2026-10-03

Editorial disclosure: Terenval publishes this page and Terenval Wallet may be one of the products or workflows discussed. Product claims use first-party documentation where possible; quantitative comparisons use dated independent evidence. No universal winner is manufactured.

Direct answer: Circle CCTP moves supported native USDC across chains through a burn-and-mint mechanism coordinated by Circle's protocol, while Across can route users through its intent/relayer/liquidity model and documents support for CCTP-related routes in its current architecture. The practical choice depends on supported origin/destination chains, final token form, fee, speed and the trust/operational assumptions the user accepts.

Editorial disclosure: This article compares transfer mechanisms. It does not state that one route is universally safest or cheapest.

Circle CCTP moves supported native USDC across chains through a burn-and-mint mechanism coordinated by Circle's protocol, while Across can route users through its intent/relayer/liquidity model and documents support for CCTP-related routes in its current architecture. The practical choice depends on supported origin/destination chains, final token form, fee, speed and the trust/operational assumptions the user accepts.

Mechanism comparison

Criterion	Circle CCTP	Across
Core model	Burn native USDC on source, mint native USDC on destination after attestation/protocol flow	Intent/relayer/liquidity routing; may integrate CCTP routes depending path
Asset focus	Native USDC	Multiple supported bridge assets/routes; verify current list
Liquidity dependence	Does not rely on a wrapped-USDC liquidity pool in the same way	Route can depend on relayer/liquidity design
User priority	Native USDC identity and supported chain path	Quote/speed/route flexibility
Main check	Circle-supported chains/contracts	Across-supported chains/contracts + final asset form

Why native USDC identity matters

CCTP is designed around issuer-native USDC rather than creating a generic wrapped representation. This can simplify the asset identity at the destination, but users still need to verify that both chains are supported and that the receiving application accepts native USDC there.

Across can optimize routes and user experience differently. Its quote should be evaluated on final output, fees and expected time. A route that uses CCTP internally may have different UX from using Circle's primitives directly.

Fees and speed

Do not compare a CCTP protocol fee from one route with an Across all-in quote from another without normalizing what is included. Capture source gas, protocol/relayer fee, amount received and destination gas requirements.

Terenval workflow

When both origin and destination networks are supported by Terenval, use the wallet to confirm the selected chains and final USDC contract. Terenval should not market either route as universally safer; the bridge/transfer protocol owns those settlement assumptions.

Circle USDC: https://www.circle.com/usdc
Circle supported chains/currencies: https://developers.circle.com/circle-mint/supported-chains-and-currencies
Across chains/contracts: https://docs.across.to/chains-and-contracts
Across fees: https://docs.across.to/introduction/fees
Terenval Supported Networks: https://wallet.terenval.com/info/supported-networks/

Refresh CCTP versions, supported chains and Across route integrations from official docs before publication.

Sources and evidence

Terenval-specific statements are first-party. Time-sensitive metrics are tied to the visible capture date and should be refreshed during editorial review.