MANDATE separates intelligence from authority. Agents may research, reason and propose. Authority remains inside a user-owned account whose rules are evaluated before execution.

A user describes what their capital should do in ordinary language. MANDATE compiles that instruction into an explicit portfolio policy, places it inside a non-custodial smart-account interface, and allows agents to submit portfolio actions that must pass the policy before they can be authorized.

Your agent can think freely. It cannot move outside the mandate.

Delegating capital to software usually means delegating authority to software. The instruction and the execution collapse into the same trusted component, and the owner is left auditing outcomes rather than constraining behaviour.

MANDATE takes the opposite position. Specifically:

• Natural-language intent is not itself trusted.
• Intent is compiled into deterministic policy.
• Users inspect and authorize the compiled clauses.
• Agent keys have scoped permissions.
• Proposals are simulated and evaluated before they can execute.
• Invalid actions are rejected with a machine-readable reason.
• Valid actions can still require human approval.

The result is that an agent’s reasoning quality determines its returns, and the policy determines its blast radius. Those two properties are decoupled by construction.

The compiler is rule-based and deterministic: the same sentence always produces the same clauses, and every clause can be traced back to the span of text that produced it. No model call sits between what you wrote and what you authorize.

Build me a concentrated AI infrastructure portfolio.
Hold 8-12 profitable companies.
Never allocate more than 15% to one company.
Keep at least 10% in USDG.
Rebalance weekly.
If drawdown reaches 8%, rotate half into QQQ.
Never execute through more than 25 bps of slippage.

universe.allow(NVDA, AMD, AVGO, TSM, ASML, MSFT, GOOGL, AMZN, ANET, VRT, MU, DELL)
count.between(8, 12)
position.max_weight(15%)
reserve.min(USDG, 10%)
schedule(weekly) | drift(5%)
on_drawdown(8%) -> rotate(equity, QQQ, 50%)
execution.max_slippage(25bps)
oracle.max_age(60s) -> halt
approval.auto_below(250000 USDG)

Nine clauses are produced. Eight of them are enforceable per-proposal checks; the ninth, the approval threshold, routes a valid proposal to either automatic execution or owner review.

The PolicyVM takes a proposed portfolio and the authorized policy and returns a decision plus a reason code. It is pure: the same inputs always yield the same output, which is what makes a rejection explainable rather than opinionated.

{
  "proposalId": "0x8f…c41",
  "approved": false,
  "failureCode": "MAX_POSITION_15%",
  "failureReason": "NVDA at 22.0% exceeds the 15% limit",
  "checks": [
    { "id": "oracle",               "status": "pass" },
    { "id": "universe",             "status": "pass" },
    { "id": "asset-count",          "status": "pass" },
    { "id": "max-position",         "status": "fail" }
  ]
}

Evaluation stops at the first failure. A partially valid proposal is not partially executed — there is no state in which some legs settle and others do not.

Authorizing an agent grants a capability set, not a signing key over the account. The denied capabilities below are structural: they are not exposed as options anywhere in the product, and no policy can enable them.

Operators post a bond in USDG. Repeatedly submitting proposals designed to breach a policy is economically penalised, which keeps acceptance rate meaningful as a ranking signal.

Proof of Constraint is the record that a specific proposal was evaluated against a specific policy hash and produced a specific decision. It contains the input portfolio, the proposed portfolio, the price references and their age, the simulated slippage, and the result of each of the 8 checks.

Because the policy hash is included, a receipt cannot be reattributed to a different policy after the fact. Editing any clause rotates the hash and invalidates the previous authorization.

Eight constraints. One authorized path.

Every proposal is simulated against reference liquidity before it is evaluated. The simulated slippage is itself a clause input, so an otherwise valid rebalance can be rejected purely because the market cannot absorb it inside the mandate’s tolerance.

• Oracle age is checked first. Stale data halts execution rather than degrading it.
• Slippage is estimated per leg and aggregated against the policy ceiling.
• Approved proposals settle at the next execution window.
• Rejected proposals return to the agent with the failing reason code.

Accounts hold Stock Token units. Portfolio weights are derived at evaluation time from units and the reference price, never stored, so a stale weight cannot be used to satisfy a clause.

The reserve is denominated in USDG, the canonical dollar asset on Robinhood Chain. Gas is paid in ETH.

chainId        4663
nativeCurrency ETH
USDG           0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168
explorer       https://robinhoodchain.blockscout.com

Authorizing a mandate produces an EIP-712 typed-data signature over the policy configuration. It moves no funds, grants no token allowance and is not a transaction. In this release no MANDATE contract is deployed, so nothing is broadcast and no transaction hash exists.

domain = { name: "MANDATE", version: "1", chainId: 4663 }

MandateAuthorization {
  address owner
  bytes32 mandateId
  bytes32 policyHash
  uint256 capitalLimit
  bool    automaticExecution
  uint256 deadline
  uint256 nonce
}

Cloning a public mandate installs the same policy into a new segregated account. It is not a pooled deposit and no capital moves between the original and the clone.

The product has not been audited. Nothing on this site is described as audited, verified onchain or live beyond what is actually true: the wallet connection, the network configuration and the signature are real; the strategy history is illustrative.

Three flows are metered at the protocol level, and each maps to something an owner can observe:

• Agent bonds. Operators post USDG to compete for mandates. Bonds are slashable for repeated deliberate policy breaches.
• Evaluation fees. Each proposal evaluation carries a small fee, which is what makes spamming a mandate with invalid proposals expensive.
• Publication. Publishing a policy so others can clone it is permissionless; the publisher receives a share of evaluation fees from clones.

None of these flows give the protocol custody of user assets at any point.

An agent submits a proposed portfolio; the interface returns a full evaluation. The client-side validator in this release exposes the same shape a deployed PolicyVM would.

import { evaluateProposal } from '@/lib/policy-validator'

const result = evaluateProposal(policy, {
  id: 'proposal-1',
  agentId: 'vector-research',
  submittedAt: '14:02:11',
  intent: 'Weekly rebalance toward target weights',
  allocations: [{ symbol: 'NVDA', weightPct: 14.8 }, /* … */],
  reservePct: 10.4,
  expectedSlippageBps: 17,
  oracleAgeSeconds: 3,
  turnoverPct: 12,
})

if (!result.approved) {
  console.log(result.failureCode)   // MAX_POSITION_15%
  console.log(result.failureReason) // NVDA at 22.0% exceeds the 15% limit
}

NEXT_PUBLIC_ROBINHOOD_RPC_URL=
NEXT_PUBLIC_WALLETCONNECT_PROJECT_ID=
NEXT_PUBLIC_MANDATE_FACTORY_ADDRESS=

Wallet connection works through any injected or EIP-6963 provider without an RPC key. When an endpoint is configured, balances are read directly; when it is not, reads are routed through the connected wallet.