Four-step pipeline - Compass AI

A Compass cross-chain route is four discrete steps: deposit on Arc, sign and submit a BurnIntent to Circle, mint on the destination chain, and call the target venue. Each step produces its own audit record.

This page covers the executor’s actual sequence. For the primitive being used, see Circle Gateway. For the on-chain permission model the executor signs against, see Session keys.

The sequence

A typical cross-chain route — moving USDC from Arc to open a position on a destination chain — flows through these four steps in order:

Step 1 — Arc deposit

The session key submits a UserOp calling the Gateway facet on the user’s Arc Diamond. The facet burns USDC on Arc and emits the deposit event Circle’s indexer is watching for. The amount the Diamond commits includes a small buffer above the route target — enough to cover Circle’s transfer fee at current rates. The UserOp is validated as any other agent action: the Account4337 facet checks the session key’s selector whitelist and the on-chain policy before execution. See Session keys.

Step 2 — Sign and attest

The session key constructs a BurnIntent for this transfer (see Circle Gateway for the schema), signs the EIP-712 digest, and submits the intent to Circle for attestation. Circle’s indexer waits for the burn event from step 1 to land, then issues a TransferAttestation — a signed proof that the burn happened and the destination is authorized to mint. Attestation typically returns within a few hundred milliseconds of the burn confirming on Arc. The intent itself is recorded in the audit trail by its EIP-712 digest. The digest is a stable identifier for this transfer that’s meaningful before the destination mint exists.

Step 3 — Destination mint

With the attestation in hand, the session key calls Gateway’s mint function on the destination chain. This step lazy-deploys the destination Diamond if it doesn’t yet exist (same address via CREATE2, see Diamond account) and credits the minted USDC to it. There is one wrinkle: at the moment of the mint call, the destination Diamond has zero USDC. A standard ERC-4337 UserOp flow would expect a paymaster to be reimbursed post-execution from the account’s balance — but there is no balance to reimburse from yet. So this single call is made as an EOA transaction from the session key directly, not as a UserOp. The session key holds a small native-gas float on the destination chain for exactly this case. See Arc-native gas for why this exception only applies to non-Arc destinations.

Step 4 — Open the position

Once the mint settles in the destination Diamond’s balance, the session key submits a UserOp calling the target venue facet (supply, deposit, or whatever the venue’s deposit function is named). The facet calls the underlying protocol from the Diamond’s address, and the position is open. The session key validation and on-chain policy check apply here as they do on Arc — every UserOp passes through both gates.

Failure handling

If any step fails, the executor does not attempt to “continue from where it left off.” Instead:

The failed step is recorded in the audit trail with its error.
Remaining steps in this route are abandoned.
The next deterministic loop tick re-evaluates the account’s state and produces a fresh plan.

This is the “pause, never reroute mid-flight” principle. Partial state (for example, USDC successfully burned on Arc but never minted on the destination) is detected by the next tick’s load_state and handled by generating a new plan — typically a gatewayMint retry using the same BurnIntent digest, since Gateway intents are replayable. Designs that would try to “salvage” a failed cross-chain route mid-flight risk taking inconsistent state and turning a transient liveness issue into a permanent safety issue. Compass prefers to fail closed and let the next tick figure it out.

What gets logged

The audit trail records each step as a distinct entry:

RouteStart       { from: Arc, to: <destination>, amount, venue }
StepCompleted    { label: "arc.deposit",    tx_hash: 0x...     }
StepCompleted    { label: "gateway.attest", intent_digest: 0x...}
StepCompleted    { label: "dst.mint",       tx_hash: 0x...     }
StepCompleted    { label: "dst.supply",     tx_hash: 0x...     }
RouteCompleted   { steps: 4 }

If a step fails, a StepFailed entry replaces StepCompleted and a RouteAborted entry replaces RouteCompleted. The audit trail page covers the full record structure.

Same-chain vs cross-chain

Not every action is a four-step route. Same-chain operations — opening, closing, or rebalancing a position entirely on Arc, for example — are a single UserOp:

Pattern	Steps	Cross-chain settlement?
Same-chain	1 UserOp	No
Cross-chain	4 (UserOp + intent + EOA tx + UserOp)	Yes — Circle Gateway

The executor picks the shorter path whenever possible. A cross-chain route only runs when the best venue under the current policy is on a different chain than where the USDC currently sits.

Next steps

Circle Gateway

The signed-intent primitive used in steps 2 and 3.

Arc-native gas

Why step 1 needs no paymaster and step 3 sometimes does.

Audit trail

The full record structure for each step.

Session keys

The validation that gates every UserOp in the pipeline.

Documentation Index

​The sequence

​Step 1 — Arc deposit

​Step 2 — Sign and attest

​Step 3 — Destination mint

​Step 4 — Open the position

​Failure handling

​What gets logged

​Same-chain vs cross-chain

​Next steps