ERC-8226: Regulated Agent Mandate

ERCs
,
1

UPDATE (June 29, 2026): Spec refinements and reference implementation now live in PR #1844. See the update post below for the full change list and our position on the custody open question.

Authors:** Ludovico Rossi, Dario Lo Buglio, Thamer Dridi, Nabil El Alami Khalifi
GitHub PR: Add ERC: Regulated Agent Mandate by thamerdridi · Pull Request #1679 · ethereum/ERCs · GitHub
Status: Draft

RAMS defines a compliance delegation layer for AI agents operating on tokenized regulated assets. It is agnostic to the agent identity system and the token compliance framework: it works with any agent registry that maps wallet addresses to agent identifiers (such as ERC-8004) and any regulated token standard that implements a pre-transfer compliance check (such as EIP-7943 or ERC-3643).

No existing standard addresses what happens when an AI agent executes a transaction on a regulated financial instrument — a tokenized security or real-world asset subject to KYC, AML, or investor eligibility requirements under frameworks such as MiCA, VARA, or MiFID II.

RAMS closes this gap by specifying:

  1. Mandate delegation. How a verified principal delegates scoped, time-bounded, and financially capped authority to an on-chain agent — analogous to a power of attorney in traditional finance.

  2. Dual compliance check via pre-transfer hook. How RAMS-aware regulated tokens verify mandate validity through their existing pre-transfer compliance hook, executing two checks in sequence: first the token’s own investor eligibility on the principal (the token’s compliance module is never bypassed), then the RAMS mandate validity on the agent. The token issuer retains full sovereignty over who may hold or transact their instrument.

  3. Unified compliance provider. A single IComplianceProvider interface for principal eligibility verification (identity + compliance in one call), with structured reason codes for audit trails.

  4. Jurisdiction-scoped enforcement. Two-tier enforcer roles (PLATFORM vs REGULATORY) with freeze authority scoped by jurisdiction. Global freeze is restricted to REGULATORY tier only.

The standard defines two interfaces: IComplianceProvider (external compliance contract) and IAgentMandate (RAMS registry). Each agentId has exactly one active principal at a time, mirroring the account segregation requirements of MiCA (Article 70), MiFID II (Article 16), and VARA. Agents use standard ERC-20 transfer and transferFrom — no agent-prefixed function variants are required on the token side. No modifications to any existing standard are needed.

Open topics

The following topics are intentionally left open for community input:

Token ownership and custody model. When an agent acquires tokens on behalf of a principal, who is the registered owner? Two models are under consideration:

  • Agent-custodied: tokens are held by the agent wallet. Beneficial ownership is tracked via the RAMS registry and ExecutionRecorded events. Suits high-frequency trading strategies where the agent needs direct control.
  • Principal-custodied: tokens are transferred or minted directly to the principal’s address. The agent orchestrates the trade but settlement is principal-to-principal. Produces a clean investor registry by default. Suits long-term investment strategies.

Both models are compatible with RAMS mandate verification. We are seeking input on whether the standard should prescribe a default or remain agnostic.

Receive-side compliance. The current specification covers agent-initiated outbound transfers (selling, moving). For inbound transfers (buying), the token’s canTransact must verify the receiver. If the receiver is the agent wallet rather than the principal address, the token must determine whether to apply investor eligibility checks to the agent or to the principal. This is closely related to the custody model.

regulatoryCompliance trust signal in ERC-8004. We suggest a regulatoryCompliance value in the supportedTrust field of the ERC-8004 registration file, as a signal that an agent operates under a certified mandate for regulated transactions. This would require no changes to the ERC-8004 core spec.

We welcome feedback on the dual compliance check pattern, the IComplianceProvider interface, the one-active-principal constraint, and the open topics above.

9 Likes
2

One question I still have is about the compliance/verifier layer.

The proposal explains how a compliance provider can validate principals and support RAMS enforcement, but what are the safeguards around the compliance providers themselves?

If these providers become the trust anchor for regulated agents, how do we prevent capture, corruption, or excessive centralization over time? In other words, who verifies the verifiers?

1 Like
3

@TrendAdmin Great question, and it goes to the heart of the trust architecture. RAMS addresses this at three levels:

  1. Principal sovereignty over provider selection.

The compliance provider is not a system-wide singleton. The principal selects the complianceProvider address at grantMandate time. This means multiple compliance providers can coexist and compete. A principal working under MiCA may choose a regulated EU KYC provider; another operating under VARA may choose a different one. If a provider is compromised or underperforms, the principal revokes the mandate and re-issues it with a different provider. The market disciplines the providers, not a central authority.

  1. Two-tier enforcement independent of provider state.

