ERC-1400

DraftOpen Standard

ERC-1400 (Security Token Standard)

ERC-1400 is the foundational security token standard that most practitioners working in this space learned from, even if they ultimately chose something else. Authored by the Polymath team and submitted as an EIP in 2018, ERC-1400 introduced the concept of partitioned tokens — a single token contract that can represent multiple tranches of securities, each with its own transfer restrictions, rights, and compliance logic. That design decision still influences how security token infrastructure is architected today. The core innovation of ERC-1400 is the partition. In traditional securities, a single company might have multiple classes of shares, senior and subordinate debt tranches, or preferred and common equity — each governed by different transfer rules and investor eligibility requirements. ERC-1400 maps this directly onto the token contract. Rather than deploying a separate token contract for each security class, an issuer deploys a single ERC-1400 contract and manages multiple partitions within it. This reduces deployment costs and simplifies on-chain accounting when multiple classes interact. The transfer restriction mechanism in ERC-1400 is controller-based: authorized controllers can override standard transfer restrictions for corporate actions, regulatory compulsion, or error recovery. The standard exposes a canTransfer function — a precursor to ERC-7943's interface approach — that allows pre-flight compliance checks before a transfer is submitted. Document management functions allow legal documents (prospectuses, subscription agreements, compliance certifications) to be attached to the token contract by URI and hash. Where ERC-1400 has innovative design, it gives back in interface complexity. The standard is actually a suite of sub-specifications: ERC-1410 (Partially Fungible Token — the partition model), ERC-1594 (Core Security Token — issuance and redemption), ERC-1643 (Document Management), and ERC-1644 (Controller Token Operations). A full ERC-1400 implementation means implementing all of these. In practice, many deployments implement only subsets, which undermines interoperability and defeats part of the standard's purpose. Polymath's stewardship of ERC-1400 has been inconsistent. The standard reached Last Call status on the EIP track but never achieved Final status — a significant distinction that reflects unresolved questions about whether some design decisions warranted standardization at the interface level versus the implementation level. That governance uncertainty has not prevented adoption: Securitize's early infrastructure, TokenSoft, and other first-generation platforms built on ERC-1400. But it creates long-term maintenance uncertainty that newer standards specifically address. ERC-1400 is the standard that taught the industry what security token infrastructure needs to do. It is not necessarily the standard to build on today.

Quick Reference
CategoryOpen Standard
Governancevendor_controlled
Chain Supportethereum
Statusdraft

Technical Specification

ERC-1400 is a suite of Ethereum security token sub-standards authored by Polymath, submitted as EIP-1400 in 2018. Status: Last Call (never reached Final). The standard comprises four interconnected EIPs that together define a comprehensive security token interface. COMPONENT STANDARDS ERC-1410 — Partially Fungible Token (Partition Model) Core concept: a single token can have multiple "partitions" — distinct buckets with their own transfer rules and potentially different rights. Key functions: - balanceOfByPartition(bytes32 partition, address account) → uint256 - transferByPartition(bytes32 partition, address to, uint256 amount, bytes data) → bytes32 Returns the partition the tokens ended up in after transfer. - operatorTransferByPartition(bytes32 partition, address from, address to, ...) - partitionsOf(address account) → bytes32[] - totalPartitions() → bytes32[] The partition bytes32 value is issuer-defined. Common patterns: keccak256("equity-class-a"), keccak256("debt-senior-tranche"), or structured bytes encoding jurisdiction codes. ERC-1594 — Core Security Token Issuance, redemption, and transfer restriction interface. Key functions: - issue(address to, uint256 amount, bytes data) — controlled minting - redeem(uint256 amount, bytes data) — token holder redemption - redeemFrom(address from, uint256 amount, bytes data) — operator redemption - canTransfer(address to, uint256 amount, bytes data) → (bool, bytes1, bytes32) Returns: (isValid, statusCode, partition). statusCode follows ERC-1066 standard. This is the original pre-flight compliance check function; ERC-7943 canTransact is a direct descendant. - canTransferFrom(address from, address to, uint256 amount, bytes data) → (bool, bytes1, bytes32) - isIssuable() → bool — whether the token can accept new issuances - isControllable() → bool — whether controller override is active ERC-1643 — Document Management Attaches legal documents to the token contract by URI + content hash. Key functions: - setDocument(bytes32 name, string uri, bytes32 documentHash) - getDocument(bytes32 name) → (string, bytes32, uint256) — returns (uri, hash, timestamp) - removeDocument(bytes32 name) - getAllDocuments() → bytes32[] Use cases: attach prospectus, subscription agreement, legal opinion, CUSIP, LEI ERC-1644 — Controller Token Operations Defines forced transfer and freeze authority for the controller (transfer agent) role. Key functions: - controllerTransfer(address from, address to, uint256 amount, bytes data, bytes operatorData) Forced transfer with dual data fields: investor-facing and operator-facing. - controllerRedeem(address from, uint256 amount, bytes data, bytes operatorData) - isControllable() → bool Events: ControllerTransfer, ControllerRedemption ROLES - Issuer/Owner: deploys contract, manages controller list, sets issuance rules - Controller: authorized for controllerTransfer and controllerRedeem; maps to transfer agent - Operator: ERC-20/ERC-777 operator concept applied per-partition TRANSFER STATUS CODES (ERC-1066) ERC-1400 uses ERC-1066 single-byte status codes for canTransfer responses: 0x50 — Transfer Verified (success) 0x51 — Transfer Pending 0x52 — Token Granularity — amount doesn't meet minimum 0x53 — Insufficient funds 0x54 — Funds Locked (frozen) 0x55 — Insufficient Transfer Allowance 0x56 — Invalid Sender 0x57 — Invalid Receiver 0x58 — Invalid Operator 0x59–0x5F — Reserved / Custom INTEROPERABILITY CHALLENGES Because ERC-1400 is a suite rather than a single interface, and because many implementations only partially implement the suite, interoperability in practice requires discovery of which sub-standards a given token implements. The ERC-1643 document functions allow self-description. Many platforms that nominally "support ERC-1400" implement only ERC-1594 (core transfer restrictions) and skip ERC-1643 (document management) or ERC-1410 (full partition support). UPGRADE PATH No built-in upgradeability in the base specification. Some implementations use proxy patterns (OpenZeppelin Transparent Proxy or UUPS) layered on top. Compliance logic is embedded in the token contract or in a controller contract; upgrading requires either a proxy upgrade or token migration. STATUS NOTE EIP-1400 reached Last Call but not Final. Polymath has not actively maintained the EIP since 2019-2020. The standard is effectively frozen in its Last Call state — stable for existing deployments but not receiving active development.

