Skip to content
MANDATE owl logoMANDATE

Architecture

The agent interacts only with the MCP server. All proof generation and on-chain commitment happen inside the SDK and contract layer.

System overview

MoonPay Agent

user-facing

MANDATE MCP Server

3 tools only

MANDATE SDK

proves + submits

Noir Compliance Proof

Noir / UltraHonk

Registry Contract

policy + session key

Auction Contract

proof-gated, on-chain

MandateAccount

funds + escape hatch

Sequencer

epoch loop, state

Local Ethereum Chain

Anvil

The agent interacts only with the MCP server. Proof generation and on-chain commitment happen entirely inside the SDK and contract layer.

Per epoch (default 10 seconds): the agent reads the anchored state, its strategy decides, it proves compliance (Noir/UltraHonk, ~1s on a laptop), and the order commitment goes on-chain gated by the proof — the plaintext order stays off-chain with the sequencer, simulating threshold encryption. The sequencer then closes the epoch, reveals, and the auction contract computes the uniform clearing price on-chain (maximum executed volume, midpoint of the tie interval); fills are emitted, reputation counters accrue, and per-agent state roots advance.

Public inputs are assembled by the contract, not calldata

The five public inputs of every proof — policy commitment (from the registry), state root (from the contract), order commitment, current epoch, and the breaker bit — are assembled by the contract from registry state. An agent cannot substitute different public inputs than what the contract itself holds.

SDK

@0xgks/mandate-sdk coordinates portfolio reads, policy checks, proof generation, signing, and order submission behind a single class, MandateClient. Full reference: /docs/sdk.

Noir circuit

circuits/policy_check is an UltraHonk compliance circuit (~277 ACIR opcodes, ~1s/proof, 13 Noir tests) that proves policy satisfaction without revealing the private strategy. It checks, in order:

  1. Correct opening of the policy commitment (the agent cannot substitute looser limits).
  2. Order/epoch binding (replay-safe — a proof for epoch e cannot be reused in epoch e').
  3. Whitelist Merkle membership (the market is on the approved list).
  4. Portfolio-leaf membership in the on-chain state root (the agent cannot self-report a healthier portfolio).
  5. Notional cap: size × limit_price ≤ max_order_notional.
  6. Post-fill position cap.
  7. Daily loss cap.
  8. Circuit breaker: when active, only strictly risk-reducing orders are provable.

Contracts

Foundry-tested Solidity (24 tests, including on-chain verification of a real proof):

ContractRole
MandateRegistryAgent registration, session-key authorization, policy commitment storage
BatchAuctionCommit–reveal epoch loop; verifies proofs; computes the uniform clearing price on-chain
MandateAccountFund custody; owner-only escape hatch independent of agent, sequencer, or auction
HonkVerifierThe real bb-generated UltraHonk Solidity verifier
MockVerifier / MockERC20Test doubles used only in the Foundry test suite

Sequencer

A minimal HTTP service running the commit–reveal epoch loop: envelope intake (verifies the Poseidon2 opening), reveal, clearing trigger, state-root settlement, and a mock price oracle. It is trusted for liveness and privacy — not for mandate enforcement or replacing proofs. State-transition proofs are deferred: the sequencer computes and posts post-fill Merkle roots off-chain, so the agent still cannot lie, but the operator is trusted for state updates (see Security — trust assumptions).

Local chain

An Anvil-based local Ethereum environment running the MVP contracts. There is no public testnet or mainnet deployment yet — see the roadmap on the Product Overview page.