RAMS defines a two-tier enforcer model (PLATFORM and REGULATORY). The registry operator assigns these roles to specific addresses as part of deployment. An address with REGULATORY tier can freeze an agent globally regardless of what the compliance provider reports. This means the enforcement mechanism exists independently of the compliance provider: even if a provider is captured and keeps returning COMPLIANT, an enforcer can halt the agent directly through the RAMS registry. In practice, platforms operating under regulated frameworks (MiCA, VARA) would be expected to assign REGULATORY tier access to the competent authority as part of their licensing obligations.

  1. The token’s own compliance is never bypassed.

*This is the most important safeguard. RAMS adds a second compliance layer but does not replace the first. The token’s own investor eligibility check (via its pre-transfer hook) runs on the principal before RAMS mandate validity is even evaluated. A compromised RAMS compliance provider cannot grant access to a token whose issuer has independently determined that the principal is ineligible. The token issuer retains full sovereignty.

What RAMS intentionally does not prescribe is the internal governance of a compliance provider: how it manages its KYC data, what audit standards it follows, or how its upgrade mechanism works. The spec recommends (SHOULD-level) that principals select providers with audited, time-locked upgrade mechanisms and documented uptime SLAs. But the standard does not enforce this because compliance provider governance is a regulatory matter, not a protocol matter. Different jurisdictions will impose different requirements on these entities, and RAMS should not constrain that.

The short answer to “who verifies the verifiers”: the principal (by choosing and switching providers), the registry operator (by assigning enforcement roles), and the token issuer (by never ceding their own compliance checks). No single actor has unchecked authority.

That said, this is exactly the kind of design tension we want pressure-tested. If you see a scenario where these three layers still leave a gap, we would rather hear it now than after deployment. What attack vector concerns you most?*

1 Like
4

Nice work on RAMS. The compliance delegation model maps cleanly to what we’re building with ERC-8240.

Concrete composability: a RAMS IComplianceProvider can consume IAttestation.getAttestation(subject) as one eligibility input — the compliance check becomes quality-aware without changing either interface. Add IRiskSignal.getRegime() as a second input: same principal might pass under STABLE regime but get restricted under CRISIS.

Two calls, two interfaces, one composable trust decision. No coupling.

Happy to spec out the integration pattern if useful.

5

Hey Nicopat, really like this framing. a

The good news is IComplianceProvider is already designed to support exactly this. Since we only constrain the output of the interface and not how a provider reaches its decision, an ERC-8240 backed provider that aggregates attestations and risk signals works today without any changes to ERC-8226. Implementers are free to compose whatever inputs make sense for their jurisdiction. That composability being possible without spec-level coupling is actually something we’re pretty intentional about. Keeps the standard focused and lets the ecosystem experiment freely on top of it.

1 Like
6

Hi hi

@Ludovico.r, Nabil

clean architecture on the three-tier safeguard.

A small composition note from our side: ERC-8240 (Trust Infrastructure for Agents and Assets) operates at the consumer/quality layer above RAMS / token compliance via your IComplianceProvider, agent quality via ERC-8240’s IAttestation. Two checks, two interfaces, no overlap with the RAMS base layer.

On the open regulatoryCompliance signal in ERC-8004 supportedTrust: this maps cleanly to what IAttestation produces. Happy to flesh out a short composition note if useful

same approach as the one I’m drafting for ERC-7943, will share the two together.

Patrick

7

Interesting proposal. I particularly like the decision to keep RAMS agnostic to both the agent identity framework and the regulated token standard. By positioning itself as a delegation and mandate layer rather than another compliance framework, it appears capable of integrating with existing ecosystems such as ERC-3643, EIP-7943, and ERC-8004 without requiring issuers to replace their current infrastructure.

The dual compliance check pattern also makes sense to me. Preserving the token issuer’s existing eligibility checks before evaluating mandate validity helps ensure that RAMS acts as an additional authorization layer rather than a mechanism that could bypass issuer-defined compliance requirements.

One area where I would appreciate further discussion is the one-active-principal constraint. While I understand the motivation from an account segregation and regulatory perspective, I wonder how this model would accommodate institutional use cases where a regulated portfolio manager, robo-advisor, or AI investment service acts on behalf of multiple principals under separate mandates. Is the expectation that such operators deploy a dedicated agent identity per principal, or is there a future path for supporting multiple principals while preserving segregation guarantees?

Regarding the open topics, I tend to favor the principal-custodied model as the default for regulated RWAs. It aligns naturally with investor registries, beneficial ownership reporting, and existing compliance workflows. However, I can also see the value of keeping the standard agnostic, particularly for higher-frequency strategies where agent-controlled custody may be operationally preferable. If the standard remains agnostic, it may be useful to define a canonical way for integrators to determine the principal, agent, legal owner, and beneficial owner associated with a transaction so that custodians, issuers, and compliance providers can interpret ownership consistently.

