ERC-1400 was the first serious attempt to encode security-token semantics at the protocol level. It is worth understanding even though the institutional market did not converge on it, because every design decision in ERC-3643 is in some sense a reaction to a problem ERC-1400 either created or failed to solve. The historical record matters here: ERC-1400 was not a bad spec, it was an over-ambitious one that tried to do everything inside the token contract and discovered, the hard way, that compliance logic ages on a different clock than token logic.
What ERC-1400 actually was
A suite, not a single interface. Proposed by Polymath in 2018-2019, ERC-1400 was an umbrella standard bundling four sub-standards: ERC-1410 (partially fungible tokens), ERC-1594 (core security-token semantics), ERC-1643 (document management), and ERC-1644 (controller operations for forced transfers). An issuer claiming "ERC-1400 compliance" was implementing a stack of these together, not a single contract. That structure was the first warning sign: the standard was more an architectural commitment than a drop-in interface.
The bundle gave the standard four load-bearing capabilities that ERC-20 lacked.
The four capabilities
Partitions. A single token contract could hold multiple tranches inside one address, with each tranche carrying different rights, lock-ups, or transfer rules. The motivating use case was a single security token representing both Reg D and Reg S tranches of the same offering, or Class A and Class B share series, with separate transfer logic per partition. transferByPartition(partition, to, amount) and balanceOfByPartition(partition, owner) extended ERC-20's flat balance sheet into a tranched one.
Transfer restrictions. The standard introduced a canTransfer(from, to, amount, data) view function that returned a status code plus a reason string. The intent was that wallets and exchanges could pre-flight a transfer, get a clear answer (allowed, blocked, blocked because jurisdiction, blocked because lock-up), and surface the reason to the user before submitting a transaction that would revert. In practice few wallets ever wired this up.
Document attachment. setDocument(name, uri, documentHash) let the issuer pin offering documents, prospectuses, and shareholder agreements to the token contract by hash, with the actual document hosted off-chain. The on-chain hash gave a tamper-evident reference; the URI gave the lookup. This was the cleanest part of the spec and is the one piece most successor standards quietly kept.
Forced transfers and freezes. controllerTransfer and controllerRedeem let a designated controller (the issuer) move tokens between addresses regardless of the holder's consent, and freeze balances on demand. Controversial in DeFi-native terms, non-negotiable for regulated security issuers facing court orders, sanctions designations, or beneficial-ownership corrections.
Why it lost
Compliance lived inside the token. The structural problem was that the transfer-restriction logic, the partition rules, and the controller hooks were all expressed in the token contract itself. Changing a compliance rule (a new jurisdiction added, a QP threshold updated, an additional lock-up clause for a new tranche) meant either upgrading the token or building elaborate sub-modules wired into the token through interfaces the standard did not actually fix. Every issuer ended up with a slightly different ERC-1400 implementation. Interoperability suffered, audit cost rose, and the standard fragmented.
Gas cost was real. The partition logic added storage per holder per partition. The canTransfer pre-flight, when actually used, doubled the on-chain calls per transfer. Document attachment was cheap but the rest of the stack was not. For a tokenised MMF doing thousands of subscriptions and redemptions a day on Ethereum mainnet, the cost difference between an ERC-1400 implementation and a leaner alternative was material.
No issuer consensus. Polymath promoted ERC-1400 but Polymath was a platform vendor, not a regulator or an SRO. Without buy-in from a critical mass of issuers (and without any major institutional MMF or bond programme settling on the standard) ERC-1400 became a reference design that everyone read and very few production systems committed to. The 2019-2021 wave of security-token offerings either used ERC-1400 partially, used a custom variant, or reverted to ERC-20 plus off-chain compliance.
The architectural lesson. The deeper problem was conceptual. Compliance rules change on a regulatory clock (new sanctions list every quarter, new jurisdictional rule every year, new investor-class threshold whenever the SEC or MAS revises a definition). Token state (balances, partitions, total supply) changes on an operational clock (every subscription, every redemption, every secondary trade). Putting both clocks inside the same contract meant every compliance update risked a token upgrade, and every token upgrade dragged compliance through a re-audit. The clocks needed to be separated.
What survived
The vocabulary, mostly. Partitions reappeared in successor designs as a per-investor compliance attribute rather than as a token-contract primitive. Document attachment became a near-universal convention. The canTransfer idea survived intact and is the load-bearing hook in ERC-3643. Forced transfer and freeze remained non-negotiable for any institutional standard, and ERC-3643 reimplemented both as compliance-module operations.
What did not survive was the assumption that a single contract should hold token logic and compliance logic together. Part 3 walks through how ERC-3643 separated the two and why that separation, more than any specific feature, is the reason the institutional market converged on it.