Skip links

EIP-RCP: Why Tokenized Capital Markets Need a Regulatory

TL;DR

The EIP-RCP (Regulatory Compliance Protocol) Informational EIP draft is now complete. Developed through collaborative research between Oraclizer and Horizen Labs, this protocol systematically classifies 31 core requirements from 15 global financial regulatory authorities and organizes them under five fundamental principles: Traceability, Privacy, Enforceability, Finality, and Tokenizability. The proposal establishes a common vocabulary for regulatory compliance interoperability of tokenized assets and clearly identifies structural gaps that existing security token standards fail to address—particularly granular regulatory actions, token expiration, and cross-chain verification. This is not a new regulatory interpretation but rather a systematic compilation of requirements that regulators have already stated.


Introduction: Two Years of Research, One Milestone

Since the publication of the RCP (Regulatory Compliance Protocol) paper in 2023 by Horizen Korea—the Oraclizer core team—we have focused on a single question: Is true interoperability possible in tokenized capital markets without regulatory compliance?

Today, we share the first fruit of that exploration. The draft of EIP-RCP: Regulatory Compliance Protocol for Tokenized Assets is complete. Developed in collaboration with Horizen Labs, this Informational EIP will be proposed to the Ethereum ecosystem.

This article is not the proposal itself but rather an explanatory companion to it. We explore why this protocol is necessary, what regulatory authorities actually demand, why existing standards are insufficient, and what this proposal means for the Ethereum ecosystem and tokenized capital markets.

The starting point of RCP research was simple: reading the official documents from regulatory authorities directly. FATF, BIS, IOSCO, SEC, MAS, FCA—we systematically reviewed what they have actually stated about distributed ledger technology and tokenized financial instruments. As a result, we identified 31 core requirements and confirmed how these are not being met by existing Ethereum token standards.

This is not the claim of a single team. It is a systematic compilation of already-existing regulatory requirements.

The Interoperability Problem: Why Compliance Is Non-Negotiable

The Prerequisite for Interoperability

The tokenization of real-world assets presents significant opportunities for capital market efficiency. However, this potential is constrained by a fundamental gap: the absence of a unified regulatory compliance protocol that enables tokenized assets to operate across different blockchain networks and regulatory jurisdictions.

Currently, tokenized assets exist as isolated systems. A tokenized bond on one network cannot meaningfully interact with tokenized securities on another without manual verification of compliance status, regulatory standing, and identity requirements.

“Without a common compliance protocol: There is no standardized way to query compliance status. There is no common vocabulary for regulatory actions. There is no mechanism to verify that freeze/seize actions are honored across chains. This is not merely inconvenient—it is a structural impossibility.”

— EIP-RCP Proposal

A Practical Scenario: From Chain A to Chain B

Consider a concrete situation: An ERC-1400 security token on Chain A needs to interact with an ERC-3643 compliant token on Chain B. How does Chain B verify the regulatory compliance status of the incoming asset?

Without a common compliance protocol:

  • There is no standardized way to query compliance status
  • There is no common vocabulary for regulatory actions
  • There is no mechanism to verify that freeze/seize actions are honored across chains

This is not merely inconvenient—it is a structural impossibility.

Connection to Traditional Finance

The problem extends beyond cross-chain scenarios. The same issue arises when tokenized assets must interact with traditional financial infrastructure. When assets operating in DAML/CANTON-based financial systems bridge to on-chain environments, both sides need a regulatory compliance vocabulary they can understand and verify.

The World Bank makes this clear:

“To be adopted in the financial system, DLT systems need to comply with know-your-customer (KYC) and customer due diligence (CDD) requirements of anti-money laundering/combatting the financing of terrorism (AML/CFT) regulations.”

— World Bank, Distributed Ledger Technology and Secured Transactions (2021)

RCP addresses this by providing:

  1. A common vocabulary for compliance status
  2. A standardized taxonomy of regulatory actions
  3. A protocol for cross-chain compliance verification

What Regulators Actually Demand: Requirements Already Stated

Compilation, Not Interpretation

A core principle of EIP-RCP must be made clear: This protocol does not propose new interpretations of regulatory requirements. It systematically compiles what regulators have explicitly stated about distributed ledger technology and tokenized financial instruments.

Through review of guidance documents from 15 regulatory authorities, we identified 31 requirements that these authorities have explicitly stated for DLT-based financial systems.

A Consistent Message from Regulators

FATF (Financial Action Task Force) requires in its virtual asset guidelines:

“VASPs and other obliged entities engaging in or providing VA activities, products, and services should have the ability to flag for further analysis any unusual or suspicious movement of funds or transactions—including those involving VA—or other activities indicative of potential involvement in illegal activities.”

