> ## Documentation Index > Fetch the complete documentation index at: https://docs.usecompassai.com/llms.txt > Use this file to discover all available pages before exploring further. # Circle Gateway > How Compass moves USDC across chains — Gateway's signed-intent model and why it's the right primitive for an agent. > Compass uses Circle Gateway as its cross-chain primitive. Gateway lets a Compass account hold a unified USDC balance across supported chains and settles transfers in seconds via signed `BurnIntent` messages rather than on-chain bridge transactions. This page covers what Gateway is and why it fits Compass. For the specific sequence of calls in a cross-chain route, see [Four-step pipeline](/cross-chain/four-step-pipeline). For why Compass doesn't need a paymaster on Arc, see [Arc-native gas](/cross-chain/arc-native-gas). ## What Gateway is Circle Gateway is Circle's cross-chain settlement layer for USDC. The user holds a single logical USDC balance; the protocol moves the underlying tokens across chains as needed. From an account's perspective: * USDC deposited into Gateway from any supported chain becomes part of a unified balance. * USDC can be moved to any other supported chain by signing a `BurnIntent` message. * The transfer settles via Circle's attestation service in under a second, followed by a mint transaction on the destination chain. Gateway is the alternative to traditional bridges. Compass uses it for every cross-chain move because two of its properties matter for an agent. ## Why Gateway fits an autonomous agent ### `BurnIntent` is a signed message, not a transaction The cross-chain trigger is an EIP-712 `BurnIntent` — a message the account's session key signs off-chain. The intent is then submitted to Circle's API for attestation, which produces the proof the destination chain needs to mint. This separation matters in three ways: * **Retryable.** If the destination chain's indexer lags or the mint transaction fails, the same `BurnIntent` can be re-submitted without re-signing or risking double-spend. * **Replayable.** The intent is recorded as a structured artifact, not a one-shot transaction. The deterministic loop can re-validate it. * **Auditable.** Every intent is logged with its digest, which serves as a stable identifier in the [audit trail](/architecture/audit-trail) — even before it becomes an on-chain mint. For an agent that retries on indexer lag and replays decisions for verification, signed messages compose with the architecture better than plain transactions would. ### Same-address smart accounts work cleanly Gateway transfers USDC from a source address to a destination address. Because Compass deploys each user's Diamond at the **same address on every supported chain** via CREATE2, the source and destination of a Compass-initiated transfer are the same address — no separate "deposit account" or "receiving account" wallet to manage. See [Diamond account](/contracts/diamond-account) for how the same-address deployment works. ## The `BurnIntent` structure The `BurnIntent` is the message the session key signs. Its inner `TransferSpec` declares the transfer; the outer `BurnIntent` adds constraints on when and how the intent can be settled. ### `TransferSpec` ```text theme={null} TransferSpec { uint32 version; uint32 sourceDomain; // Circle's chain identifier uint32 destinationDomain; bytes32 sourceContract; // source Diamond address bytes32 destinationContract; // destination Diamond address bytes32 sourceToken; // source USDC bytes32 destinationToken; // destination USDC bytes32 sourceDepositor; // source Diamond bytes32 destinationRecipient; // destination Diamond bytes32 sourceSigner; // the session key address bytes32 destinationCaller; // zero address — any caller may mint uint256 value; // USDC amount in 6 decimals bytes32 salt; // random 32 bytes bytes hookData; // empty for standard transfers } ``` All address fields are `bytes32` — Gateway uses 32-byte addresses so the same schema works across EVM and non-EVM chains. EVM addresses are left-padded with zeros. ### `BurnIntent` ```text theme={null} BurnIntent { uint256 maxBlockHeight; // expiry (uint256 max for no expiry) uint256 maxFee; // upper bound on Circle's transfer fee TransferSpec spec; } ``` `maxFee` is a hard ceiling. If Circle's fee at settlement time would exceed `maxFee`, the burn is rejected. Compass sets `maxFee` based on current rates with a small buffer. ### Domain separator ```text theme={null} EIP712Domain { name: "GatewayWallet" version: "1" } ``` The domain deliberately omits `chainId` and `verifyingContract`. This is intentional — a Gateway signature is valid across chains by design, which is what makes the "unified balance" model work. ## The signer is the session key The address that signs the `BurnIntent` is the account's session key, not the owner EOA and not the Compass backend. Two consequences: * The signature carries the same trust properties as any other agent-initiated action — bounded by the on-chain [policy engine](/architecture/policy-engine) and revocable via [`revokeSession`](/contracts/session-keys#revocation--the-kill-switch). * The `sourceSigner` field in `TransferSpec` is the session key address. This separates "who signed the intent" (session key) from "whose USDC is being moved" (Diamond as `sourceDepositor`). This signer / depositor split is Gateway's native pattern for delegated flows, and it maps cleanly onto Compass's account-plus-agent model. ## What Gateway is not Gateway is not an optimistic bridge. There is no 7-day withdrawal window and no fraud-proof game. Settlement speed comes from Circle's attestation service acting as the source of truth for "this burn happened" — the destination chain accepts a Circle-signed attestation as proof. The trust assumption is on Circle's attestation service. For Compass that's the same trust assumption already in place — USDC itself is a Circle product. ## Next steps The exact sequence of calls in a cross-chain route. Why Arc removes one step compared to other chains. The key that signs BurnIntents and the on-chain checks that bound it. How intent digests and mint tx hashes are both recorded.