ERC-1404: The Simple Restricted Token Standard

I co-authored ERC-1404 in 2018 to solve one problem: how do you make a token that can enforce securities law?

ERC-20 tokens can go anywhere. That's great for utility tokens, but securities have rules — accredited investor requirements, lockup periods, jurisdictional restrictions, KYC/AML. Before ERC-1404, there was no clean way to enforce these at the protocol layer.

ERC-1404 is the standard behind the first SEC-registered security token IPO in history (INX, 2020) and the first '40 Act fund on a public blockchain (ArCoin). It's been used in over $1B of compliant token offerings.

What ERC-1404 Does

ERC-1404 extends ERC-20 with two functions:

function detectTransferRestriction(address from, address to, uint256 value) public view returns (uint8);
function messageForTransferRestriction(uint8 restrictionCode) public view returns (string);

That's it. Two functions.

detectTransferRestriction checks whether a transfer is allowed before it happens. If it returns anything other than 0, the transfer reverts. The logic is up to the issuer — whitelist checks, lockup enforcement, accreditation verification, whatever your compliance requires.

messageForTransferRestriction returns a human-readable explanation for why a transfer failed. This lets wallets and exchanges show users why they can't transfer, not just that they can't.

Why I Built It This Way

Simplicity over complexity

ERC-1400 (the other major security token standard) is comprehensive — partitions, documents, controller operations. It's powerful but heavy.

ERC-1404 is minimal. If you know ERC-20, you can implement ERC-1404 in an afternoon. The restriction logic lives in your contract, not in a sprawling standard.

On-chain enforcement, not off-chain promises

Before ERC-1404, "compliant tokens" usually meant tokens with transfer restrictions enforced by gentlemen's agreements and terms of service. The token itself didn't know or care who held it.

ERC-1404 enforces restrictions at the protocol layer. A non-compliant transfer doesn't fail gracefully — it reverts. The blockchain itself becomes the compliance layer.

Backward compatible with everything

ERC-1404 tokens are fully ERC-20 compatible. Any wallet, exchange, or DeFi protocol that supports ERC-20 can hold ERC-1404 tokens. The restriction check happens transparently.

The Spec

Interface

contract ERC1404 is ERC20 {
    /// @notice Checks if a transfer is allowed
    function detectTransferRestriction(address from, address to, uint256 value) 
        public view returns (uint8 restrictionCode);
    
    /// @notice Returns human-readable message for a restriction code
    function messageForTransferRestriction(uint8 restrictionCode) 
        public view returns (string message);
}

Implementation Requirements

1. detectTransferRestriction must be called inside transfer and transferFrom
2. If the return value is not 0, the transaction must revert
3. Restriction logic is implementation-specific (the standard doesn't prescribe what to check, only how to check it)

Example Implementation

contract RestrictedToken is ERC20, ERC1404 {
    mapping(address => bool) public whitelist;
    mapping(uint8 => string) public restrictionMessages;
    
    uint8 public constant SUCCESS = 0;
    uint8 public constant NOT_WHITELISTED_FROM = 1;
    uint8 public constant NOT_WHITELISTED_TO = 2;
    
    constructor() {
        restrictionMessages[SUCCESS] = "Success";
        restrictionMessages[NOT_WHITELISTED_FROM] = "Sender not whitelisted";
        restrictionMessages[NOT_WHITELISTED_TO] = "Recipient not whitelisted";
    }
    
    function detectTransferRestriction(address from, address to, uint256 value) 
        public view override returns (uint8) 
    {
        if (!whitelist[from]) return NOT_WHITELISTED_FROM;
        if (!whitelist[to]) return NOT_WHITELISTED_TO;
        return SUCCESS;
    }
    
    function messageForTransferRestriction(uint8 code) 
        public view override returns (string memory) 
    {
        return restrictionMessages[code];
    }
    
    function transfer(address to, uint256 value) public override returns (bool) {
        uint8 code = detectTransferRestriction(msg.sender, to, value);
        require(code == SUCCESS, messageForTransferRestriction(code));
        return super.transfer(to, value);
    }
}

Real-World Usage

ERC-1404 has been adopted in SEC-registered offerings, institutional funds, and enterprise platforms worldwide. Below are verified on-chain deployments and regulatory filings.

Verified On-Chain Deployments

Academic & Institutional Citations

ERC-1404 has been cited in regulatory filings, central bank research, and academic legal scholarship:

Platform Implementations

Notable Offerings

Over 100 projects and $1B+ in compliant offerings have used ERC-1404 through the Tokensoft platform, including:

• Tezos ($242M)
• Hedera Hashgraph ($132M)
• Avalanche ($42M)
• INX ($85M) — first SEC-registered security token IPO
• Tauschen Semicoin — $5B semiconductor infrastructure tokenization

ERC-1404 vs Other Standards

When to use ERC-1404: You want a simple, battle-tested standard that does one thing well — enforce transfer restrictions.

When to use ERC-1400/3643: You need the full toolkit — document management, partial fungibility, on-chain identity.

FAQ

Is ERC-1404 officially adopted?

ERC-1404 has "Draft" status in the EIP process, but it's been used in SEC-registered offerings since 2020. Practical adoption matters more than committee status.

Can ERC-1404 tokens be used in DeFi?

Yes, with caveats. ERC-1404 is ERC-20 compatible, so tokens can technically interact with Uniswap, Aave, etc. But if the restriction logic blocks a transfer, it will revert.

How do I implement KYC with ERC-1404?

The standard doesn't prescribe a KYC method. Common approaches: whitelist contracts, off-chain attestations, or identity tokens.

Source Code

The canonical reference implementation lives in a GitHub repository I maintain:

• simple-restricted-token/simple-restricted-token — Reference implementation with composable restriction patterns (84 ⭐, 27 forks)

The repository includes ready-to-use contracts for common compliance patterns:

• Whitelist-based restrictions — Only approved addresses can send/receive
• Max holder limits — Cap the number of token holders (Reg D compliance)
• Lockup periods — Time-based transfer restrictions
• Accreditation checks — Verify investor status before transfers

Resources

• GitHub — Original EIP Proposal
• GitHub — Reference Implementation
• ERC1404.org — Official Standard Website
• Tokensoft — Production Implementation
• Etherscan — INX Token Contract (verified source)