A map of the agent-mandate ERCs — what each one actually does

ERCs
1

Corrected 14 August. The ERC-8226 row originally described its enforcement as taking
place in a regulated token’s pre-transfer hook. That is one of three venues its
specification defines, not the definition — corrected below after @thamerdridi pointed it
out. Thread activity figures are still as collected on 13 August.

If you are trying to work out how to bound what an autonomous agent may do on-chain, you
will find a dozen ERCs that sound like they answer the question. Most of them answer a
different one. Working out which is which took me a week, so here is the map, with the
method attached so you can check it rather than trust it.

This is not a critique of anyone’s work. Several of the standards below deliberately
exclude what I was looking for, and say so.

Method

Titles are misleading in this space — “agent”, “delegation” and “permission” appear in
proposals that have nothing to do with each other. So I ranked the corpus by content.

Every ERC in ethereum/ERCs was listed (611 files), those numbered ≥ 7000 kept
(271), their full text downloaded (~5.1 MB) and scored against 11 concept patterns:
delegation, attenuation, sub-agent, inheritance, cap, revocation, expiry, identity,
AI-agent, caveat, session. The top of that ranking was then read end to end —
specification and discussion thread, not abstracts. Five threads, 73 posts.

The ranking is a filter, not a verdict. ERC-7303 scored third and is a false positive —
token-based role access control, nothing to do with agents.

Scope limit, stated up front. The corpus is the merged ethereum/ERCs tree. Open
pull requests and forum-only drafts are outside it — ERC-8165 (PR #1549, open since
February) is one such case, and it sits on the intent/solver layer rather than this one.

The map

(thread activity as of 13 August 2026)

ERC What it actually does Status Thread
8226 Regulated Agent Mandate A principal grants a scoped, capped, time-bounded mandate to one agent. Per-transaction and cumulative caps, freeze, compliance provider. Enforcement is venue-agnostic: a regulated token’s pre-transfer hook, an EIP-7702 delegated account, or a dedicated executor — all read the same mandate. Draft live — 12 posts, last 2026-08-12
8196 AI Agent Authenticated Wallet Executes only with cryptographic proof that the action complies with an owner-defined policy. Hash-chained audit trail, entropy commit-reveal against host manipulation. Layer 2 of a stack with ERC-8126. Final 14 posts, last 2026-07-20
8199 Sandboxed Smart Wallet Containment by isolation: the agent’s wallet fully detached from the owner’s, the relationship one-directional. Draft dormant — 2 posts, 93 views
8273 Attestation-Gated Agentic Actions Per-operation attestation, authorized in EIP-1153 transient storage and cleared at the end of the transaction. Draft —
7715 Request Permissions from Wallets The request side: a JSON-RPC method for a dapp to ask a wallet for permissions. Requires 4337 and 7710. Draft 10 posts, last 2026-04-29
7710 Smart Contract Delegation A single function, redeemDelegations, for redeeming a delegation against a Delegation Manager. Draft dormant — 35 posts, 6.2k views, last 2025-04-30

Three things that are easy to get wrong from the abstracts:

8273 is not a session system. Its own text: “There is no expiration mechanism, and
there are no long-lived or session-based attestations.” Authorization exists for one
transaction. If you need state that outlives a call, this is the wrong axis — not a weaker
version of the right one.

7710 does not specify caveats. The ERC is one function. Caveat enforcement, delegation
chains and revocation appear only as features of the MetaMask Delegation Framework, its
reference implementation. The standard also declares acquisition out of scope: “The
process by which a delegate obtains a delegation is intentionally left out of scope.” Its
Security Considerations section currently ends with Needs discussion. <!-- TODO -->.

8196 is Final. Whatever you think of it, it is not going to change.

The empty square

None of the 271 standardizes attenuated re-delegation: a child agent that comes into
existence already bounded by its parent, on every clause, with the bound non-strippable.

The closest candidate is ERC-8226, and it is worth being precise about why it is not that.
Its mandate is keyed by (agent, principal); only the principal can grant. An agent holding
a valid mandate cannot create anything. Searching its reference implementation for the
vocabulary of lineage —

grep -rniE "child|parent|sub-?agent|inherit|lineage|spawn|attenuat" contracts/ test/

— returns only @inheritdoc, a Solidity documentation tag. The concept is absent from the
code, not merely from the prose.

That is not a defect. @thamerdridi made the point directly on my own thread, and was
right to: a spawned child inherits nothing under RAMS, including the authority to act, so
reproduction cannot be used to escape a mandate. Inheritance is out of scope by design. The
honest phrasing is “ERC-8226 does not define mandate inheritance”, not “ERC-8226 can be
bypassed.”

The same care applies to the others. 8199 refuses granular sharing on principle, arguing
that session-key-style approaches “inherently bring in permission evasion issues”. 8273 is
transaction-scoped by construction. 7715 is a request protocol, not an enforcement layer.
None of these is an oversight; they are four different answers to four different questions.

The square is empty because nobody has claimed it, not because everybody missed it.

Reproduce it

gh api repos/ethereum/ERCs/contents/ERCS --paginate | jq -r '.[].name'
curl -sL https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-8226.md
curl -s "https://ethereum-magicians.org/t/28208.json?include_raw=true&print=true"

