Introduction
MANDATE is a verifiable policy enforcement layer for autonomous financial agents. This page introduces the core concepts used throughout the rest of the documentation.
Introduction
MANDATE sits between an AI agent and a financial execution system. Before an agent can submit a financial action, MANDATE requires the action to be accompanied by a cryptographic proof showing that it complies with the user's predefined policy. MANDATE does not decide what an agent should do — it enforces what the agent is allowed to do.
The current MVP integrates MANDATE with the MoonPay Agent through a published MCP server (@0xgks/mandate-mcp@0.1.0). If you want the fastest path to a working system, start with Quickstart.
Project status
Local MVP — experimental, not audited
Mandates
The user-defined set of rules that governs what an agent is permitted to do. Analogous to a delegation agreement with explicit boundaries.
A mandate is composed of a policy (the specific numeric and structural rules) plus the authorization data (session key, on-chain registration) that lets an agent act under it.
Policy commitments
A cryptographic fingerprint (Poseidon2 hash) of the policy, stored on-chain at registration time. Ensures the policy used during proof generation matches what the user originally registered.
Concretely, the repository's policyCommitment() function computes Poseidon2(whitelistRoot, maxOrderNotional, maxPosition, maxDailyLoss, policySalt). The agent's SDK client checks this local commitment against MandateRegistry.policyCommitmentOf(agentId) before ever generating a proof — see SDK — agent registration.
Session keys
A limited cryptographic key that allows an agent to sign order instructions. Scoped to a specific registered mandate; has zero authority over user funds.
The session key has zero authority over funds — no function of the MandateAccount contract is callable by it. It exists only to sign order-submission calls to the BatchAuction contract.
Portfolio state
An agent's portfolio (position and daily PnL, per market) is stored as a leaf in a sparse Merkle tree whose root is anchored on-chain by the settlement contract. The agent proves a portfolio leaf is a member of that root — it cannot fabricate a healthier portfolio, because it doesn't control the commitment. See Architecture — Noir circuit.
Compliance proofs
A cryptographic method that allows one party to prove a statement is true without revealing the underlying private information.
MANDATE's compliance circuit is written in Noir and proved with UltraHonk (Barretenberg). It proves, in a single proof, that an order simultaneously satisfies whitelist membership, the notional cap, the post-fill position cap, the daily-loss cap, and circuit-breaker mode — against a portfolio anchored on-chain. See Architecture — Noir circuit for the exact constraint list.
Order commitments
An order commitment is Poseidon2(market, side, size, limit_price, epoch, order_salt). Binding the epoch into the commitment means a proof generated for epoch e cannot be replayed against a different epoch — the circuit rejects the mismatch (see test_order_commitment_mismatch_rejected).
Epochs and batch auctions
A time-bounded auction window. Orders can only be committed during the commit phase of an epoch.
The on-chain execution venue (BatchAuction) where compliant orders are committed during an epoch's commit phase and later processed during the clearing lifecycle. The default epoch duration in the demo is 10 seconds. See Demo for a walkthrough of a full epoch, including a compliant and a rejected order.