— FATF, Updated Guidance for Virtual Assets and VASPs (2021)

BIS-IOSCO is clear on settlement finality:

“An FMI should provide clear and certain final settlement, at a minimum by the end of the value date. Where necessary or preferable, an FMI should provide final settlement intraday or in real time.”

— BIS-IOSCO, Principles for Financial Market Infrastructures (2021)

FINMA (Switzerland) is specific about identity verification:

“Where a contracting party is a body corporate or partnership, the financial intermediary must ascertain and document the contracting party’s authorisation provisions relating to the body corporate concerned and verify the identity of the individuals acting on behalf of a body corporate or partnership in establishing the business relationship.”

— FINMA, Special Regulations for Financial Intermediaries, Article 44(3)

Additional Regulatory Trends Beyond the Proposal

Beyond the 15 authorities in the EIP-RCP proposal, major jurisdictions are actively developing regulatory frameworks for tokenized assets.

The US SEC presented criteria for determining whether digital assets qualify as securities through its 2019 “Framework for ‘Investment Contract’ Analysis of Digital Assets.” It specified analysis factors including application of the Howey Test, degree of decentralization, and functional use of tokens, concretizing the scope of tokenized securities subject to regulation.

EU MiCA (Markets in Crypto-Assets Regulation) came into effect in June 2023, establishing a comprehensive regulatory framework for crypto-asset service providers (CASPs). It provides separate provisions for asset-referenced tokens (ARTs) and e-money tokens (EMTs), institutionalizing differentiated regulatory approaches by token type.

Singapore MAS is developing regulatory frameworks for tokenized assets through the Payment Services Act and Project Guardian. It is conducting pilot programs for tokenized bonds and deposits targeting institutional investors, validating regulatory requirements in actual operating environments.

Japan FSA defined “electronically recorded transferable rights” through amendments to the Payment Services Act in 2019, incorporating them as regulatory targets under the Financial Instruments and Exchange Act. This was a pioneering approach to clarifying the legal status of security tokens.

Convergence of the Message

Common patterns emerge from the messages of all these regulatory authorities:

  1. Identity verification (KYC/AML) is non-negotiable: All authorities explicitly require it
  2. Transaction monitoring is mandatory: Capability to detect suspicious activity is required
  3. Regulatory intervention capability must be secured: Measures such as asset freeze, seizure, and confiscation must be possible
  4. Settlement finality must be guaranteed: Transaction completion with legal certainty
  5. Auditability must be maintained: Record keeping for regulatory review

RCP’s five principles—Traceability, Privacy, Enforceability, Finality, and Tokenizability—are derived from functional classification of these regulatory requirements. This is not the creation of a new categorization but the systematic organization of existing requirements.

Why Existing Standards Fall Short: Anatomy of Structural Gaps

The Limitation of a Single Function

ERC-1400 and ERC-3643 have made important progress in the security token space. However, these standards meet only a portion of the 31 regulatory requirements and were developed without a unified conceptual basis.

The ERC-1400 ecosystem is fragmented across multiple sub-standards (ERC-1594, ERC-1410, ERC-1643, ERC-1644). In particular, ERC-1644’s single controllerTransfer function is insufficient to distinguish legally distinct regulatory actions.

As analyzed in detail in previous research, the core problem is this:

Regulatory actions are not interchangeable. The legal distinction between asset freeze (temporary, reversible) and confiscation (permanent, ownership transfer) requires different on-chain mechanisms.

Regulatory Action Taxonomy

EIP-RCP defines six distinct regulatory actions:

Compliant implementations MUST distinguish between these actions because they have different legal implications and procedural requirements. A single controllerTransfer function cannot adequately represent these distinct regulatory mechanisms.

Absence of Cross-Chain Verification

Both ERC-1400 and ERC-3643 were designed for single-chain, single-jurisdiction scenarios. There is no mechanism for cross-chain regulatory compliance status verification.

Consider the scenario again: What happens when an asset that is FROZEN on Chain A is bridged to Chain B? Under current standards:

  • Chain B has no way to recognize the FREEZE status
  • The frozen asset can trade freely on Chain B
  • Regulatory enforcement is nullified

RCP solves this problem by providing a common vocabulary for cross-chain regulatory compliance verification.

Absence of Token Expiration

Another fundamental gap in existing standards is the absence of token expiration mechanisms. Tokens representing bonds, options, and other time-bound instruments cannot exist indefinitely.

A 10-year government bond maturing in 2035 must have automatic principal repayment and token burn mechanisms at maturity. However, none of ERC-20, ERC-1400, or ERC-3643 provide this as a standard feature.

