Circle Gateway vs CCTP: Unified USDC Balance Guide

Circle Gateway can mint USDC on another chain in under half a second, but only after your deposit has sat through 13 to 19 minutes of Ethereum finality. Getting that deposit back without Circle's API takes about a week, and the two functions that do it stop working whenever Circle pauses the contract.

None of that makes Gateway a bad product, just a different one from CCTP, and the pages ranking for "Circle Gateway" don't explain how. They are Circle's own docs, launch coverage that stops at "under 500 ms", and one competitor's comparison that lists CCTP's latency as Gateway's. None prices a transfer. The figures below come from Circle's docs, the contracts on GitHub, live calls to the Gateway API and on-chain reads of the wallet contracts on 31 October 2026.

What Is Circle Gateway?

Gateway gives a wallet address one USDC balance spread across several chains. You deposit USDC into a GatewayWallet contract on any supported chain. Circle's off-chain ledger credits your unified balance once the deposit finalises, and from then on you can mint that value on any other supported chain by signing a message.

It went live on mainnet on 19 August 2025 on seven chains. It now covers 13 domains: Ethereum, Avalanche, OP, Arbitrum, Solana, Base, Polygon PoS, Unichain, Sonic, World Chain, Sei, HyperEVM and Arc. Solana arrived on 14 January 2026 and Arc on 16 September 2026. EURC (on six chains) and cirBTC (on Ethereum and Arc) joined USDC on 23 October 2026.

The EVM contracts share one address on every chain: GatewayWallet at 0x77777777Dcc4d5A8B6E418Fd04D8997ef11000eE and GatewayMinter at 0x2222222d7164433c4C09B0b0D809a9b52C04C205. Gateway reuses CCTP's domain IDs (Ethereum 0, Base 6, Arc 26) and nothing else. It has its own contracts, its own attestation signers, its own API, and its own USDC minter role. On Base, GatewayMinter's minter allowance stood at about 44.9m USDC when I read it.

How Does Circle Gateway Work?

A transfer has five steps, and their order is what matters.

1. Deposit. Call deposit, depositFor, depositWithPermit (EIP-2612) or depositWithAuthorization (EIP-3009) on the wallet contract. A plain ERC-20 transfer to the contract is not credited, and Circle's docs say that USDC is lost. 2. Sign a burn intent. On EVM chains this is EIP-712 typed data. On Solana it's an ed25519 signature over the byte-encoded struct behind a 16-byte prefix. 3. Request the transfer. POST /v1/transfer with an array of signed intents. The API checks the signature, fee and balance, then returns HTTP 201 with a transferId, an attestation and Circle's signature. 4. Mint. Anyone can submit gatewayMint(attestation, signature) on the destination chain, unless you set destinationCaller, in which case only that address can. Attestations expire after 10 minutes, and an unused one is credited back to your balance. 5. Burn, later. Circle's operator calls gatewayBurn on the source chain. The contract re-verifies your signature, sends the fee to Circle and burns the rest.

Steps 4 and 5 are the whole design. Circle mints on the destination before it burns on the source, so for a while the same value exists on both chains, backed by Circle's ledger and your signed intent. CCTP runs the other way: burn, wait for finality, then mint. Gateway moves the finality wait out of every transfer and into the deposit, and the withdrawal delay is what makes that safe.

The Forwarding Service, live since 11 February 2026, submits the mint for you if you call /v1/transfer?enableForwarder=true. You then poll GET /v1/transfer/{id}, which moves through pending, confirmed and finalized, or ends in failed or expired.

How Long Does a Circle Gateway Deposit Take?

"Under 500 ms" is the time from transfer request to attestation once the balance exists. It excludes the deposit, and it excludes the destination mint landing in a block. Circle's supported-blockchains page gives the deposit wait:

Rollup deposits wait for Ethereum finality, not the L2's soft confirmation. Top up your float from Base and the money is unspendable for a quarter of an hour, exactly as with CCTP Standard. Circle's Fast Deposit uses CCTP Fast Transfer to land deposits on Avalanche or Polygon instead, with you paying the CCTP fee. For now it's only offered through Arc App Kits.

What Does a Gateway Burn Intent Look Like?

This is what POST /v1/estimate returned for 1,000 USDC from Ethereum to Base, with placeholder addresses for the depositor and recipient:

