Circle Gateway

Unified USDC balance backed by deposits across supported source domains

Circle Gateway

Circle Gateway presents one available USDC balance backed by deposits across supported source domains. The rows for each source domain describe the balance’s composition and provenance; they are not separate spending silos. Once USDC is available in Gateway, it can be used to mint and settle on any supported destination.

Think of it as a single prepaid balance funded from several accounts or rails. The source-domain entries still show where each contribution came from for reconciliation, but the usable balance is one balance—not a separate spending account per funding source.

Circle’s Gateway overview and unified-balance how-to describe the provider model. QTG uses that model as a controlled execution lane; its own durable movement and node evidence remain the authority for a QTG movement.

What the dashboard shows

QTG Circle Gateway testnet dashboard: unified balance and source-domain backing; the wallet USDC panel continues below the captured viewport.

The dashboard separates three useful views. This captured viewport shows the first two; the wallet / on-chain-outside-Gateway panel continues below it:

1. Unified total — the available Gateway USDC balance that can support an eligible destination settlement.
2. Backing by source domain — the deposits that compose that balance and preserve their provenance.
3. Wallet / on-chain outside Gateway — USDC still held directly by the wallet, before it becomes Gateway backing.

It is testnet observational evidence, not a mainnet-readiness claim.

QTG execution flow

QTG models the Gateway lane as durable nodes. The exact executor keys are:

Stage	Executor key	What QTG records
Approve Gateway spend	exec.gateway.approve	Signed approval artifact and its verification
Deposit to Gateway	exec.gateway.deposit	Source-chain deposit submission and expected binding
Observe deposit	exec.gateway.deposit_observe	Deposit / backing observation and reconciliation evidence
Create settlement intent	exec.gateway.intent	EIP-712 burn intent and provider request identity
Mint / settle	exec.gateway.mint	Destination execution evidence
Observe mint	exec.gateway.mint_observe	Destination receipt and terminal settlement observation

The transfer side uses a signed EIP-712 burn intent. Circle’s API and attestation processing coordinate the provider-side transfer, while the destination mint and its observation establish the destination evidence. QTG does not treat an API response, dashboard display, or explorer rendering as enough by itself: the persisted movement/node artifacts, signed-artifact checks, and destination observations are its authority.

For implementation boundaries, see Executor overview and the signer protocol.

Gateway and CCTP solve different shapes

	CCTP	Circle Gateway
Starting point	Point-to-point USDC movement	A pre-established unified USDC balance
Transfer shape	Burn on source → Circle attestation → mint on destination	Deposit creates Gateway backing; an eligible instant transfer settles from the unified balance
Source-chain work	A burn is part of each CCTP transfer	Deposits still require source-chain execution; Gateway does not erase that work
Fees and timing	Depend on the selected CCTP route and finality	Depend on Gateway’s supported route and fee model; not a zero-fee claim

Use the CCTP lane when the desired operation is a point-to-point burn/attest/mint transfer. Gateway is useful when deposits have already established a unified balance and a supported destination can settle against it. Circle publishes the relevant protocol and commercial boundaries in its technical guide and fees reference.

Arc

Do not run a Gateway deposit against Arc mainnet (chain 5042). The Gateway wallet and minter contracts are deployed there, but Circle has the Gateway service switched off for Arc. A deposit runs the on-chain deposit first and only then calls the API — the API refuses, and the USDC is left sitting in the Gateway wallet awaiting a separate withdrawal path with its own delay. Arc mainnet CCTP is open; Arc mainnet Gateway is not.

Name Arc explicitly as arc_mainnet (5042) or arc_testnet (5042002). Unlike every other chain QTG routes, Arc’s two networks share both the Circle domain (26) and the USDC predeploy address, so there is no bare arc alias and a wrong guess would not fail downstream.

QTG’s retained Arc Testnet evidence used Circle domain 26. A 0.01 USDC live transfer was finalized by Circle, and the destination mint receipt had status=1 on the Arc RPC. This is narrow route evidence: it shows the observed transfer and destination receipt, not a general availability or readiness guarantee.

Explorer and indexer availability can make investigation easier, but neither is settlement authority. The official Arc connection reference, Circle processing evidence, and the destination-chain receipt are the relevant operational inputs; QTG’s persisted movement/node evidence determines its local conclusion.

Safety and evidence boundaries

• The active EVM signing path uses an AWS KMS signer; private key material is not the normal QTG custody path.
• Destination and source bindings are constrained by the address allowlist, and QTG verifies the signed artifact against the approved action before submission.
• If signing or broadcast evidence is ambiguous, recovery observes the existing identifiers; QTG does not rebroadcast.
• A fresh balance snapshot is recent enough for the configured freshness policy; pending means the relevant deposit or settlement has not reached its terminal observation; stale means it is displayable historical context, not fresh approval evidence.
• Gateway’s API is an eventually-consistent off-chain ledger. QTG reconciles it with source and destination on-chain events instead of treating either side as an unconditional substitute for the other.

The broader policy is described in the security model.

Current scope and non-goals

QTG currently supports Gateway deposit plus instant transfer / mint flows. It does not make Circle’s managed-wallet SDK custody the default: the normal QTG signer boundary remains the configured signer, including AWS KMS for this EVM lane.

There is no implemented seven-day trustless withdrawal lane in QTG. This page and its dashboard screenshot therefore document the supported testnet execution and evidence model—not a custody promise, a withdrawal feature, or mainnet readiness.