ERC-8226: Regulated Agent Mandate

Дата публикации: 14-08-2026 16:57:20

Coming from the map thread, where @VladKuzR said the enum is going into the next revision. One data point that might be worth having before it closes, from an enforcement layer that was written without any contact with this thread.
I maintain ERC-8370 — inheritable agent mandates, a different problem — but its enforcement gate has exactly the shape this enum describes: a boolean answer that throws away the branch that produced it. Four checks, in order, each with its own revert:
require(mandate.isActive(a.agentId), "agent not active");
require(mandate.payeeAllowed(a.agentId, a.payee), "payee not allowed");
require(spent[a.agentId] + a.amount <= effectiveCap(..),"over effective cap");
require(a.amount <= room(a.agentId), "insufficient room");
Deployed and source-verified on Base Sepolia. Three of the four map onto your set without argument — isActive splits into AGENT_FROZEN and OUTSIDE_VALIDITY_WINDOW, payeeAllowed is close to TOKEN_NOT_ALLOWED in spirit, the cap check is OVER_CUMULATIVE_CAP.
The fourth one has no equivalent in your list, and I think that is the useful part.
insufficient room is not a cap. It is funds actually credited to this agent, minus what it has spent, minus what it has returned. An agent can be well inside its authorized ceiling and still be refused because nobody has funded it — or because it already sent the money back up its lineage. Authorization says yes; the purse is empty.
That distinction only appears once authorization and custody are separated, which RAMS also does — your registry authorizes and holds nothing. So a RAMS-aware token can hit the same condition: the mandate is valid, cumulativeUsed is well under maxCumulativeValue, and the transfer still fails on the token’s own balance or allowance. Today that would come back as OTHER, or as a plain revert with no reason at all, and a wallet cannot tell the user whether to top up or to ask for a new mandate — which is precisely the case @Anzus_GemWallet described: should I retry, or is something actually wrong? Those two have opposite answers.
Whether it belongs in the enum is your call, and there is a real argument that it does not: it is arguably the token’s condition, not the mandate’s. But if it is left out, the spec should probably say so explicitly rather than let integrators fold it into OTHER — that is the same failure the enum exists to prevent, one layer down.
On “first failing check wins”: agreed, and worth stating as a MUST rather than a SHOULD. Two implementations that report different reasons for the same call are worse than two that report nothing, because the second case is at least honestly useless.
Separately, @a-laz — reading your integration post above, we appear to have converged on the same discipline from opposite ends: publish the transaction hashes and the block-boundary reads, and let anyone recompute the cause rather than take the writeup’s word for it. That is not common, and it is good to see.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	A map of the agent-mandate ERCs — what each one actually does	0	11.48	14-08-2026
2	ERC-8370: Inheritable Agent Mandates	0	8.79	14-08-2026
3	ERC-8354: Confidential Agent Policy Verdicts	0	12.87	24-07-2026
4	EIP Editing Office Hour (EIP + ERC ) Meeting #111, Aug 18, 2026	0	18.71	13-08-2026
5	ERC-8337: Agent Memory State	0	7.65	26-07-2026
6	ERC-8343: Contract Deactivation	0	15.62	21-07-2026
7	Preserving censorship resistance for BAL data in EIP-7999	0	6.62	14-08-2026
8	Proposing a family of candidate ERC interfaces for titled asset infrastructure — architecture review	0	7.85	27-07-2026
9	ERC-8004: Trustless Agents	0	7.85	13-08-2026
10	[IDEA] Native Ethereum Delegation (NED) - Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification	0	13.6	13-08-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 8.97. Источник: ethereum-magicians.org.