{
  "burnIntent": {
    "maxBlockHeight": "26369090",
    "maxFee": "1155000",
    "spec": {
      "version": 1,
      "sourceDomain": 0,
      "destinationDomain": 6,
      "sourceContract": "0x77777777dcc4d5a8b6e418fd04d8997ef11000ee",
      "destinationContract": "0x2222222d7164433c4c09b0b0d809a9b52c04c205",
      "sourceToken": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
      "destinationToken": "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913",
      "sourceDepositor": "0x1111111111111111111111111111111111111111",
      "destinationRecipient": "0x2222222222222222222222222222222222222222",
      "sourceSigner": "0x1111111111111111111111111111111111111111",
      "destinationCaller": "0x0000000000000000000000000000000000000000",
      "value": "1000000000",
      "salt": "0xabab...abab",
      "hookData": "0x"
    }
  }
}

Every address field is a bytes32 in the contract, so EVM addresses are left-padded when you build the typed data yourself. Five details matter in production:

• The EIP-712 domain is only {name: "GatewayWallet", version: "1"}. There's no chainId and no verifyingContract, so one signature verifies on every chain. Replay protection comes from the transfer spec hash, which is why salt must be unique per intent.
• maxBlockHeight counts source-chain blocks, and on Arbitrum it's an Ethereum L1 block number. The API rejects any intent that expires sooner than the wallet's withdrawalDelay from now, so the shortest-lived intent you can sign is valid for about a week. Circle's own sample code sets it to maxUint256, which never expires.
• hookData is carried but never executed. GatewayMinter only mints. To act on arrival, set destinationCaller to your contract and mint inside a multicall.
• Batching: up to 16 intents per request, drawn from several EVM chains in one BurnIntentSet if they share a sourceSigner. Solana intents go one at a time.
• Limit: the API rejected 10,000,000.000001 USDC with "Maximum: 10000000 USDC". That cap isn't in the docs.

Circle Gateway Fees in 2026

A cross-chain transfer costs 0.005% (0.5 bps) of the amount plus a flat gas fee set by the source chain. That fee pays for Circle's later burn, so you never pay source gas at transfer time. Same-chain withdrawals skip the percentage.

The maxFee you sign must cover the gas fee, plus 0.00005 × amount, plus any forwarding fee, or the API refuses the transfer. The estimate endpoint adds 10%: 1,000 USDC from Ethereum came back with maxFee of 1,155,000 base units, which is 1.1 × (1.00 + 0.05). Forwarding is documented as $0.05 plus destination gas, and live quotes for 1,000 USDC ran from $0.050 into OP to $0.745 into Ethereum.

The live API disagreed with the fees page twice. Every quote with Arc as source or destination came back with no transferFee at all, including 10,000 USDC from Arc to Base. Forwarding into Arc cost $0.016, below the "$0.05 on all chains" in the docs. I'd treat both as promotional pricing that can change without a docs update.

How Does the Circle Gateway 7-Day Withdrawal Work?

If Circle's API goes away, you call initiateWithdrawal(token, value) on the wallet contract, wait withdrawalDelay blocks, and call withdraw(token). A second initiateWithdrawal adds to the amount and restarts the clock.

The delay is set in blocks, so "7 days" is approximate. I read withdrawalDelay() on each chain and timed the most recent run of that many blocks:

The delay protects Circle more than it protects you. Because Circle mints before it burns, a depositor could otherwise take an attestation, mint on Base, then withdraw the same USDC on Ethereum before the burn lands. The rule that every burn intent must outlive withdrawalDelay closes that gap. Circle always holds a valid intent it can burn before your withdrawal completes, and gatewayBurn draws on your withdrawing balance once your available balance runs out.

Is Circle Gateway Actually Non-Custodial?

Mostly, with two caveats the docs leave out. Circle can't move deposited USDC without your signature, so the custody claim holds. But initiateWithdrawal and withdraw both carry a whenNotPaused modifier, and the contracts are UUPS-upgradeable by Circle. The trustless exit works only while Circle hasn't paused or replaced the contract.

Key management has a catch too. removeDelegate doesn't cancel intents a delegate has already signed, because the burn checks whether the signer was ever authorised. Combine that with the one-week minimum expiry and a leaked delegate key stays usable for at least a week after you revoke it. With maxUint256 expiries, it stays usable indefinitely.

Smart contract accounts have been able to sign since 5 August 2026. An AWS Nitro Enclave simulates the account's ERC-1271 isValidSignature against two of three RPC providers, then re-signs with ECDSA. Validation logic that changes state isn't supported.

