ERC-3643

ERC-3643 is an Ethereum token standard, also known as T-REX (Token for Regulated EXchanges), that enables the issuance and management of permissioned security tokens on public blockchain infrastructure. It embeds on-chain identity verification and compliance rule enforcement into the token transfer logic, ensuring that only verified, eligible investors can hold and transfer regulated digital assets. The standard extends ERC-20 with an identity registry, modular compliance modules, and claim-based permissioning, making it suitable for tokenised securities, real-world assets, and other regulated financial instruments. ERC-3643 was standardised through the Ethereum Improvement Proposal process and has been adopted by multiple institutional asset tokenisation platforms.

Overview

• ERC-3643 was designed to bridge the gap between the open, permissionless nature of public blockchains and the compliance requirements imposed by securities law and financial regulation worldwide.
• Traditional ERC-20 tokens can be held and transferred by any Ethereum address, which is incompatible with Regulatory Compliance frameworks that require investor accreditation, residency checks, holding period enforcement, and AML/KYC screening.
• The T-REX standard solves this by embedding compliance logic directly into the token contract, so that every transfer or transferFrom call is subject to an on-chain validation pipeline before it can succeed.
• Why it matters:
  • Enables Asset Tokenisation of regulated assets (equities, bonds, real estate, private credit) on public Ethereum infrastructure.
  • Provides a standardised, auditable compliance trail on-chain, reducing settlement risk and operational overhead for issuers.
  • Interoperates with permissioned DeFi venues that need to verify participant eligibility before allowing swaps, lending, or liquidity provision.
  • Offers modular compliance rules that can be updated by the token issuer without redeploying the core token contract.
• The standard is actively deployed by institutional-grade tokenisation platforms and underpins several large Real-World Asset Tokenisation programmes in Europe and Asia.

Key Components

Token Contract (T-REX Token)

• Extends ERC-20 with additional interfaces: forcedTransfer, freeze, pause, and identity-gated transfer.
• Each transfer triggers a call to the Compliance Module and Identity Registry before execution.
• Agents (operators) can be granted limited administrative roles (e.g. freezing individual wallets, forced recovery of tokens).

Identity Registry

• A smart contract mapping Ethereum wallet addresses to ONCHAINID identity contracts.
• Each investor must have a registered identity before they can receive tokens.
• The registry is controlled by the token issuer and can be shared across multiple token issuances from the same issuer.
• Works with the Identity Registry Storage contract that physically holds the address–identity mapping, allowing the registry logic to be upgraded independently.

ONCHAINID / Claim-Based Identity

• Built on ERC-734 (key management) and ERC-735 (claim holder) standards.
• Each investor’s identity contract stores cryptographically signed claims (e.g. “KYC verified”, “accredited investor in jurisdiction X”).
• Claims are issued by trusted Claim Issuer contracts (e.g. KYC providers, legal counsel) and verified on-chain at transfer time.
• This decouples identity verification from the token contract itself, enabling reusable identity across multiple token issuances and issuers.

Compliance Module

• Pluggable smart contracts that enforce business rules at transfer time.
• Standard modules include: CountryRestrictModule (block/allow specific nationalities), MaxBalanceModule (cap individual holdings), SupplyLimitModule (enforce total supply caps), TransferFeesModule.
• Modules implement a common interface so that new compliance rules can be added or removed by the issuer after deployment.
• Multiple modules can be stacked; all must return true for a transfer to proceed.

Trusted Issuers Registry

• Maintains the list of claim issuers whose attestations the token contract accepts as authoritative.
• The issuer can add or remove claim issuers (e.g. onboard a new KYC provider or revoke a compromised one).
• Claim issuers themselves are smart contracts with a registered signing key, providing an auditable chain of trust.

Token Factory

• A deployment utility contract (part of the reference T-REX suite) that deploys all the above contracts in a single transaction and wires them together.
• Reduces deployment errors and ensures consistent configuration across multiple token issuances from a single issuer.

