Category: restricted-token base standard / transfer-restriction middleware / compliance-token lower bound
Summary: ERC-1404 is best understood as a deliberately minimal restriction layer for ERC-20 tokens rather than as a full tokenized-asset operating system. Its core move is to add only two things: a standard function that detects whether a transfer should be blocked and returns a restriction code, and a second function that maps that code to a human-readable message. That makes ERC-1404 analytically useful because it isolates the smallest viable compliance hook for security-style tokens: the token itself decides whether a transfer may proceed, but the standard refuses to prescribe where the policy comes from. Identity checks, whitelists, lockups, jurisdiction rules, holder caps, or sanctions logic can all sit behind the same narrow interface.
What it does:
Extends ERC-20 with detectTransferRestriction(from, to, value) returning a restriction code where 0 means success
Adds messageForTransferRestriction(code) so wallets, issuers, or exchanges can expose human-readable failure reasons instead of opaque reverts
Requires issuers to call restriction detection inside transfer and transferFrom, making preflight checking part of the token’s transfer path
Leaves the policy source open so issuers can implement whitelists, lockups, holder-count caps, jurisdiction rules, or other compliance conditions however they choose
Encourages composition of small reusable restriction modules rather than one monolithic compliance contract, as shown in the reference repository’s example patterns
Positions itself as fully backwards-compatible with ERC-20 and intentionally easy for exchanges and wallets to integrate
Key claims:
The draft’s motivation is explicit that issuers need transfer restrictions for securities law and contractual obligations, but the standard’s answer is intentionally narrow: standardize the detection and messaging interface rather than standardizing every policy source.
The decisive mechanism insight is the split between machine-readable restriction codes and human-readable messages. ERC-1404 treats “why did this transfer fail?” as a first-class interoperability surface.
The reference repository sharpens the point further: the standard is meant to support small reusable contracts that each enforce one restriction pattern, with final tokens built by composing them through inheritance.
That composability matters because it distinguishes ERC-1404 from thicker compliance stacks. It is not trying to define identity registries, claim issuers, controller powers, or disclosure plumbing.
The ecosystem site is useful not as neutral proof of adoption but because it shows the standard being framed as a base layer under more branded systems such as Polymath ST-20 and Harbor R-Token. That makes ERC-1404 a lower-bound comparison point rather than a full product stack.
Relative to ERC-1462, ERC-1404 is even thinner: it standardizes transfer restriction detection and user messaging but not mint/burn prechecks, ERC-1066-style generalized status codes, or document attachment.
Relative to ERC-1594 and ERC-3643, ERC-1404 keeps the policy engine deliberately offstage. That is exactly why it belongs in the corpus: it makes clear how little interface surface is actually required before people start calling a token “compliant.”
Whitepaper: No standalone ERC-1404 whitepaper surfaced in this pass. The strongest primary materials were the draft ERC issue, the ERC1404 project site, and the reference repository README collected in ../../whitepapers/erc-1404-primary-sources-2026-05-12.md.