ERC-1400

ERC-1400 is a composite Ethereum token standard that defines a framework for security tokens representing regulated financial instruments such as equities, bonds, and real estate on-chain. It extends the ERC-20 fungible token model with partition-based token tranches, on-chain transfer restrictions enforced via controller logic, document attachment for prospectuses and legal agreements, and forced transfer capabilities required for regulatory compliance. The standard is designed to satisfy securities law requirements across multiple jurisdictions by embedding compliance logic directly into the smart contract layer.

Overview

• ERC-1400 was proposed in 2018 by Polymath and collaborators to address a fundamental gap: while ERC-20 provided a simple fungible token interface, it included no mechanisms for the transfer restrictions, investor whitelisting, or document management required by securities regulators worldwide.
• The standard introduces a modular architecture: issuers can adopt the full ERC-1400 suite or implement only the sub-components relevant to their use case. This composability makes it applicable to a wide range of regulated assets.
• It operates on the Ethereum blockchain and relies on Smart Contract logic to enforce compliance rules at the protocol level, removing the need for off-chain gatekeeping.
• The standard is tracked as an Ethereum Improvement Proposal (EIP-1400) and achieved broad adoption in the Security Token Offering market between 2019 and 2022.
• Its design influenced subsequent standards for Real-World Assets tokenisation and continues to serve as a reference architecture for Digital Securities infrastructure.

Key Components

• ERC-1400 is a composite standard decomposed into several sub-standards, each addressing a specific functional requirement:
• ERC-1410 — Partially Fungible Token (Partitions)
  • Introduces the concept of token partitions (tranches), allowing a single token contract to manage multiple classes of shares or bond series with different rights.
  • Tokens within the same partition are fungible; tokens across different partitions may have distinct properties and transfer rules.
  • Enables modelling of preferred vs ordinary shares, locked vs unlocked tranches, or different bond maturities within a single contract.
• ERC-1594 — Core Security Token
  • Defines canTransfer and canTransferFrom functions that return a reason code (ERC-1066 compliant) indicating whether a proposed transfer would succeed before it is executed.
  • Provides transferWithData and transferFromWithData for passing compliance data (e.g. signed attestations) alongside a transfer.
  • Implements issuance and redemption functions required for the full lifecycle of a security token.
• ERC-1643 — Document Management
  • Provides on-chain attachment of legal documents (prospectuses, shareholder agreements, regulatory filings) via URI and content hash pairs.
  • Documents are versioned and time-stamped, enabling an immutable audit trail of issuer disclosures.
  • Links the Smart Contract to off-chain legal reality, satisfying prospectus and offering document requirements.
• ERC-1644 — Controller Token Operations
  • Provides forced transfer and forced redemption capabilities required by securities regulators for court orders, insolvency proceedings, or error corrections.
  • Designates a controller role (typically the issuer or transfer agent) with authority to override the standard transfer logic.
  • Satisfies requirements under regulations such as the UK Companies Act and US Uniform Commercial Code.
• Transfer Restriction Mechanisms
  • Transfer Restriction rules are typically implemented via a separate Transfer Restriction Manager contract queried by the token contract before each transfer.
  • Common restriction types: investor AML whitelist, jurisdiction lock-up, accredited investor verification, holding period enforcement.
  • The canTransfer return includes an ERC-1066 status code explaining the rejection reason, enabling transparent, machine-readable compliance reporting.
• Role-Based Access Control
  • Role-Based Access Control governs which addresses can issue, burn, force-transfer, or update documents.
  • Typical roles: Issuer, Controller, Transfer Agent, Operator.
  • Role management often integrates with OpenZeppelin AccessControl patterns.

Applications and Use Cases

• Equity Tokenisation
  • Private company shares can be issued as ERC-1400 tokens, with partitions representing different share classes (ordinary, preference, restricted).
  • Shareholder registers are maintained on-chain, replacing traditional paper-based registers.
  • Corporate actions such as dividends and voting can be coordinated programmatically.
• Bond and Debt Instrument Tokenisation
  • Fixed-income instruments issued under ERC-1400 allow automated coupon payments and maturity redemptions via Smart Contract logic.
  • Multiple tranches (senior, mezzanine, junior) can coexist within a single ERC-1410 partition structure.
• Real Estate Tokenisation
  • Real-World Assets such as commercial property can be fractionalised and distributed to accredited investors, with transfer restrictions enforcing jurisdiction limits.
  • Document management (title deeds, planning permissions) can be attached via ERC-1643.
• Security Token Offerings (STOs)
  • ERC-1400 became the de facto standard for Security Token Offering platforms including Polymath, Securitize, and TokenSoft.
  • STOs using ERC-1400 can programmatically enforce Regulation D / Regulation S transfer restrictions, lock-up periods, and investor caps.
• Regulated DeFi
  • Decentralised Finance protocols handling regulated assets (e.g. tokenised money market funds, on-chain repos) may integrate ERC-1400 tokens as the base asset layer.
  • Bridges between ERC-1400 security tokens and DeFi liquidity pools require compliant transfer wrappers to preserve restriction enforcement.
• Central Bank Digital Currency Experiments
  • Several central bank sandbox experiments have drawn on ERC-1400’s partition and controller patterns to model restricted-circulation digital currency instruments.

Standards and Context

• EIP Number: EIP-1400 (Ethereum Improvement Proposal), submitted to the Ethereum GitHub repository.
• Principal Authors: Adam Dossa, Pablo Ruiz, Fabian Vogelsteller, Stephane Gosselin (Polymath Network and contributors).
• Status: The EIP formally remained in Draft status in the Ethereum process, but the standard achieved de facto adoption across the Security Token Offering industry independent of final EIP ratification.
• Related EIPs: EIP-1410, EIP-1594, EIP-1643, EIP-1644 (the four sub-standards), and EIP-1066 (status codes used by canTransfer).
• Industry Bodies: The Token Standard was championed by Polymath and has been referenced by IOSCO, the UK FCA regulatory sandbox, and the Swiss FINMA DLT framework.
• Competing Standards:
  • ST-20 (Polymath’s earlier proprietary standard, superseded by ERC-1400).
  • DS Protocol (Securitize’s proprietary alternative).
  • ERC-3643 (also called T-REX, a later standard from Tokeny that introduced on-chain identity registries as a compliance layer, and which has grown in adoption relative to ERC-1400 for EU-regulated instruments).
• Regulatory Alignment: ERC-1400 was designed with awareness of US SEC Regulation D, Regulation S, and Regulation A+ exemption requirements; EU MiFID II; and Swiss FinSA.
• OpenZeppelin Support: OpenZeppelin published audited ERC-1400 reference implementations that issuers and platforms have used as a deployment baseline.
• Evolution: The Real-World Assets tokenisation wave of 2023–2025 renewed interest in ERC-1400 patterns, with several institutional DeFi platforms adopting or adapting the partition and controller mechanics for on-chain structured products.

Provenance