Regulated Agent Mandate Standard (RAMS)

ERCs
,
1

Authors: Ludovico Rossi (Brickken), Dario Lo Buglio (Brickken), Thamer Dridi (Brickken)
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 identified via ERC-8004 that operate on tokenized regulated assets governed by EIP-7943.

ERC-8004 gives an AI agent a portable on-chain identity. It does not address what happens when that agent executes a transaction on a regulated financial instrument such as 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 ERC-8004 agent, analogous to a power of attorney in traditional finance.

  2. Dual compliance check via canTransact. How RAMS-aware EIP-7943 tokens verify mandate validity through their existing canTransact hook, executing two checks in sequence: first the token’s own investor eligibility on the principal (EIP-7943 compliance 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 ERC-8004 or EIP-7943 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.

A reference implementation is under development at https://github.com/brickken/eip-rams.

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

4 Likes