ERC-1404 primary sources — 2026-05-12

What I reviewed

• Draft standard:
  • https://github.com/ethereum/EIPs/issues/1404
• Project site:
  • https://erc1404.org/
• Reference / explainer repository:
  • https://github.com/simple-restricted-token/simple-restricted-token
  • https://raw.githubusercontent.com/simple-restricted-token/simple-restricted-token/master/README.md

Key takeaways from primary sources

• ERC-1404 defines a very small restricted-token interface: one function to detect transfer restrictions and one function to explain the restriction code.
• The design is intentionally policy-agnostic. Whitelists, lockups, ownership caps, jurisdiction rules, and sanctions logic can all sit behind the same narrow interface.
• The standard’s most reusable idea is not “security tokens need restrictions” — that part is obvious — but that wallets and exchanges should get both machine-readable failure codes and human-readable error messages from a predictable interface.
• The reference repository adds the second important signal: ERC-1404 was meant to encourage composition of small reusable restriction contracts, not one gigantic compliance monolith.
• The project site is useful because it explicitly positions ERC-1404 as a base layer that can sit beneath branded issuer stacks such as ST-20 or R-Token rather than replacing them.

Specific source signals worth retaining

• Draft motivation and rationale: strongest sources for why the authors wanted a standard transfer-restriction and error-messaging surface.
• Draft specification: best source for the exact two-function interface and the requirement that restriction checking occur inside transfer paths.
• Reference README: best source for the “small reusable restriction modules” framing.
• Project site: useful evidence that the standard was promoted as a lower-bound compliance substrate and tied to real issuer/exchange integration concerns.

Why this entry belongs in the corpus

• It provides the tokenization cluster with a clean lower-bound comparison point for transfer-restriction interfaces before identity registries, claim systems, document management, or admin workflows are layered on top.
• It helps distinguish transfer restriction detection from broader compliance stacks such as ERC-1462, ERC-1594, and ERC-3643.
• The durable insight is that “compliance tokenization” can begin as little more than a standardized transfer gate plus intelligible error reporting, with everything else left to surrounding contracts and issuer policy.