The burn-and-mint lifecycle
1
approve
The bridge is approved to spend the USDC being moved.
2
burn
USDC is burned on Arc, emitting a cross-chain message.
3
fetchAttestation
Circle attests the burn. Because Arc has instant finality, the attestation is
reached fast.
4
mint
Native USDC is minted on the destination chain (Base Sepolia in our demo): the
same dollar, no wrapper.
Verified live on Arc testnet: a 1 USDC transfer ran the full
approve → burn → fetchAttestation → mint lifecycle in about 15 seconds, each step a real transaction,
minting native USDC on Base Sepolia, on both the local and the live production
backend. SDK: @circle-fin/bridge-kit.Stellar
Stellar is on this rail too, and it is the one destination that needs its own paragraph. Circle’s Bridge Kit has no Stellar adapter, somcp/src/cctp-stellar.ts
drives the protocol directly: burn, Iris attestation, mint, in both directions.
- A Stellar recipient must go through Circle’s
CctpForwarder. The CCTP message format has no room for a StrKey type marker, so theG...account rides in the hook data and the forwarder mints and forwards in one atomic call. A direct mint to aG...account is unrecoverable. - Seven decimals on one side, six on the other. Stellar assets carry 7 decimals and every EVM USDC carries 6, so an amount is converted rather than copied.
- Testnet-proven both ways on 2026-09-10: Arc testnet to Stellar testnet, and a Stellar testnet burn minted back on Arc. Both legs are on the proof pages.
- Mainnet is opt-in only. It runs behind
CCTP_STELLAR_ALLOW_MAINNETwith a single-digit USD cap (CCTP_STELLAR_MAX_USD, default 5), and the hosted deployment carries no CCTP Stellar keys, so production returns a labeled prepared no-op there.
Gateway vs CCTP
Build on Arc
Arc is the primary rail: gas in USDC, sub-second finality. CCTP and Gateway extend
it across chains.