Mechanisms

Transfer Validation Flow

• When transfer(to, amount) is called, the token contract checks:
  1. Sender is not frozen.
  2. Receiver address is registered in the Identity Registry.
  3. Receiver’s identity holds required claims (e.g. KYC claim, country eligibility).
  4. All Compliance Module rules pass (holding limits, country restrictions, etc.).
• Only if all four conditions pass does the ERC-20 balance transfer execute.

Forced Transfer and Recovery

• Token agents can execute forcedTransfer to move tokens between addresses without normal transfer validation, used for legal orders (court-ordered recovery, lost-wallet recovery).
• Wallet freeze functions allow the issuer to block an address from sending or receiving tokens while preserving ownership on-chain.

Pausability

• The entire token can be paused (all transfers disabled) by an authorised agent, enabling market halt scenarios required by some jurisdictions.

Agent Role Model

• The standard defines granular agent roles: owner, agent, compliance agent, transfer manager.
• This role separation prevents single-key compromise from granting full administrative access.

Applications / Use Cases

Tokenised Securities

• Issuance of digital shares, bonds, and convertible notes on Ethereum, where investor eligibility checks are a legal requirement.
• Tokeny Solutions (the original author) has facilitated numerous tokenised security offerings using the T-REX suite.

Real Estate Tokenisation

• Fractional ownership tokens backed by commercial real estate, where ownership is restricted to qualified investors and must comply with jurisdictional transfer rules.
• ERC-3643 enforces the holding rules automatically on-chain, reducing legal overhead for secondary market trades.

Private Credit and Funds

• Tokenised fund units (private equity LP interests, debt instruments) requiring accredited investor status verification and investor count limits.
• The MaxInvestorsModule compliance module enforces SEC Regulation D investor count limits for US offerings.

Carbon Credits and ESG Assets

• Permissioned carbon credit tokens where only verified registries and corporate buyers can participate, preventing fraud and double counting.

Central Bank Digital Currency (CBDC) Infrastructure

• Some wholesale CBDC pilots use ERC-3643’s compliance architecture to restrict token holding to authorised financial institutions.

Permissioned DeFi

• Integration with Decentralised Finance protocols that verify ERC-3643 token eligibility before allowing liquidity provision or borrowing, enabling compliant DeFi for institutional investors.

Standards & Context

EIP Process

• ERC-3643 was submitted as an Ethereum Improvement Proposal (EIP-3643) and ratified as a Final ERC, meaning it has gone through community review, implementation reference checks, and editorial acceptance.
• The standard is maintained by the T-REX open-source community and Tokeny Solutions under an Apache 2.0 licence.

Relationship to Other Security Token Standards

• ERC-1400 (Polymath): an earlier security token standard with partitioned tokens and controller-based transfers; ERC-3643 is considered more modular and identity-centric.
• ERC-1404 (Simple Restricted Token Standard): a simpler approach using error codes returned from detectTransferRestriction; ERC-3643 provides a richer compliance and identity layer.
• ST-20 (Polymath legacy): an early proprietary standard; largely superseded.

Regulatory Alignment

• The compliance module architecture was designed to be compatible with EU MiFID II, US SEC Regulation D and S, and Singapore MAS requirements for digital securities.
• The ONCHAINID identity system supporting ERC-3643 is compatible with eIDAS electronic identity frameworks used in the European Union.
• The standard’s on-chain audit trail supports requirements under GDPR when combined with off-chain personal data handling (claims reference off-chain data without storing PII on-chain).

Adoption

• Adopted by Tokeny Solutions, InvestaX, TokenFi, and multiple institutional tokenisation platforms as of 2025.
• Supported on Ethereum mainnet and several EVM-compatible chains including Polygon, BNB Chain, and Avalanche.
• Referenced in the European Blockchain Services Infrastructure (EBSI) pilots for digital bond issuance.

Provenance