How ChainMore moves USDC across chains

A short technical 1-pager for engineers and finance teams evaluating ChainMore against Bridge.xyz, BVNK, and similar stablecoin-payment providers.

The headline: ChainMore is the orchestration layer above Circle's CCTP. We never hold customer funds. The customer signs one transaction; the destination leg mints native USDC and forwards it to the merchant under ChainMore route controls. End-to-end timing depends on source-chain confirmation, Circle attestation availability, destination-chain inclusion, and operator policy.

The flow, in 5 stages

Customer authorizes the ChainMore source adapter on the source chain.

The customer's wallet (MetaMask, Coinbase Wallet, Rainbow, any WalletConnect-compatible) signs a bounded USDC authorization or an adapter transaction. Hosted Checkout does not call Circle's TokenMessengerV2 directly; the ChainMore source adapter makes that call so the trusted burn sender and destination payload are bound correctly. ChainMore never holds the signing key.

The source adapter burns the USDC and emits a Message.

The ChainMore source adapter calls Circle's TokenMessengerV2, USDC is destroyed on the source chain, and CCTP's MessageSent event captures the burn, including the destination chain, amount, and recipient. ChainMore's backend monitors for the event but does not custody the funds.

Circle's attestor service signs the burn proof.

Circle's offchain attestor verifies the burn happened and signs the message. Our backend polls Circle's iris-api for the signed attestation. CCTP V2 Fast Transfer can reduce attestation latency where available, but the route remains gated by chain confirmation and ChainMore controls.

Backend submits receiveMessage on the destination chain.

ChainMore's backend wallet (gas-only, never holding USDC) submits the proof to Circle's MessageTransmitterV2 contract on the destination. The wallet is single-purpose: its only capability is calling receiveMessage; an attacker compromising it cannot redirect funds (CCTP's protocol design enforces the recipient).

Smart contract mints USDC and forwards to the merchant atomically.

USDC is minted to ChainMore's settlement contract, which executes the CCTP V2 Hook in the same transaction: it deducts our fee, transfers the rest to the merchant's wallet, and reverts if any USDC is left over. The merchant's wallet receives the funds; we hold nothing.

What this gives the merchant

Faster USDC settlement path: CCTP V2 Fast Transfer can reduce attestation latency where available. End-to-end timing still depends on source-chain confirmation, Circle availability, destination-chain inclusion, and ChainMore route controls.
No third-party bridge or LP: no liquidity-provider slippage, no wrapped-asset bridge layer. Circle's protocol burns USDC on one chain and mints native USDC on the other; the supply is unchanged. Smart-contract risk and protocol risk remain; see Trust model and audits below.
Native USDC at destination: not a wrapped or bridged variant. The merchant receives the same Circle-issued USDC they would receive on a same-chain payment.
Transparent fee model: ChainMore prices the orchestration layer separately from provider and protocol costs. CCTP V2 Fast Transfer adds a variable fee paid through to Circle.
Idempotency by design: the protocol's nonce-binding makes the destination mint replay-safe at the contract level. Multiple submissions of the same proof produce one mint.

Compare to a custodial provider

Custodial provider (e.g. Bridge.xyz)

Customer pays into provider's wallet. Provider holds funds, runs its own bridge, swap, and KYB layer, then pays the merchant through its own operating model. Contracting and KYB timelines depend on the provider, jurisdiction, merchant profile, and rail scope.

ChainMore (orchestrator)

Customer signs transaction directly. Funds flow through Circle's permissionless protocol; ChainMore never custodies. Merchant access is approved through ChainMore onboarding and risk checks before production routes are enabled. The timeline depends on the merchant profile, destination wallets, and partner requirements.

What it does not do

This CCTP explainer is intentionally focused. It does not include:

Fiat off-ramp (USDC to EUR / USD bank transfer). That requires a reviewed settlement or off-ramp partner and is outside this CCTP scope.
Cross-asset payments (e.g. customer pays USDT, merchant receives USDC). Token normalisation requires additional provider, risk, and regulatory review outside this CCTP scope.
Recurring billing or subscriptions.
Card payments. This page covers the current CCTP stablecoin path; card and other fiat rails require a reviewed PSP or acquiring integration and are outside this CCTP scope.

Supported chains and assets

Asset: USDC (native, Circle-issued). Not USDT, not bridged USDC.e.
Source chains: Ethereum, Base, Arbitrum, Polygon. Customers can pay from any of these.
Destination chains: Same set. Merchants can receive on any of these.
Cross-chain only. Same-chain USDC transfers go through our direct-payment path (also non-custodial), not the CCTP path described here.

Trust model and audits

We trust:

Circle: to issue USDC, run the CCTP attestor service, and not collude with attackers.
The underlying chains: Ethereum, Base, Arbitrum, Polygon, for consensus and finality. We require N confirmations per chain to insulate from short-range reorgs.
The customer's wallet: to correctly sign the user's intent. The customer self-custodies; if their wallet is compromised, the funds at risk are their own.

We do not trust:

The customer (could be malicious; sanctions screening at intent creation).
The merchant (could be malicious; sanctions screening at intent creation).
Our own backend (single-key compromise of the gas-only wallet cannot redirect funds; the destination is bound at burn time).
Our own smart contract. External review and vulnerability-disclosure planning are production-mainnet prerequisites.

What you actually need from us

If you're a merchant evaluating ChainMore:

An API key after merchant onboarding approval. Production access remains subject to DD/KYB and risk review.
A wallet address on your preferred destination chain.
A webhook endpoint (optional but recommended).

If you're an engineer evaluating ChainMore against a build-it-yourself approach:

The CCTP integration alone is 2-3 weeks of careful engineering.
Smart-contract audit ($30-80k, 4-6 weeks) is the single biggest line-item.
AML vendor onboarding (Chainalysis or TRM) is required by every downstream partner.
Per-chain operational tooling (RPC fallback, reorg handling, gas refill, alerting) is non-trivial.
Or: use ChainMore's API instead of building this stack yourself.

Want the full architecture document, including state machine, threat model, and acceptance criteria? See our developer documentation. Want to talk to us before deploying? Email hello@chainmore.io.