Category: security-token base standard / compliance-check middleware / document-bound tokenization primitive
Summary: ERC-1462 is best understood as a minimal compliance-and-documentation extension for fungible tokens rather than as a full tokenized-asset operating system. Its core move is to keep the token standard narrow: add explicit preflight checking functions for transfer, delegated transfer, mint, and burn, require them to return ERC-1066 status codes instead of a bare boolean, and add optional document-attachment functions for legal or disclosure materials. That makes ERC-1462 analytically useful as a lower-bound comparison for richer tokenization stacks such as ERC-3643, ONCHAINID, Tokeny, and Chainlink ACE. Instead of bundling identity, policy composition, and issuer-role frameworks into one surface, it isolates the simpler question of how a token can ask is this action allowed? and how it can bind itself to offchain legal documents.
What it does:
Extends ERC-20-style tokens with checkTransferAllowed, checkTransferFromAllowed, checkMintAllowed, and checkBurnAllowed preflight checks
Requires those checks to return Ethereum status codes from ERC-1066 so applications can distinguish allowed, disallowed, and error conditions more precisely than with a boolean revert alone
Separates direct-transfer and delegated-transfer checking so transfer and transferFrom can be governed differently
Adds optional document-management functions, attachDocument and lookupDocument, for binding legal or disclosure materials to the token
Leaves the source of policy flexible: checkers can use onchain registries, built-in issuer logic, or even offchain-oracle inputs
Positions itself as a backwards-compatible, minimal base layer rather than a fully opinionated compliance suite
Key claims:
The draft ERC’s own motivation is unusually revealing: it explicitly argues that other security-token proposals were either too project-specific or too broad, and it presents ERC-1462 as a narrower, more modular baseline.
The specification’s split between checkTransferAllowed and checkTransferFromAllowed is one of the main reusable insights. It makes direct-holder actions and delegated/operator actions separate control surfaces instead of flattening both into one generic canTransfer gate.
The standard’s use of ERC-1066 status codes matters because it turns compliance checking into a richer interface than true/false. That is analytically useful for later systems that want preflight explanations, traceability, or differentiated failure reasons.
ERC-1462 deliberately does not hard-code a specific identity or allowlist model. The check functions may consult whitelists, blacklists, contract-local logic, or offchain-oracle results, which means the standard is a hook surface for policy rather than the policy itself.
The optional document functions are the second key insight: ERC-1462 treats legal binding as a first-class token concern by letting issuers attach named offchain documents and content hashes without requiring a whole credential stack.
The rationale section explicitly ties the proposal to both ERC-20 and ERC-777 compatibility, but still centers ERC-20 because of adoption. That shows the design goal was pragmatic integration into existing fungible-token workflows rather than a clean-sheet replacement.
ERC-1462 remains useful in the corpus precisely because it is smaller and more incomplete than newer compliance systems. It provides a lower-bound comparison where compliance consists of transfer/mint/burn checks plus document references, before richer issuer-identity and token-policy frameworks are layered on top.
Whitepaper: No standalone ERC-1462 whitepaper or litepaper surfaced in this pass. The strongest primary materials were the EIP itself, its reference implementation repository, and the linked discussion thread collected in ../../whitepapers/erc-1462-primary-sources-2026-05-12.md.