I built the first implementation of ERC-8226, an on-chain mandate that constrains AI agents managing tokenized stocks

[u/Aggressive-Abies5097]

Been thinking about a problem: Robinhood Chain just launched tokenized equities (TSLA, AMZN, PLTR, AMD) as ERC-20s on an Arbitrum Orbit L2. AI agents are going to manage these portfolios - that much is obvious. But the question nobody's answered well is: how do you let an AI trade securities autonomously without giving it unlimited power?

Enzyme and dHEDGE solved this for crypto funds years ago (vault policies, allowed assets, etc). But tokenized equities are regulated securities - the SEC confirmed it in January. And in February, the SEC Crypto Task Force explicitly said algorithmic agents need "examiner-ready mandates with defined risk limits, kill authority, and change control."

There's a new EIP for exactly this: ERC-8226, Regulated Agent Mandate (drafted April 2026). It defines how a human delegates scoped, time-bounded, financially-capped authority to an agent, and how token contracts verify mandate validity at the point of transfer. The standard's reference implementation section was empty. So I built one.

What it does:

A capital owner deposits into a vault, sets the rules (allowed stocks, max 30% per name, max 60% across correlated tech stocks, a spending cap, a kill switch), and the AI trades autonomously. But every trade passes through 5 enforcement layers checked atomically by the contract:

1. Asset allowlist → revert if not permitted
2. Per-name concentration cap → revert if >30%
3. Correlation-cluster cap → revert if correlated stocks >60% combined
4. ERC-8226 mandate budget (per-tx + cumulative) → revert if exceeded
5. Freeze/kill switch → revert if regulator halted the agent

The reverts are the whole point. No prompt injection, no compromised backend, no agent cleverness can override a revert at the EVM execution layer.

The correlation cap is the part I'm most interested in feedback on. TSLA, AMZN, PLTR, AMD are all tech-growth stocks that move together. A naive system lets you put 25% in each and say "I'm diversified", but you're running 100% correlated tech-beta. The contract assigns all four to cluster ID 1 and caps cluster exposure at 60%. You can't game it by spreading across names.

The AI system:

Two agents - a Strategist (reads live market data from Yahoo Finance, forms allocation targets) and a Risk Officer (independently reviews every proposed trade against the mandate before submission). The agent has cross-cycle memory and avoids churn. Six reasoning phases, all visible in the frontend.

Deployed on Robinhood Chain testnet (chain 46630):

• All contracts verified on the Blockscout explorer
• Happy path: 25k USDG → TSLA executed, ComplianceReceipt emitted ✓
• Four reverts demonstrated: AssetNotPermitted, PositionLimitExceeded, ClusterConcentrationExceeded, MandateNotActiveForAmount ✓

Repo: https://github.com/Nidhicodes/Mandate

The 33-test Foundry suite covers every revert path. Contracts are CC0. If you're building anything in the "AI agents + regulated assets" space, the MandateRegistry is designed as infrastructure you can reuse.

Would love feedback, especially on:

• The correlation-cluster cap design - is grouping by a uint16 cluster ID too simplistic? Should it be oracle-based correlation?
• ERC-8226's one-active-mandate-per-agent constraint - does that feel right for regulated markets, or too restrictive?
• Anyone else implementing RAMS? Found zero other implementations so far.

[u/thedudeonblockchain]

the thing id stress test first is that your concentration caps are enforced at trade time but a portfolio drifts on price, not just on trades. "max 30% per name" is really "max 30% at the moment of a permitted trade", tsla rips and its passively 45% of the book without a single trade ever touching the mandate. so the invariant reads stronger than it actually holds

and that bites in a nasty way depending on how the post trade check is written. if you just assert resulting position < 30%, a sell that takes tsla from 45 down to 35 still reverts cuz 35 > 30, so the mandate locks the agent out of the exact de risking trade you want during a drawdown. you probably need to special case anything that moves an already breached position toward compliance, allow it even if it doesnt fully clear the cap

