Skip to main content

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.

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. For why Compass doesn’t need a paymaster on Arc, see 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 — 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 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

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

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

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 and revocable via revokeSession.
  • 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

Four-step pipeline

The exact sequence of calls in a cross-chain route.

Arc-native gas

Why Arc removes one step compared to other chains.

Session keys

The key that signs BurnIntents and the on-chain checks that bound it.

Audit trail

How intent digests and mint tx hashes are both recorded.