System overview

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 has three layers. An off-chain agent generates and evaluates plans, an on-chain smart account enforces them, and Circle Gateway moves USDC between chains. A single audit trail spans all three.

This page is the map. Each layer below has its own dedicated page that goes deeper.

​

The three layers

The solid arrows are the execution path: chat → plan → policy check → session key → smart account → (optional) cross-chain settlement. The dashed arrows are the audit path: every component writes to a shared trail.

​

Layer 1: Off-chain agent

The off-chain layer is where decisions are proposed and evaluated. Nothing in this layer can move funds directly — it produces plans that the on-chain layer either accepts or rejects. It has four components:

• Chat agent. The LLM-facing interface. It reads user messages, asks for missing detail, and emits structured plans. It is the only component that touches a language model. See Chat agent.
• Deterministic loop. A Rust evaluator that ticks on a fixed cadence, re-evaluates every account, and proposes routes when better venues appear. Pure functions, fully reproducible. No LLM in this loop. See The deterministic loop.
• Policy engine. Checks every plan — whether from the chat agent or the deterministic loop — against the rules attached to the user’s account. Rejects out-of-policy plans before they reach the on-chain layer. See Policy engine.
• Audit trail. Records every tick, every plan, every check, every decision. See Audit trail.

A useful frame: the chat agent and deterministic loop are two sources of plans, the policy engine is the single gate, and the audit trail is the record. The LLM is in source-1 only. Source-2 runs on every account every tick with zero LLM cost.

​

Layer 2: On-chain smart account

The on-chain layer is where funds actually move. It is per-user — every Compass user has their own smart account, deployed at a deterministic address. It has two components:

• Diamond account. An ERC-2535 Diamond holding the user’s USDC and managing facets for each supported venue. The user is the sole owner. See Diamond account.
• Session key. A scoped key the agent uses to call whitelisted functions on whitelisted venues. The session key cannot withdraw, cannot upgrade the account, and cannot change the rules. See Session keys.

The smart account enforces the policy again, on-chain, on every call. This is why the trust model is the contract, not the operator — even if the off-chain layer were compromised, calls outside the session key’s scope would revert. See Trust & security model.

​

Layer 3: Cross-chain settlement

When a route requires moving USDC from one chain to another, the executor uses Circle Gateway. Gateway gives Compass a unified USDC balance across supported chains, so cross-chain moves settle in under a second. Two properties of Gateway matter for the architecture:

• BurnIntent is a signed message, not a transaction. The intent can be retried after indexer lag, re-broadcast, or replayed without re-signing. This is why the deterministic loop’s retry behavior is safe.
• Same address across chains. Your Diamond is deployed on Arc when you first set up the account. On every other supported chain, the Diamond is lazy-deployed the first time you stake there — at the same address, via CREATE2 with a matching deployer salt. USDC that lands on the target chain is always owned by the same address that signed on Arc.

See Four-step pipeline for the exact sequence.

​

How the layers interact

A single route, traced through all three layers:

1. User → chat agent (layer 1). User types something like move 5 USDC to the best lending venue on an L2.
2. Chat agent → policy engine (layer 1). The LLM emits a plan. The policy engine checks it against the user’s rules.
3. Policy engine → session key (layer 1 → layer 2). Approved plan becomes a session-key-signed call.
4. Session key → Diamond account (layer 2). The smart account re-validates the call at the contract level and executes.
5. Diamond account → Circle Gateway (layer 2 → layer 3). Cross-chain transfer if needed.
6. Diamond account on target chain → venue (layer 2). The deposit call is made from the same address.
7. Every step → audit trail. Off-chain reasoning, on-chain tx hashes, and Gateway intent IDs all land in the same record.

For the same walkthrough from the user’s perspective, see How it works.

​

What’s in each section

The rest of the Architecture group covers each piece in detail: For the on-chain side, see Smart contracts. For the cross-chain side, see Cross-chain.