Summary: ERC-1400 is best understood as an umbrella library for security-token interfaces rather than as one narrowly-scoped token primitive. Its draft spec bundles four different sub-standards — ERC-1410 for partitioned balances, ERC-1594 for transfer prechecks and issuance/redemption semantics, ERC-1643 for document management, and ERC-1644 for controller overrides — into one composable family. That makes it analytically useful because it exposes a design choice that later tokenization stacks often hide: regulated assets can be decomposed into partial-fungibility, preflight compliance checks, disclosure surfaces, and coercive admin powers instead of being treated as one undifferentiated “security token” feature set.
What it does:
Defines ERC-1400 as a library-style aggregate of multiple underlying security-token standards instead of a single self-sufficient contract interface
Preserves ERC-20 compatibility while explicitly aiming to cover issuance, redemption, transfer restrictions, partitioned balances, documents, and controller actions
Treats partitioned balances via ERC-1410 as a first-class requirement so subsets of one holder’s balance can carry different rights or restriction metadata
Uses ERC-1594-style preflight transfer checks and optional offchain-data injection so transfer validity can depend on more than balance and allowance
Standardizes document references through ERC-1643 so issuers can expose legal and disclosure materials onchain by name, URI, and hash
Standardizes controller transfer and redemption rights through ERC-1644 so force-move and force-burn powers are explicit rather than hidden in bespoke admin roles
Key claims:
The draft’s own simple summary says ERC-1400 represents a library of standards for security tokens on Ethereum, which is the clearest signal that the proposal is an umbrella coordination layer rather than one minimal interface.
The abstract is unusually explicit about the decomposition: differentiated ownership, transfer checking, document management, and controller operations are separate components that can still be treated as one family.
The strongest reusable insight is architectural rather than contractual: ERC-1400 argues that a regulated token stack should expose multiple control planes instead of flattening compliance, tranche logic, disclosure, and override power into one opaque issuer contract.
The underlying README makes clear that the standard was designed as a “foundational block” for additional standards and that offchain processes would still remain necessary, which is a useful reminder that the proposal is an interface framework for compliance, not compliance itself.
The requirements section is revealing because it bundles together transfer prechecks, forced transfers, issuance/redemption, metadata on subsets of balances, document discoverability, and optional signed offchain approvals. That set of requirements effectively defines the early security-token design space.
ERC-1400 is especially useful in the corpus as a comparison hinge: richer systems like ERC-3643 add identity registries and more operational policy on top, while thinner systems like ERC-1404 and ERC-1462 strip the stack back down to fewer hooks.
The community website’s older tranche-oriented interface language is also worth retaining because it shows how the family originally framed partitioned balances as security-specific tranches rather than as a generic token extension.
Whitepaper: No standalone ERC-1400 whitepaper surfaced in this pass. The strongest primary materials were the draft ERC issue, the Security Token Standard site, and the original EIP-Spec repository README collected in ../../whitepapers/erc-1400-primary-sources-2026-05-12.md.