Skip to content
MANDATE owl logoMANDATE

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

Everything on this site describes a working local system: a real Noir/UltraHonk circuit, real Foundry contracts, a real published npm package, and a real local demo. It runs on a local Anvil chain with test-only keys. It has not been externally audited and has no public testnet or mainnet deployment. See Current limitations.

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.