Key Features

Partition model (ERC-1410): single contract manages multiple security classes (tranches, share classes) with per-partition transfer rulesPre-flight compliance check (canTransfer): standardized function for UI and smart contract pre-validation before transfer submissionDocument management (ERC-1643): attach legal documents (prospectus, subscription agreement) to the token by URI and content hashController operations (ERC-1644): forced transfer and redemption authority for transfer agent functionERC-1066 status codes: standardized single-byte transfer status codes for machine-readable compliance feedbackHistorical ecosystem: large body of audited implementations, developer tooling, and platform integrations from 2018-2022

US Regulatory Fit

ERC-1400 was designed with US securities regulatory requirements more explicitly in mind than ERC-3643. The controller model maps directly to the transfer agent function under Section 17A of the Securities Exchange Act — a single authorized entity with the technical ability to perform forced transfers and redemptions. The document management interface (ERC-1643) maps to the obligation to maintain shareholder records with associated legal documentation. The canTransfer status codes provide a machine-readable compliance feedback layer useful for ATS connectivity. The partition model supports Regulation S / Regulation D segmentation: a single token can have different partitions for US-accredited investors and non-US investors, each with its own transfer restrictions and holding period locks. Polymath built an early relationship with US-focused securities platforms specifically around this regulatory alignment. ERC-1400 has been used in US exempt securities offerings including tokenized real estate and private equity fund interests. The main regulatory gap is the absence of a standardized identity layer — implementers must build their own KYC/AML connection.

Institutional Adoption

ERC-1400 was the dominant security token standard for US-adjacent deployments from approximately 2018 to 2022. Key deployers included: Securitize (early infrastructure before building proprietary DS Protocol), TokenSoft (now Trident Digital), and tZERO. Several real estate tokenization platforms (Harbor, before it shifted strategy) and fund tokenization providers built on ERC-1400. Polymath's own Polymesh blockchain was eventually built as a security-token-specific chain that draws on ERC-1400 concepts but moves beyond the Ethereum implementation. As of 2025, ERC-1400 is primarily relevant for: (1) maintaining existing issuances deployed on the standard, (2) platforms with significant sunk cost in ERC-1400 infrastructure, and (3) developers studying the lineage of security token interface design.

Limitations & Trade-offs

Never reached Final EIP status: Last Call only; governance is effectively frozen with Polymath as de facto but inactive maintainerSuite complexity: full compliance requires implementing four sub-EIPs (ERC-1410, ERC-1594, ERC-1643, ERC-1644); partial implementations undermine interoperabilityNo native upgradeability: compliance logic changes require proxy patterns layered on top or full token migrationEthereum-only: no multi-chain architecture in the specificationSuperseded for new builds: ERC-7943 and ERC-3643 have addressed most of ERC-1400's limitations for new issuances; ERC-1400 is primarily relevant for maintaining existing deployments
Official Specification ↗Compare All StandardsAsk The Advisor
← Back to all standards

This entry reflects TTP's editorial assessment as of 2026 and is intended as an informational practitioner reference only. Consult qualified legal and technical counsel before adopting any standard in a production context.