My view is that, for USDC, none of this adds a trust assumption. Circle can already freeze USDC at the token level, so a pausable Gateway wallet asks little beyond what you accepted when you chose USDC. That's the strongest argument for Gateway over a solver bridge: you trust the one party you already trust, rather than adding a relayer set and an oracle.

Circle Gateway vs CCTP V2: Which Should You Use?

On fees Gateway beats Fast almost everywhere. Moving 1,000 USDC from Base to Arbitrum costs $0.06 through Gateway against $0.13 through CCTP Fast at 1.3 bps. At 100,000 USDC it's $5.01 against $13. Ethereum is the exception: with a $1.00 flat fee against Fast's 1 bp, Gateway only wins above about 20,000 USDC, before counting the Ethereum gas you pay yourself to call depositForBurn.

The flow should decide, not the fee. CCTP fits one-off transfers by someone who holds USDC on one chain and wants it on another: nothing is pre-funded and there's no float to reconcile. Gateway fits anyone who keeps working balances on three or more chains and spends from them all day, such as payout platforms, exchanges and PSPs settling merchants on whichever chain they ask for. Circle's own February 2026 framing, Gateway as "pull" and CCTP with forwarding as "push", gets this right. My CCTP V2 guide covers CCTP's fees, attestation polling and the V1 shutdown.

Circle Gateway vs Across, Relay and Chainlink CCIP

Across routes large USDC transfers, up to $10m, through CCTP V2 itself, so on big tickets you are often paying Across to call CCTP for you. Particle's Universal Accounts sell the same one-balance idea, but a solver fronts the funds from pools Particle runs, and no latency or fee figures are published.

Gateway also sits under Circle's Nanopayments, live on mainnet since 29 April 2026. Buyers sign EIP-3009 authorisations against a GatewayWalletBatched domain, payments go as low as $0.000001, and Circle settles them in batches of balance changes that must net to zero. The live x402 endpoint now advertises minValiditySeconds: 604800, seven days, where parts of Circle's docs and my EIP-3009 vs Permit2 piece say three.

Is a Unified USDC Balance Worth Pre-Funding?

For a business that already holds float on several chains, yes. The 7-day exit sounds alarming until you notice it only matters if Circle's API is unavailable for days. An outage that long would also stall CCTP, whose mints wait on Circle's attestation service, so choosing CCTP doesn't buy you much independence.

Here's my prediction, and it is opinion. Within a year, CCTP Fast becomes mainly the way money gets into Gateway rather than a rival to it. Fast Deposit already works that way. The Unified Balance Kit, released for Arc in April 2026, wraps Gateway for apps, and the live API waives the 0.5 bps on Arc routes. Expect Fast Deposit to leave Arc App Kits and become an ordinary API option, at which point the 13–19 minute deposit wait, Gateway's biggest weakness, mostly disappears for anyone willing to pay a basis point.

What This Means for Payment Engineers in the UK and EU

1. Treat Gateway as a treasury account, not a transfer API. USDC leaves your wallet on deposit, so balanceOf drops to zero. Reconcile against POST /v1/balances and the contract events, and book the 10-minute attestation window as pending. 2. Size float by deposit finality. Top up from Solana, Avalanche, Polygon or Arc when speed matters. Rollups make you wait 13–19 minutes. Keep Ethereum as a source for large moves only, given the $1 fee. 3. Never copy maxBlockHeight: maxUint256. Use the minimum the API accepts plus a margin, so revoking a delegate takes effect in about a week rather than never. 4. Generate a fresh 32-byte salt for every intent and store the transfer spec hash. It's your idempotency key and the way to match burns back to ledger entries. 5. Block plain ERC-20 transfers to 0x7777...00eE in payout code. One wrong transfer call loses the money. 6. Read fees from /v1/estimate, never from config. The Arc waiver shows the live numbers already differ from the docs. 7. Check the token before the rail. EURC now works on six Gateway chains with fees charged in EURC, which matters for euro settlement. EU firms should confirm the e-money token status of anything they route. In the UK, the FCA's stablecoin regime applies from 25 October 2027, so build expecting the rules to change before then.

Gateway trades a week of exit time for sub-second spending. That's a good trade if your code treats the deposit as the slow step and each signed intent as a standing authorisation that outlives the API call. More notes from the payments stack by Tom Wang.