Skip links

EIP-RCP Draft Proposal Released: Regulatory Compliance Protocol for Tokenized Assets

Oraclizer Update

The Oraclizer team and Horizen Labs are officially releasing the EIP-RCP (Regulatory Compliance Protocol for Tokenized Assets) draft proposal. This proposal is an Informational EIP that defines a regulatory compliance framework for tokenized capital markets—a first step toward establishing a common reference point for compliant tokenization in the Ethereum ecosystem.


Why EIP-RCP

Interoperability of tokenized assets is not merely a technical challenge. For tokenized assets to meaningfully interact across different blockchain networks and regulatory jurisdictions, a common vocabulary and protocol for verifying and sharing compliance status is essential.

While security token standards like ERC-1400 and ERC-3643 exist today, they address only portions of regulatory requirements and lack a unified conceptual framework. For instance, ERC-1644’s single controllerTransfer function cannot distinguish between legally distinct regulatory actions such as asset freeze (FREEZE) and confiscation (CONFISCATE).


The Five Principles

EIP-RCP organizes 31 core requirements derived from systematic review of official guidance from 15 global financial regulatory authorities (FATF, BIS, SEC, MAS, FCA, and others) under five fundamental principles:

  1. Traceability: The ability to identify, track, and audit all participants, assets, and transactions throughout their lifecycle
  2. Privacy: Protection of sensitive information while maintaining necessary transparency for regulatory oversight
  3. Enforceability: The ability for authorized parties to execute regulatory actions on tokenized assets
  4. Finality: Assurance that transactions and ownership records are legally conclusive under defined conditions
  5. Tokenizability: The ability to represent real-world assets as tokens while preserving their legal, economic, and regulatory characteristics throughout their lifecycle

Key Contributions of the Proposal

The key contributions that EIP-RCP provides to the Ethereum ecosystem are:

  • Common Vocabulary: Standardized definitions for compliance terminology
  • Completeness Reference: A protocol for assessing whether existing standards meet requirements
  • Interoperability Foundation: Shared requirements enabling compatibility across different standards

The proposal includes a Requirements Coverage Matrix comparing which of the 31 requirements are met by ERC-20, ERC-777, ERC-1400, and ERC-3643, clearly illustrating the gaps in the current ecosystem.


What Informational EIP Means

EIP-RCP is classified as an Informational EIP. Unlike Standards Track EIPs that define implementation interfaces, this document defines a conceptual framework and requirements. The rationale for this classification includes:

  • Foundational nature: Defines requirements rather than implementation
  • Implementation flexibility: Multiple standards can implement these requirements differently
  • Jurisdictional adaptability: Different jurisdictions may require different subsets
  • Stability: Conceptual framework can remain stable while implementations evolve

A separate Standards Track EIP (ERC-TRUST) implementing this framework will be proposed in the future.


Next Steps

With the release of the EIP-RCP draft proposal, we welcome feedback from the Ethereum community and regulatory compliance practitioners.

The full proposal is available for download below.


Learn More

Read Next

We Joined Observer Patch Holography: Proving Outside Our Own Stack
Oraclizer CPTO Jay Kim is credited on three papers from the Observer Patch Holography research program, under the affiliation Oraclizer Labs. We joined because the central question is shaped like ours: how far can a divergent state be brought back, and what stands in the way. Our contribution separates the four ways repair fails, proved in Lean 4.
Oraclizer Core ⋅ Aug 18, 2026
Formalizing ERC-TRUST from Normative Rules to Executable Semantics
Discharging a proof obligation does not mean it constrains anything. If no reachable state satisfies its premise, the obligation passes vacuously and the checker stays silent. This is how ERC-TRUST lowered its normative sentences into machine-checkable state transitions, built an execution for every rule, and drew the line at legal fact.
Oraclizer Core ⋅ Aug 11, 2026
When Regulatory Actions Do Not Commute: Order, Outcome, and Sixty Normal Forms
Enforcement standards define what a freeze or a confiscation does, and say nothing about what happens when two commands overlap. Regulatory action composition closes that gap in Isabelle/HOL: twenty-one action pairs split into twelve commuting and nine not, each non-commuting pair with a witness, and exactly sixty state transformations behind unbounded sequences.
Oraclizer Core ⋅ Jul 31, 2026
Defining the Sync Unit: Oracle Usage Metering for State Synchronization
The State Subscription economy has quoted ten Sync Units for a dollar without ever fixing what one Sync Unit counts, leaving three conflicting conversion rates inside one body of work. This study anchors the unit to a single committed state binding and derives its weight from the sync degree hierarchy. Applying it inverts the existing frequency bands.
Oraclizer Core ⋅ Jul 25, 2026
Designing the ERC-TRUST Enforceability Architecture
A regulator's freeze and a court's confiscation are legally opposite, yet on today's token standards they compile to the same call. This ERC-7943 conformance extension makes each of the six regulatory actions a typed, distinct object whose legal effect is verifiable on-chain, and carries that meaning from the abstract model down to deployed bytecode as evidence.
Oraclizer Core ⋅ Jul 23, 2026