EIP-RCP’s Tokenizability principle explicitly includes this requirement:

“Tokens representing time-bound assets must support expiration mechanisms.”

— EIP-RCP Proposal, Requirement 23

The Coverage Gap: 31 Requirements and Existing Standards

Requirements Coverage Matrix

The EIP-RCP proposal systematically analyzes the extent to which existing standards meet requirements. Key findings include:

ERC-20: Provides only basic token functionality. Meets approximately 6 of 31 requirements.

ERC-1400 ecosystem: Progress for security tokens. Meets approximately 15 of 31 requirements. However, core requirements such as suspicious transaction monitoring, token expiration, blacklist management, and forced liquidation remain unmet.

ERC-3643: Focus on regulatory compliance. Meets approximately 14 of 31 requirements. Single-chain design means no cross-chain verification.

Common gaps:

  • Suspicious transaction monitoring (Requirement 2)
  • KYC change detection (Requirement 3)
  • Transaction cancellation/modification (Requirement 12)
  • Smart contract suspension/disposal (Requirement 14)
  • Blacklist management (Requirement 15)
  • Forced liquidation (Requirement 16)
  • Token expiration (Requirement 23)
  • Asset class management (Requirement 30)

Why These Gaps Matter

These gaps are not mere missing features. They represent the absence of capabilities that regulators explicitly require.

For example, FINRA Rule 4210 requires immediate liquidation of portfolio margin accounts under certain conditions:

“A member must immediately liquidate all portfolio margin accounts that have a position in any of the affected products… if it is insolvent or unable to meet its obligations.”

— FINRA Rules 4210(g)(14)(A)

Currently, no standard provides a standardized interface for implementing this requirement on-chain.

Five Principles: The Logic of Functional Classification

Structural Rationale

The five-principle structure of EIP-RCP reflects how regulatory requirements functionally cluster:

  1. Traceability: Who participates
  2. Privacy: What is protected
  3. Enforceability: How can authorities intervene
  4. Finality: When does finality occur
  5. Tokenizability: What properties must be preserved in tokens

This structure describes existing regulatory organization rather than prescribing new categories.

Tokenizability: Innovation of the Fifth Pillar

One of the most practical discoveries from RCP research is the Tokenizability principle. This is not simply “tokenization capability” but rather a comprehensive set of technical and legal properties that enable assets to fully and faithfully maintain all their essential characteristics, regulatory attributes, and lifecycle behaviors when converted from real-world assets to digital tokens.

Three components of Tokenizability:

Temporal Properties: The ability to implement time-based characteristics of assets in code, such as maturity dates, exercise periods, and coupon payment schedules

Classificatory Properties: The ability to apply differentiated regulations based on asset type (EQUITY, DEBT, DERIVATIVE, COMMODITY) and characteristics

Restrictive Properties: The ability to implement restrictions according to regulatory requirements, such as trading restrictions by investor type, holding limits, and access restrictions by KYC level

Classification as Informational EIP

Why Not Standards Track?

There is a reason EIP-RCP is classified as Informational rather than Standards Track:

Foundational nature: It defines requirements rather than implementation interfaces. It specifies “what” implementations should reference, delegating “how” to each implementation.

Implementation flexibility: Various standards can implement these requirements differently. RCP does not mandate specific Solidity interfaces.

Jurisdictional adaptability: Different jurisdictions may require different subsets of requirements. RCP provides a comprehensive reference, leaving selection to implementations.

Stability: The conceptual foundation can remain stable even as implementations evolve.

Relationship to Existing Standards

RCP is not intended to replace existing standards. It provides:

  • Common vocabulary: Standardized definitions for regulatory compliance terminology
  • Completeness reference: A protocol for assessing the extent of standard compliance
  • Interoperability foundation: Shared requirements enabling cross-standard compatibility

Implications for the Ethereum Ecosystem

RCP as Regulatory Constitution

As digital asset markets mature, someone must step forward to organize and establish standards. Regulators have already stated their requirements. The question is how the Ethereum ecosystem will accommodate them.

EIP-RCP aims to become the Ethereum ecosystem’s “regulatory constitution”—the fundamental principles that all regulatory-compliant tokenization projects should reference. A philosophical foundation for harmonizing G20 financial standards with blockchain.

Prerequisite for Tokenized Capital Markets

What RCP establishes is not merely a technical standard. It is a prerequisite for tokenized capital markets to truly integrate with traditional finance.

Major financial institutions including BlackRock, JPMorgan, and Goldman Sachs are announcing tokenization initiatives, but without a structural compliance framework, these attempts will remain isolated experiments.

