MANDAOpen control room ↗

MANDA DOCUMENTATION

Permission
is the product.

Manda gives a personal AI agent a narrow payment capability attached to a human-owned smart account. This reference explains what is enforced, what runs offchain, how an agent requests payment, and what has been proven on testnet.

OVERVIEW

A shared identity with separate authority.

The smart account is the payment identity. The human wallet remains its root owner. An AI agent operates through a separate delegated key and can request only the actions allowed by the active mandate. Manda evaluates the request before any UserOperation is submitted.

Core guarantee

The agent does not receive the owner’s private key. A payment outside the recipient, amount, chain, expiry, reserve, approval, or daily-budget rules is rejected before settlement.

HUMAN

Root owner

Creates the account, signs mandates, approves higher-value requests, and revokes delegated access.

SMART ACCOUNT

Shared identity

Holds funds, installs validation modules, and executes ERC-4337 UserOperations.

AI AGENT

Bounded delegate

Signs narrow payment intents using a separate service-side key.

POLICY ENGINE

Decision point

Checks every request and records an attributed success or rejection reason.

AUTHORITY MODEL

Ownership stays singular. Capability is delegated.

Manda combines onchain validation with runtime policy controls. The installed account modules bind the delegate and a cumulative spend ceiling. The authenticated agent service adds daily accounting, recipient checks, per-payment caps, approval thresholds, balance reserves, expiry, chain binding, and replay protection.

Why both layers exist

Onchain rules provide a hard account boundary. Runtime rules provide detailed operational controls and clear rejection reasons without pretending every policy field is enforced by the chain itself.

PAYMENT LIFECYCLE

From intent to evidence.

  1. The agent creates a payment intent

    The request specifies a unique request ID, chain, recipient, and amount in wei.

  2. The service authenticates the caller

    A trusted agent runtime uses the local bearer token. Browser control uses a short-lived owner-signed session.

  3. The active mandate is evaluated

    Manda checks identity, status, expiry, destination, amount, daily spend, reserve, chain, replay, and approval requirements.

  4. An approved UserOperation is submitted

    Eligible Arbitrum operations use Candide sponsorship. Robinhood Chain operations use Alchemy Bundler and Gas Manager.

  5. The outcome is recorded

    The activity ledger stores the actor, intent, policy result, network, and transaction evidence where a transaction exists.

POLICY REFERENCE

The mandate fields that matter.

FieldPurposeEnforcement
recipientSingle approved service or destination address.Runtime and installed hooks
perPaymentWeiMaximum value allowed for one request.Runtime
dailyLimitWeiTotal confirmed and pending spend allowed per UTC day.Runtime ledger
approvalThresholdWeiValue above which the owner must sign a fresh approval.Runtime signature verification
balanceFloorWeiMinimum account balance that must remain after payment.Runtime chain read
expiresAtTime after which the mandate cannot authorize a request.Runtime and module configuration
chainIdNetwork on which the policy is valid.Runtime
entityIdInstalled Modular Account validation entity.Onchain

AGENT API

A narrow tool surface.

The agent does not call arbitrary wallet methods. It sends a constrained payment request to the local service.

{
  "requestId": "agent-run-unique-id",
  "chainId": 421614,
  "recipient": "0x...",
  "amountWei": "100000000000"
}
SESSION

POST /auth/challenge

Creates a short-lived message for the connected owner to sign.

SESSION

POST /auth/verify

Verifies the owner signature and returns an authenticated session.

POLICY

GET /policy

Returns the active policy for the requested supported chain.

PAYMENT

POST /pay

Evaluates and, when allowed, executes a payment through the delegated key.

ACTIVITY

GET /activity

Returns scoped policy decisions and confirmed transaction evidence.

NETWORK EVIDENCE

One address. Two independent deployments.

The same deterministic Modular Account V2 address is deployed on both test networks. Each chain maintains its own mandate, balance, allowance, and transaction history.

SECURITY BOUNDARIES

What the implementation protects.

KEYS

Secrets remain server-side and untracked

Agent keys, service tokens, owner pins, ledgers, environment values, and policy-state files are excluded from Git.

AUTH

Private routes require authenticated callers

Payment, policy, and activity endpoints accept an agent bearer token or a verified owner session.

REPLAY

Request IDs are single-use

Confirmed, pending, and terminally rejected requests cannot be silently replayed.

SPEND

Pending requests reserve daily capacity

Concurrent attempts cannot overrun the daily budget while an earlier operation is settling.

OWNER

Revocation requires the connected owner

The implementation removes the validation entity and associated hooks on the policy’s chain.

LOCAL DEVELOPMENT

Run Manda locally.

Use Node.js 20 or newer. Copy the example environment file and add an Alchemy application key and Gas Manager policy ID.

Install dependencies npm install
Start the frontend npm run dev
Start the agent service npm run agent:serve
Run the policy suite npm test
Create a production build npm run build
Production serving

Run the agent service and npm start. The Node server keeps Alchemy credentials and agent routes off the browser surface.

CURRENT LIMITS

What remains intentionally unfinished.

Prototype boundaries

  • Live owner-signed revocation has not been executed because it would disable the active demo mandates.
  • Cross-chain bridging and automatic rebalancing are outside the critical payment path.
  • The current agent service is a single-owner local prototype and is not a multi-tenant production custody system.
  • Token support beyond native testnet value has not been claimed or demonstrated.