> ## Documentation Index > Fetch the complete documentation index at: https://jephalabs.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # 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. ```mermaid theme={null} flowchart LR WALLET["Wallet / on-chain USDC
outside Gateway"] -->|"deposit from a supported source"| BACKING["Gateway Wallet backing
per source domain"] BACKING -->|"composition + provenance"| AVAILABLE["Unified available USDC balance"] AVAILABLE -->|"EIP-712 intent + Circle settlement"| DEST["Mint / settle on any
supported destination"] style WALLET fill:#bbdefb style BACKING fill:#fff9c4 style AVAILABLE fill:#c8e6c9 style DEST fill:#e8f5e9 ``` Circle's [Gateway overview](https://developers.circle.com/gateway) and [unified-balance how-to](https://developers.circle.com/gateway/howtos/create-unified-usdc-balance) 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 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 | ```mermaid theme={null} sequenceDiagram participant W as Source wallet / chain participant Q as QTG durable movement participant G as Circle Gateway API participant D as Destination chain Q->>W: exec.gateway.approve Q->>W: exec.gateway.deposit Q->>G: exec.gateway.deposit_observe Note over Q,G: reconcile source deposit with Gateway backing Q->>Q: exec.gateway.intent (EIP-712 burn intent) Q->>G: submit signed intent / obtain Circle processing state Q->>D: exec.gateway.mint Q->>D: exec.gateway.mint_observe Note over Q,D: durable node evidence determines QTG outcome ``` 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](/reference/executors/overview) and the [signer protocol](/reference/signers/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](/concepts/bridges/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](https://developers.circle.com/gateway/references/technical-guide) and [fees reference](https://developers.circle.com/gateway/references/fees). ## 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](https://docs.arc.io/arc/references/connect-to-arc), 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](/concepts/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.