RCP provides the common language to bridge this gap.

Security Considerations

The proposal specifies several key security considerations:

Regulatory authority management: If authority designation is compromised, unauthorized asset freezes, malicious transaction blocks, and false compliance reporting become possible. Multi-signature schemes, timelocks, and transparent authority registries are recommended.

Privacy vs. compliance balance: The protocol acknowledges tension between privacy (the Privacy principle) and oversight (the Traceability principle). Approaches such as zero-knowledge proofs, selective disclosure mechanisms, and trusted execution environments are proposed.

Cross-chain considerations: Cross-chain compliance verification introduces new attack surfaces—false proofs from compromised bridges, race conditions between regulatory actions on different chains, and state inconsistencies due to finality differences.


Conclusion: Toward the Next Step

The completion of the EIP-RCP Informational EIP is not an end but a beginning.

This proposal defines the “what”—what is needed for regulatory compliance of tokenized assets. But the “how” remains to be answered.

In upcoming Standards Track work, we will propose a new security token standard—ERC-TRUST (Total Regulatory Unified Security Token)—that implements RCP requirements on-chain. This standard will:

  • Inherit the design philosophy of ERC-1400 while overcoming its structural limitations
  • Provide explicit interfaces for six granular regulatory actions
  • Include token expiration, asset class management, and cross-chain verification mechanisms
  • Enable selective implementation through a modular structure

In the next research, we will explore the architecture design of the Enforceability module. How to implement six regulatory actions on-chain—this is the first challenge of the Standards Track.

Without regulatory compliance, there is no interoperability. Without interoperability, the promise of tokenized capital markets cannot be realized. RCP is the first step on that journey.


References

  1. World Bank. (2021). Distributed Ledger Technology and Secured Transactions. https://documents.worldbank.org/en/publication/documents-reports
  2. FINMA. (2018). Special Regulations for Financial Intermediaries. https://www.finma.ch
  3. HKMA. (2021). Distributed Ledger Technology White Paper. https://www.hkma.gov.hk
  4. FATF. (2021). Updated Guidance for a Risk-Based Approach for Virtual Assets and Virtual Asset Service Providers. https://www.fatf-gafi.org
  5. BIS-IOSCO. (2021). Application of the Principles for Financial Market Infrastructures to Stablecoin Arrangements. https://www.bis.org
  6. SFC. (2019). Statement on Security Token Offerings. https://www.sfc.hk
  7. MAS. (2021). Technology Risk Management Guidelines. https://www.mas.gov.sg
  8. SEC. (2019). Framework for “Investment Contract” Analysis of Digital Assets. https://www.sec.gov
  9. European Parliament. (2023). Regulation on Markets in Crypto-Assets (MiCA). https://eur-lex.europa.eu
  10. IOSCO. (2020). Issues, Risks and Regulatory Considerations Relating to Crypto-Asset Trading Platforms. https://www.iosco.org
  11. FINRA. (2021). FINRA Rules. https://www.finra.org

Read Next

Insurance and Recovery Economics: Preparing for Black Swan Events
Earlier designs cut node risk by 73%, but the unpredictable 27% needs different rules. This study fixes how a staking insurance pool is sized (15% of stake, not protected value), bootstrapped, and banded; why a reserve held in its own token collapses with it; and how session protection follows the sync-degree hierarchy when security breaks mid-session.
Oraclizer Core ⋅ May 29, 2026
Tokenized Securities Under the CLARITY Act: The Weight of Codification
The CLARITY Act tokenized securities clause settles a single proposition in statute: tokenization is a delivery method, not a new asset class. That one sentence codifies the regulatory status of tokenized securities in U.S. law for the first time and derives an entire infrastructure specification for boundaries the token crosses.
Oraclizer Core ⋅ May 23, 2026
Sync Degree Hierarchy: Classifying What Assets Demand from State Synchronization
Sync degree hierarchy turns sync requirement strength into a four-level classification axis for RWA assets. S₀ static through S₃ atomic state binding form a reduction relation where causal consistency separates S₁ from S₂. Existing oracles, structurally two independent channels, are capped at S₁ by definition. Regulatory action forces S₃.
Oraclizer Core ⋅ May 20, 2026
Why RWA Isn’t Real DeFi Collateral Yet: The Non-Atomicity of the Collateral Layer
Tokenized RWA-backed stablecoin supply reached $8.5B, yet only 12% operates inside DeFi. Aave Horizon's dual structure separates rather than solves regulatory state synchronization. Three conditions from cross-border securities trading transfer into the DeFi collateral layer, with a fourth condition added when the protocol becomes a regulatory subject.
Oraclizer Core ⋅ May 14, 2026