ERC-8226’s reference implementation compiles and its own test suite passes — 72 tests, 0
failures — with OpenZeppelin resolved from master (the v5.1.0 tag does not exist) and
forge-std supplied locally. Worth doing: reading a specification and running it are not
the same activity, and the second one is cheap.

Disclosure

I work on ERC-8370, which is an attempt at the empty square. That is why I read all of
this, and you should weigh the map accordingly — though every claim above is checkable with
the three commands in the previous section, which is rather the point.

Corrections welcome, especially from the authors of anything listed here. If I have
mischaracterized your standard’s scope, say so and I will fix it — the version I keep
updated lives at interop/standards-map.md in the ERC-8370 repository.

2

Thanks for putting this map together. It makes the differences between these proposals much easier to understand.

From a user-facing wallet perspective, which of these standards do you think users are most likely to encounter first? For example, would it appear as a permission request, a spending limit, or a warning before an action?

It would be interesting to understand how these ideas may eventually translate into something ordinary wallet users can recognize.

3

Thanks, Helmy, for the rigorous comparison and for testing the reference implementation. The inheritance distinction is framed accurately.

One technical correction to the ERC-8226’s “What it actually does”: RAMS is enforcement-venue agnostic. A regulated token’s pre-transfer hook is one integration path, but the same mandate and canExecute semantics can also be enforced through a dedicated executor or an EIP-7702 delegated account.

Happy to compare notes or clarify any other aspects of the RAMS architecture.

4

You’re right. RAMS is venue-agnostic — the token hook is one of three venues your spec defines, not the definition. Corrected in the post above and in the maintained version, with the change noted rather than made silently.

On comparing notes: there is one place where I think I have something to offer rather than ask. Your June update left a question open that I don’t think anyone has answered — whether the venue-agnostic model holds up for EIP-7702 delegated accounts, and what account-abstraction edge cases need explicit handling.

ERC-8370 splits the same two things you do: the mandate lives in one contract, its enforcement in a gate that consults it. So the venue question lands on me in the same shape, with lineage where you have a compliance provider. I have a gate and a registry deployed on Base Sepolia that have been through that split in practice, including the parts that went wrong. Happy to write up what the separation actually costs at the enforcement boundary, if that’s useful input on your open question.

5

Good question, and the map answers it without quite saying so: only one of these is user-facing at all.

ERC-7715 is the request side — a JSON-RPC method a site calls to ask a wallet for permission. That is the one your users would actually see, and it would look like a permission prompt.

Every other standard on the list is enforcement. Users never see them; they hit them. The experience is not a dialog, it is a transaction that fails.

Two things follow, and both matter more for a wallet than the taxonomy does.

The user-facing path is the least developed of the set. ERC-7715 requires ERC-7710, and 7710’s discussion thread has had no activity since April 2025, with an unresolved Needs discussion marker still sitting in its Security Considerations. If wallets want a standard permission-request flow, that is where the work is missing — not in the enforcement layer, which has four active proposals competing.

And the thing you will need most does not exist yet: a reason. An enforcement standard answers with a boolean. When it says no, the wallet has nothing to show the user beyond a failed transaction — was the mandate revoked, expired, over its cap, or aimed at the wrong asset? The check knows; the answer throws it away.

That is being worked on right now, and your input would count: on the ERC-8226 thread two days ago, @VladKuzR proposed an ExecutionReason enum mapped one-to-one onto the branches of the authorization check, with a rule that the first failing check is the one reported so that two implementations answer identically. That proposal is live and unanswered. It is the difference between your users seeing “transaction failed” and seeing “this agent’s spending limit is used up” — and a wallet team saying so while the enum is still being designed is worth more than any of us specifying it from the enforcement side.

1 Like
6

Thanks, this is very helpful. From a user-support perspective, a generic “transaction failed” message often leaves users unsure whether they should retry or whether something is actually wrong.

Clear reasons such as permission expired, permission revoked, spending limit reached, or wrong asset would make the wallet experience much easier to understand. It would also be helpful if these reasons were consistent enough for wallets to translate into simple, user-friendly messages.

7

Thanks @helmymekaoui-web, good summary of where this landed. The ExecutionReason enum is going into the next revision of the ERC-8226 draft, with canExecute returning (bool allowed, ExecutionReason reason) so each enforcement branch maps to one reason code. @Anzus_GemWallet since you raised the wallet UX angle, feedback on the reason taxonomy from wallet and agent-framework teams would be exactly the input we’d love to hear. The draft discussion lives here: ERC-8226: Regulated Agent Mandate

3 Likes
8

The method is the useful part here, especially publishing the concept patterns so the ranking can be rerun rather than taken on trust.

One thing the eleven patterns cannot see. Delegation, attenuation, cap, revocation, expiry, session and the rest all describe the shape of an authority envelope, which is a standing property of the grant. None of them index whether a specific action was evaluated against a policy at the moment it executed. Those are different axes, and a proposal can sit on the second one without scoring on any of the eleven.

It matters for the map because the two compose rather than compete. A mandate bounds what an agent may ever do. A per-action check decides whether this particular action clears the rules right now, inside that envelope. If the corpus is scored only on envelope vocabulary, the second class stays invisible even where it is present.

This is not a complaint about coverage. Your scope limit is stated up front and open PRs sit outside it, which is a defensible line to draw. It is the pattern list I would extend, since that is what decides what the next run is able to find.