ERC-1400 is a family of security-token interfaces proposed in 2018 to give issuers partitions (tranches), on-chain transfer validation, document management and controller (court-order) powers. It was never finalised as a single ERC, but its ideas — and its sub-standards ERC-1410, ERC-1594, ERC-1643 and ERC-1644 — still shape how security tokens are built, and several issuance platforms continue to use it. If your instrument needs multiple classes or lock-up buckets inside one token, ERC-1400’s partition model remains the most expressive design available.
Key takeaways
- ERC-1400 = ERC-1410 (partitions) + ERC-1594 (core issuance, redemption and transfer validation) + ERC-1643 (documents) + ERC-1644 (controller operations).
- Its signature feature is partially fungible tokens: balances are split into named partitions such as “locked”, “Class A” or “Tranche 2024-1”.
- Transfers return reason codes (inspired by ERC-1066) so wallets can explain why a transfer failed.
- For most new issuances ERC-3643 is the default because it is final and widely supported; ERC-1400 remains useful where partitions are central. See ERC-3643 vs ERC-1400.
The four building blocks
ERC-1410 — partially fungible tokens
Balances are tracked per partition (a bytes32 key). Tokens in the same partition are fungible; tokens in different partitions are not. Key functions include balanceOfByPartition, partitionsOf, transferByPartition and operatorTransferByPartition. Partitions let one token express:
- Locked vs unlocked balances (vesting, lock-ups, Reg S distribution compliance periods).
- Share classes with different rights.
- Tranches of a debt issuance.
ERC-1594 — core security token
Adds issue, redeem, transferWithData and canTransfer. The data parameter lets an off-chain compliance service sign a transfer approval, so restrictions can be enforced without storing every rule on-chain. canTransfer returns a status byte and reason, giving users meaningful errors.
ERC-1643 — document management
Attaches named documents (URI plus content hash) to the token: prospectus, term sheet, legend text, notices. See ERC-1643 document management.
ERC-1644 — controller operations
Defines controllerTransfer and controllerRedeem so a designated controller (issuer, transfer agent or regulator) can move or cancel tokens — for court orders, error correction or lost keys — with events that make every intervention visible.
How a partitioned transfer works
- The holder calls
transferByPartition(partition, to, value, data). - The token validates the partition balance, then checks restrictions — optionally verifying an off-chain signed certificate in
data. - The token may move tokens into a different destination partition (e.g. from “locked” to “unlocked” after a holding period).
- Events record the partition movement for auditors and transfer agents.
Ideal use cases
- Multi-class equity — common, preferred and founder shares with different transfer rules in one token.
- Vesting and lock-ups — employee or founder tokens moving from locked to free partitions on schedule.
- Debt tranches — senior and junior tranches in one instrument.
- Jurisdiction buckets — e.g. tokens sold under different exemptions held in separate partitions until restrictions lapse.
Limitations to weigh
- Not finalised. Interfaces differ slightly across implementations; ecosystem tools assume ERC-3643 or plain ERC-20 more often.
- Complexity. Partition logic multiplies test cases and audit effort.
- Identity is not standardised. ERC-1400 relies on off-chain certificates or custom whitelists rather than a shared identity model such as ONCHAINID.
- Wallet UX. Generic wallets show a single balance and cannot use partitions directly.
Modern alternatives for partition-like needs
- ERC-3643 with separate tokens per class, sharing one identity registry.
- ERC-1155 with one ID per class or tranche plus compliance hooks.
- ERC-3525 semi-fungible tokens, where each token carries a “slot” and a value — a natural fit for bonds and vesting. See ERC-3525.
- ERC-3643 partial freezing to emulate locked balances.
Should you use ERC-1400 today?
Choose ERC-1400 if you are integrating with a platform that already uses it, or if partitions are the core of your instrument and you accept the extra audit work. Otherwise start with ERC-3643 and add classes as separate tokens. Either way, the legal rights live in your documents — document them on-chain so investors can verify them.
Reason codes: making failures understandable
ERC-1400 implementations commonly return status codes inspired by ERC-1066 from canTransfer / canTransferByPartition, so interfaces can tell investors why a transfer would fail before they sign:
| Code (hex) | Typical meaning |
|---|---|
0x51 |
Transfer success |
0x50 |
Transfer failure (generic) |
0x52 |
Insufficient balance |
0x53 |
Insufficient allowance |
0x54 |
Transfers halted (paused) |
0x55 |
Funds locked (lock-up period) |
0x56 |
Invalid sender |
0x57 |
Invalid receiver |
0x58 |
Invalid operator |
Exact codes vary between implementations, so document them for integrators. Whichever standard you use, pre-flight checks with human-readable reasons dramatically reduce support tickets on tokenization platforms.
Example partition scheme for a private company
| Partition | Purpose | Rule |
|---|---|---|
FOUNDERS_LOCKED |
Founder shares in vesting | No transfers; moves to FOUNDERS_FREE on schedule |
FOUNDERS_FREE |
Vested founder shares | Transfers to eligible investors only |
SERIES_A |
Series A preferred | Eligible professional investors; ROFR applies |
REG_S_DCP |
Shares sold under an offshore exemption | Restricted to non-US holders during distribution compliance period |
EMPLOYEE_POOL |
Option exercises | Transfer back to company only |
A single ERC-1410 token can hold all five with distinct rules — the strongest argument for the partition model.
Implementing the equivalent on newer standards
If you prefer a finalised standard, map partitions as follows:
- Separate ERC-3643 tokens per class sharing one identity registry; use partial freezes for vesting.
- ERC-1155 IDs per class with per-ID compliance, plus the ERC-7943 multi-token interface.
- ERC-3525 slots where value-based partial transfers within a class matter.
Audit focus areas for ERC-1400 implementations
- Partition accounting invariants (sum of partitions = balance; sum of balances = supply).
- Destination-partition switching logic encoded in
data. - Off-chain certificate verification (signature replay, expiry, signer rotation).
- Controller operations: authorisation, events and whether controllers can be removed.
- Interaction between ERC-20 transfer functions and partition defaults.
Frequently asked questions
It was proposed and widely discussed but never reached Final status. Its sub-standards are referenced by many security-token implementations.
A named bucket of a holder’s balance. Tokens within a partition are fungible; tokens in different partitions can carry different rights or restrictions.
Typically through off-chain verification services that sign transfer certificates passed in the data field, or through on-chain whitelists checked by canTransfer.
Yes, via a migration: snapshot balances and partitions, onboard holder identities, mint equivalent ERC-3643 tokens (one per class) and burn or freeze the originals.
Generally only on venues that support security tokens and can enforce eligibility. Generic exchanges do not understand partitions.
Not directly; distributions are implemented by separate contracts reading balances (optionally per partition).
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
