ERC-8226: Regulated Agent Mandate

ERCs
,
1

Authors: Ludovico Rossi, Dario Lo Buglio, Thamer Dridi, Nabil El Alami Khalifi
GitHub PR: Add ERC-8226: 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.

7 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