Overall, I think the proposal fills an important gap. Existing standards address identity, compliance, and tokenization independently, but there is currently no standardized way to express and verify delegated authority for AI agents interacting with regulated assets. RAMS appears well positioned to address that missing layer.

1 Like
8

@yehia67 thanks, two points worth tightening.
One active principal: it’s one mandate per (agent, principal) pair, not per agent. The same agent can hold N mandates from N principals concurrently, so robo-advisors and multi-client operators work natively, no dedicated agent identity per client. We’ll make that explicit in the next update.

On custody: RAMS stays custody-agnostic by design. The mandate defines authorization between agent and principal; it lets the agent act against the principal’s wallet, never take custody. Principal-custodied is the default we recommend for regulated RWAs (aligns with investor registries and beneficial-ownership reporting), but the standard doesn’t hardcode it, since custody varies by structure and resolves through the compliance model.

Canonical role resolution: RAMS resolves four on-chain roles today, agent, principal, compliance provider, and enforcer, with identityRef linking to off-chain identity via the provider. Legal vs beneficial owner is the real open part: the principal can be either depending on structure (trust company vs HNWI). We lean to extend the IComplianceProvider with optional getLegalOwner(principal, identityRef) and getBeneficialOwner(principal, identityRef), keeping IAgentMandate minimal and delegating the ownership model to the provider rather than adding opinionated fields to the mandate struct.

Does that cover your use cases? If not, what’s the scenario where resolving through the provider falls short, keen to understand where you’d want it at the mandate level.

9

Nice, the delegation/mandate layer is exactly the piece that’s been missing. Everyone did identity and tokenization, nobody really did “what is the agent actually allowed to do”.

Read through the spec and one thing I couldn’t find: replay protection on the grant signature. grantMandate just says verify the signature against principal, but there’s no nonce or domain binding on what gets signed. The “already has an active mandate” guard only holds while the mandate is active, so once a principal calls revokeMandate, isActive goes false and the agent has no active mandate again. Doesn’t that let someone replay the principal’s original grant signature and re-instate the mandate they just revoked? Same worry across chains or registry deployments if the signed payload isn’t pinned to chainId + the registry address.

Intended to be in scope here, or left to implementations?

10

Great catch @VladKuzR, thanks for reading through the spec, and yes it’s in scope.
The current update adds full replay protection on all signed operations: a per-principal nonce that’s included in the signed payload and consumed on use, plus a deadline. So a grant signature is spent the first time it’s used; after a revoke it can’t be replayed because the nonce has already advanced. Cross-chain / cross-registry replay is prevented by the EIP-712 domain, which binds chainId and verifyingContract (the registry address). EIP-1271 is supported for contract-wallet principals.
So nonce + deadline + domain binding, normative for every signed op. The version you read predated this; the update is landing now!
Does this address the concern you had, or do you see another edge case we should make explicit in the spec?

11

Update: spec refinements and reference implementation now in PR #1844

We’ve opened PR #1844. Two sets of changes, one from the EIP review process and one from this thread.

Spec refinements

  • complianceProvider is now mandatory at grantMandate. The optional path is removed. This closes a gap that was implicit in @TrendAdmin’s question on safeguards: with the provider optional, a mandate could be granted without principal eligibility verification ever running. Making it mandatory ensures the dual compliance check is always active.

  • Cap denomination clarified, and enforcement is now explicitly venue-agnostic. The same mandate can be enforced at the token hook, in an EIP-7702 delegated account, or via a dedicated executor, with consistent semantics across all three.

Reference implementation (under assets/erc-8226/)

  • AgentMandate registry

  • ComplianceProvider reference

  • Optional AgentExecutor

  • End-to-end integration with ERC-7943 (uRWA-20) showing the dual compliance check pattern in working code

Position on the custody model open question
After working through the reference implementation, the current PR keeps the spec custody-agnostic. Prescribing a default would constrain adoption across use cases with materially different operational needs (high-frequency strategies vs long-term investment vehicles, agent-direct vs principal-direct settlement). Both models are supported by the same interfaces. The reference implementation demonstrates the agent-custodied path with ExecutionRecorded events for traceability; principal-custodied works without any spec changes. We’ll revisit this position once we have production deployments to learn from.

Open for feedback

  • Does the venue-agnostic enforcement model hold up for EIP-7702 delegated accounts in your view, or are there account-abstraction edge cases that need explicit handling in the spec?

  • On composability: @Nicopat, your ERC-8240 integration note remains fully applicable. IComplianceProvider is unchanged. Happy to coordinate on the composition note you mentioned.

1 Like