Product Overview
MANDATE — Product Overview
A structured web adaptation of mandate-product-overview.pdf — the practical walkthrough of the working local MVP. For developer reference (install commands, exact types, tool schemas), see Documentation.
mandate-product-overview.pdf — Product Overview, July 2026
Open in new tabExecutive summary
AI agents are increasingly capable of interacting directly with financial systems — placing orders, initiating payments, managing portfolio positions, and executing across protocols and platforms. MANDATE is a verifiable policy layer placed between an AI agent and a financial execution rail: the agent does not simply assert that an action is allowed, it generates a zero-knowledge compliance proof demonstrating that the action satisfies the registered policy. If the proof cannot be produced, the order cannot be submitted.
The current working MVP integrates MANDATE with the MoonPay Agent through a published MCP server, @0xgks/mandate-mcp@0.1.0. During testing, a valid order (buy 250 units at 3,500 — notional 875,000) was successfully proven and submitted on-chain. An oversized order (10,000 units at 3,500 — notional 35,000,000) failed proof generation and was correctly rejected, with no transaction accepted and the server remaining fully available.
The problem: agents need authority, but not unlimited authority
Consider a practical scenario: a user wants an AI agent to trade ETH on their behalf, but only within a specific market, within an order size of 1,000,000 notional, with a defined position limit, and a daily loss ceiling — provided as instructions in the agent's prompt.
| Risk | Example | Without MANDATE |
|---|---|---|
| Prompt injection | Malicious input instructs agent to place an oversized order | Instruction may override original policy |
| Strategy bug | Agent miscalculates position and submits an oversized trade | No circuit-level constraint |
| Unauthorized market | Agent selects an asset not on the approved list | No enforceable whitelist |
| Policy manipulation | Local execution limits differ from registered policy | No on-chain commitment to verify against |
| Compromised runtime | Agent output is tampered with before submission | No cryptographic receipt of compliance |
| State inconsistency | Off-chain portfolio data is stale or falsified | No state-root verification |
Key insight
What MANDATE is
MANDATE is
- + Policy enforcement infrastructure
- + An agent authorization layer
- + A proof generation and verification path
- + An integration layer for execution systems
- + Verifiable delegated authority
- + A protection layer for autonomous agents
MANDATE is not
- − An AI model or trading strategy
- − A general-purpose wallet
- − A replacement for MoonPay
- − A centralized risk API
- − A simple transaction simulator
- − A standard multi-signature scheme
Core design principle:the circuit proves the ACTION, not the model. It does not prove “this is a trustworthy AI.” It proves: “this order satisfies policy constraint set P against portfolio state S, where S is anchored on-chain.” The agent's strategy, reasoning, and confidence level are irrelevant to whether the proof succeeds.
User experience
From the user's perspective, MANDATE operates as a silent enforcer running behind the agent: the user defines the rules once, and the system enforces them automatically on every execution attempt — (1) user defines the mandate, (2) MANDATE registers a policy commitment and issues a session key, (3) the agent proposes an order, (4) MANDATE checks it and generates (or fails to generate) a proof, (5) only a validly-proven order reaches the execution layer.
How the MVP works
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.
Order plaintext (side, quantity, price) stays off-chain with the sequencer until the commit phase closes — a commit-reveal design that simulates threshold encryption. Only the order commitment hash goes on-chain with the proof. Full component breakdown: Architecture.
What the agent can do
The MCP server exposes exactly three tools — this is a deliberate security boundary, not an incomplete API.
| Tool | Type | Purpose |
|---|---|---|
| mandate_get_epoch | Read-only | Get MANDATE auction epoch state |
| mandate_get_portfolio | Read-only | Get MANDATE portfolio |
| mandate_submit_order | Execution (proof-gated) | Submit a MANDATE proof-gated order |
Full schemas and configuration: MCP documentation.
The demo policy
| Rule | Demo value |
|---|---|
| Approved market | Configured whitelist market (whitelist index 0) |
| Maximum order notional | 1,000,000 |
| Maximum position | Configured position limit |
| Maximum daily loss | Configured daily loss limit |
| Authorization | Registered session key |
| Policy identity | On-chain commitment hash (Poseidon2) |
| Execution window | Active commit phase of the current epoch |
| Emergency control | Circuit breaker (active / inactive) |
Order notional = quantity × limit price.
| Order | Quantity | Price | Notional | Limit | Result |
|---|---|---|---|---|---|
| Valid | 250 | 3,500 | 875,000 | 1,000,000 | ALLOWED — proof generated |
| Invalid | 10,000 | 3,500 | 35,000,000 | 1,000,000 | REJECTED — proof failed |
Interactive version with a full breakdown: Demo.
Verified demo results
Produced during a live local test — not simulated outcomes.
| Field | Value |
|---|---|
| Epoch | 396 |
| Order commitment | 0x12a254be...5e74d89 |
| Transaction hash | 0xdee28569...9a60bc01 |
Confirmed
- MoonPay Agent can discover and connect to the MANDATE MCP server
- Read-only tools return accurate current state
- Portfolio state root matches the on-chain committed value
- A compliant order generates a valid Noir compliance proof
- A compliant order is successfully committed to the on-chain batch auction
- An on-chain transaction is produced with a verifiable transaction hash
- A non-compliant order fails proof generation
- The non-compliant order is not submitted — no on-chain transaction created
- The MCP server remains fully available after rejecting a non-compliant order
- Execution is isolated behind a single, controlled tool
Not yet proven
- Mainnet safety or real-money security
- Real-fund custody adequacy
- Production-scale decentralization
- External security audit results
- Production-scale proof generation performance
- Multi-market or cross-chain liquidity
- Cross-chain settlement
- State-transition validity (sequencer posts state roots after clearing; operator trust for state updates not yet eliminated)
Comparison with alternatives
| Approach | Strength | Limitation |
|---|---|---|
| Prompt instructions | Easy to implement, low overhead | Model may ignore, misunderstand, or be manipulated |
| Human approval | Strong oversight, high trust | Slows or prevents autonomous operation |
| Backend rules | Practical, flexible, widely used | User must trust the operator; not independently verifiable |
| Wallet spending limits | Useful financial boundary | Cannot express strategy-level or multi-variable rules |
| Multisig | Strong ownership model | Not designed for high-frequency autonomous execution |
| MANDATE | Verifiable, programmable, proof-based | Current MVP is local and experimental |
Security model
- 1
Schema validation
Malformed inputs are rejected before any processing (Zod-validated MCP tool inputs).
- 2
Session-key authorization
The agent must hold a registered key scoped to a specific mandate. The session key has zero authority over funds — no MandateAccount function is callable by it.
- 3
Policy-commitment verification
MandateClient checks the local plaintext policy opens the on-chain registered commitment before ever proving — refusing to prove with a stale or wrong mandate.
- 4
Portfolio-state-root verification
Confirms the sequencer-reported portfolio matches the on-chain committed state root. The agent cannot fabricate a healthier portfolio. The sequencer/operator is trusted to post correct state roots after clearing — state-transition proofs are deferred.
- 5
Zero-knowledge compliance proof
The Noir/UltraHonk circuit cryptographically proves all policy constraints are satisfied simultaneously — whitelist, notional, position, daily loss, and breaker mode.
- 6
On-chain contract verification
The bb-generated HonkVerifier re-verifies the proof on-chain. The five public inputs (policy commitment, state root, order commitment, epoch, breaker bit) are assembled by the contract from registry state, not taken from calldata.
- 7
Batch-auction epoch commitment
An order is committed only within the valid commit window of the current epoch; the order commitment binds the epoch, so a proof cannot be replayed against a different one.
- 8
Owner escape hatch
MandateAccount provides an owner-only withdrawal that depends on nothing — not the agent, sequencer, proof, or auction being alive.
Failure at any single layer is sufficient to prevent an order from being submitted.
Full threat model and trust assumptions: Security.
Current MVP vs. future production system
| Area | Current MVP | Production direction |
|---|---|---|
| Network | Local Anvil chain | Public L2 or application-specific deployment |
| Sequencer | Single trusted service (state-transition proofs deferred; operator trusted for state updates) | Decentralized operator set; proved state transitions; watchtowers |
| Market | Single demo market | Multiple real markets |
| Funds | Test-only keys and values | Audited custody and settlement integration |
| Proofs | Real Noir / UltraHonk compliance proofs (~1 s/proof) | Optimized, audited, production-benchmarked |
| Order privacy | Commit-reveal through single sequencer (ring-1 privacy) | Threshold-encrypted intents via decentralized keyper set |
| Reputation | On-chain counters (epochs, orders, volume, violations) | Nova-style recursive credential (constant-size, portable) |
| Auction | Local batch auction with real on-chain clearing | Production liquidity, clearing, and settlement |
| Monitoring | Local logs | Watchtowers, alerting, and operational dashboards |
| Integration | MoonPay Agent via MCP | Multiple agent platforms, wallets, payment systems |
Potential use cases
MANDATE's policy model is intentionally general — the same architecture applies across many autonomous financial applications:
| Use case | Example mandate |
|---|---|
| Autonomous trading agent | May trade only whitelisted markets; max position 500,000; max daily loss 50,000 |
| Treasury management agent | May rebalance approved assets within a 2% daily risk budget; no withdrawals to new addresses |
| Payment agent | May pay approved vendors up to a daily cumulative limit of 25,000 |
| DAO treasury agent | May execute approved treasury actions below the governance authorization threshold |
| Institutional execution agent | Must follow venue restrictions, exposure limits, and drawdown rules at circuit level |
| Portfolio rebalancing agent | May adjust allocations within predefined bands; no single trade may exceed 5% of portfolio NAV |
| Cross-chain intent execution | May bridge approved assets between approved networks within configured size limits |
| Business spending agent | May approve invoices from registered suppliers below a per-transaction ceiling |
Roadmap
Phase 1 — Completed MVP
Noir/UltraHonk circuit (13 tests), contracts (24 tests), SDK, sequencer, agent strategies, demo script, npm package, MoonPay Agent integration
Phase 2 — Surface layer
Next.js principal dashboard, docker-compose wrapper, local:start polish, improved agent onboarding
Phase 3 — Public testnet
Testnet contracts, hosted sequencer, persistent agent registration, public explorer
Phase 4 — Security & integrations
Contract + circuit audit, wallet integrations, production monitoring
Phase 5 — Production network
Real settlement rails, decentralized keypers, proved state transitions, Nova reputation, cross-chain (ERC-7683)
Frequently asked questions
Is MANDATE an AI model?
No. MANDATE is a policy enforcement layer that runs alongside an AI agent. It does not generate text, make trading decisions, or replace the agent's reasoning capabilities.
Does MANDATE hold user funds?
In the current MVP, MANDATE operates with test-only keys and a local environment. It does not hold, custody, or transfer real funds.
Can the agent change its own policy?
No. The policy is registered on-chain as a cryptographic commitment before the agent begins operating, and MandateClient refuses to prove against a policy that doesn't open the registered commitment.
Why use zero-knowledge proofs?
ZK proofs let the system verify that an action complies with a policy without requiring the complete policy — or the agent's strategy — to be made public, and they produce a verifiable receipt any party can independently check.
Why not rely only on human approval?
Human approval provides strong oversight but requires a person to be available for every action. MANDATE allows autonomous operation within a pre-approved policy boundary, reserving human decision-making for policy definition.
What happens when an order violates the policy?
The Noir circuit cannot produce a valid proof (nargo execute fails on the violated assertion). Without a valid proof, the order cannot be submitted. The rejection is cryptographic, not a warning or a blocked API call.
Is the current system running on mainnet?
No. The current MVP runs on a local Anvil development chain. All keys, assets, and transactions are for testing purposes only.
Can MANDATE support payments as well as trading?
Yes, in principle. The policy model can express payment constraints — approved recipients, daily limits, per-transaction ceilings. The current MVP uses a trading context; payments are a natural extension.
Why is MCP used?
MCP is an open standard for AI agent tool connectivity. Any compatible agent can connect without custom integration work, and it means the tool surface area is explicitly and narrowly defined.
Is MoonPay required?
No. The MoonPay Agent is the integration demonstration vehicle. MANDATE is designed to work with any MCP-compatible agent.
What information remains private?
The full policy parameters are not published on-chain — only a Poseidon2 commitment is stored. The proof demonstrates compliance without revealing policy values in full.
What happens if the sequencer provides incorrect state?
The state-root verification step fails if the sequencer's reported root doesn't match the on-chain committed root (PortfolioMismatchError). A compromised or stale sequencer cannot enable policy violations — it can only cause liveness failures.
Can a user revoke an agent?
The architecture supports session-key revocation through the Registry contract, preventing further order submission.
Is the system audited?
No. The current MVP has not undergone an external security audit. Contracts, circuits, and the SDK are considered experimental. An audit is planned in Phase 4 of the roadmap.
What is the next milestone?
Public testnet deployment — moving to a publicly accessible chain with a hosted sequencer, persistent agent registration, and simplified onboarding.
Glossary
- AI agent
- A software system that perceives inputs, reasons about them, and takes actions autonomously. Here, one that can call financial tools and APIs.
- Mandate
- The user-defined set of rules that governs what an agent is permitted to do. Analogous to a delegation agreement with explicit boundaries.
- Policy
- The specific rules within a mandate: approved markets, size limits, position caps, loss limits, authorized session keys, and so on.
- Policy commitment
- 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.
- Session key
- A limited cryptographic key that allows an agent to sign order instructions. Scoped to a specific registered mandate; has zero authority over user funds.
- Zero-knowledge proof
- A cryptographic method that allows one party to prove a statement is true without revealing the underlying private information.
- Circuit
- The code-level specification of what must be proven. The Noir circuit encodes the policy constraints an order must satisfy to generate a valid proof.
- Registry
- The on-chain contract (MandateRegistry) that records agent registrations, session key authorizations, and policy commitments.
- Batch auction
- The on-chain execution venue (BatchAuction) where compliant orders are committed during an epoch's commit phase and later processed during the clearing lifecycle.
- Epoch
- A time-bounded auction window. Orders can only be committed during the commit phase of an epoch.
- Sequencer
- The off-chain service that maintains current portfolio state and provides data required for policy evaluation.
- State root
- A cryptographic summary of the entire portfolio state at a point in time, committed on-chain.
- MCP (Model Context Protocol)
- An open standard for connecting AI agents to external tools and services in a structured, discoverable way.
- Circuit breaker
- A system-level safety switch that, when active, allows only strictly risk-reducing orders to be provable.
- Whitelist
- The approved list of markets an agent is permitted to trade. An order for an unapproved market cannot satisfy the circuit.
- Notional value
- The total monetary value represented by an order, calculated as quantity multiplied by limit price.