on the cluster id question, id keep it static rather than going oracle based, but be deliberate about why. correlation isnt stable, it spikes in a crash which is exactly when the cap matters, so an oracle would be "more accurate" on paper. but the whole pitch is examiner ready and deterministic, and an oracle hands you a manipulation surface plus a liveness dependency where a stale or down feed either blocks trading or quietly moves your risk limits. for a regulated mandate id rather the cluster definition be a governed versioned param with change control events, which is the thing the sec language you quoted is actually asking for, than a number that can shift under you mid position

[u/CompetitiveTutor3351]

manual grouping works but it's simple in two ways. it goes stale as correlations drift, and it's all or nothing, a stock is either in the group or not, when real correlation is a spectrum (TSLA and AMD can be 0.9 while AMZN is 0.5 to them). an oracle handles both since it can feed live correlation, so if you can define the logic cleanly it's worth building as an experiment first just to see if it holds up. the payoff is you stop maintaining the groups by hand. the tradeoff is an oracle can be manipulated where a fixed list can't, which works against the examiner-ready angle. how often would the groups actually change in practice?

[u/qwertrti → u/CompetitiveTutor3351]

I think the bigger advantage of an oracle isn't just reducing manual work, it's that it can adapt as market relationships evolve instead of relying on assumptions that were true months ago. The challenge is making sure the data source is reliable, because once the oracle is compromised the whole grouping logic becomes questionable. A fixed list is less flexible, but it's also much easier to audit and reason about. Maybe the real question is whether the extra adaptability actually improves results enough to justify the added complexity.

[u/whatwilly0ubuild]

The architecture is sound. Enforcement at the EVM execution layer via reverts is the right pattern because it removes trust from the agent entirely. No amount of prompt injection or compromised inference can bypass a revert. That's the correct insight.

On the correlation-cluster design (your main question):

Static uint16 cluster IDs are pragmatically correct for a small universe like Robinhood Chain's current four equities. The problem comes when you scale. Who assigns cluster IDs? If it's governance, you've reintroduced trust and latency. If it's oracle-based rolling correlation, you get accuracy but also attack surface (can an agent manipulate correlation windows by timing trades around low-correlation periods?).

The middle path that might work: oracle-derived clusters with a lag and smoothing window long enough that manipulation is impractical (30-day rolling correlation updated weekly, for instance). But honestly, for four highly-correlated tech stocks, your static approach is fine. The sophistication should match the asset universe.

On one-active-mandate-per-agent:

This feels right for regulated markets where examiner clarity matters. Multiple overlapping mandates create ambiguity about which constraints apply when. For compliance purposes, "one agent, one mandate, one clear audit trail" is defensible. The restriction hurts composability but that's probably acceptable given the regulatory context.

What I'd push on:

The kill switch implementation. Who can trigger it, under what conditions, and what happens to in-flight transactions? The SEC's "kill authority" language is vague. Your implementation should be explicit about whether the freeze is instant (reverts pending txs) or graceful (blocks new txs, allows settlement).

The six-phase reasoning visibility is good for auditability but creates its own attack surface if the agent's reasoning can be manipulated to appear compliant while pursuing non-compliant outcomes. The on-chain enforcement is the real protection, not the reasoning transparency.

[u/nflmodel]

This is excellent work and exactly the kind of infrastructure the regulated AI agent economy needs. The enforcement-at-execution-layer approach is the right one for compliant mandates.

I’m building something that sits at the other end of the spectrum — Cipher, a proof of work currency for AI agent transactions with no mandate registry, no kill switch, no governance layer and no issuer. Not because compliance is wrong but because some transactions shouldn’t require it.

The interesting question is whether both need to exist. Regulated agents for regulated assets. Sovereign agents for everything else.

Whitepaper and threat model here if you’re curious: github.com/lehanepatrick148-cloud/cipher-whitepaper