ERC-20 vs ERC-721 vs ERC-1400 vs ERC-3643: Token Standards Explained

Introduction

A token standard tells wallets and applications which functions a contract exposes. It does not, on its own, decide who may hold a regulated asset. ERC-20, ERC-721 and ERC-1155 carry no eligibility rules at all. ERC-1400 and ERC-3643 add transfer checks and issuer override powers on top of an ERC-20-compatible interface, but they come from different places: the ERC-1400 family remains a set of 2018 GitHub drafts that never became formal Ethereum Improvement Proposals (EIPs), while ERC-3643 reached Final status in December 2023 (Ethereum ERCs repository, 2023).

This article maps five Ethereum token standards, ERC-20, ERC-721, ERC-1155, ERC-1400 and ERC-3643, across fungibility, compliance design and real deployments. It also checks a common assumption against the contracts themselves. The largest tokenized funds, including BlackRock's BUIDL on Securitize, Ondo's OUSG and USDY, and Centrifuge's JAAA, do not run on ERC-3643. Each uses a permissioned ERC-20 design of its issuer's own. The result is a decision framework for equity, debt, real estate, collectibles and gaming assets that starts with the question that matters: who controls the transfer rules.

Why Does Token Standard Choice Determine Legal Enforceability and On-Chain Behavior?

Token standards set the interface a contract must expose, and the contract built on that interface decides whether a transfer succeeds. For a regulated asset, that decision carries legal weight: the code either enforces the offering's holder rules or leaves enforcement to paperwork after the fact. Five Ethereum standards handle this differently.

Why Token Standards Are Legally Operative Rule Sets, Not Just Interfaces

A token standard defines the function calls a smart contract must expose: approve, transfer and transferFrom for ERC-20; ownerOf and safeTransferFrom for ERC-721. Function signatures alone do not determine compliance. Whether a token checks know-your-customer (KYC) status, limits transfers to approved wallets or locks part of a balance depends on the logic behind those functions. A real estate fund deployed as a plain ERC-20 token ships with no transfer restrictions, no investor checks and no way to block an ineligible buyer, whatever the offering documents say. Changing that later is possible only if the contract was deployed behind an upgradeable proxy, which is how BUIDL and the ERC-3643 reference contracts are built (Etherscan, 2026; ERC3643 Association, 2026). Otherwise the issuer must deploy a new contract and migrate every holder.

How Five Ethereum Standards Occupy Distinct Compliance and Fungibility Layers

The five standards divide across two axes. On fungibility, ERC-20 and ERC-3643 tokens are interchangeable units, ERC-721 tokens are unique by ID, ERC-1155 supports both in one contract, and ERC-1400 tokens are fungible but can be split into partitions with separate rules. On compliance, ERC-20, ERC-721 and ERC-1155 carry no built-in eligibility logic. The ERC-1400 family adds a pre-transfer check, document links and controller transfers, and leaves the eligibility rules to the issuer's code. ERC-3643 requires an on-chain identity system and checks the receiving wallet against an identity registry on every transfer (EIP-3643, 2021). The table maps each standard against its specification status and live examples.

Data current as of October 2026.

ERC-20 occupies the first and most widely used layer of this stack. It carries the largest stablecoins and encodes no compliance logic of its own.

How Does ERC-20 Define Fungible Token Behavior and Power the DeFi Stack?

Proposed in November 2015 by Fabian Vogelsteller and Vitalik Buterin, ERC-20 defines six required functions, totalSupply, balanceOf, transfer, transferFrom, approve and allowance, that give any Ethereum contract a standard token interface (EIP-20, 2015). Every unit is identical to every other, which makes ERC-20 the default for currencies, stablecoins and decentralized finance (DeFi) protocol tokens.

ERC-20 Mechanics — Fungibility, Approve-Transfer Pattern, and DeFi Composability

The approve and transferFrom pair is ERC-20's most consequential design decision. A holder calls approve(spender, amount) to authorize a third-party contract, such as a decentralized exchange, a lending protocol or an automated market maker, to move tokens later without the holder signing each move. The authorized contract then calls transferFrom to execute the transfer. Uniswap pools, Aave markets and Compound markets all rely on this pattern. A plain ERC-20 contract carries no transfer restrictions, no identity check and no concept of investor eligibility. Any wallet can hold and transfer the token, which is both its composability advantage and the reason a regulated asset needs extra logic on top.

ERC-20's Stablecoin and DeFi Ecosystem Footprint

The scale of ERC-20 adoption shows in the assets it carries. Tether (USDT) had a market capitalization of about $184.0B and USD Coin (USDC) about $74.0B on 5 October 2026 (CoinPaprika, 2026). Both run as ERC-20 tokens on Ethereum and also on other blockchains, so those totals cover every chain, not Ethereum alone. Beyond stablecoins, ERC-20 underlies governance tokens such as UNI and COMP, yield-bearing tokens such as stETH, and wrapped assets such as WBTC. Many tokenized funds are ERC-20 tokens too. BUIDL, OUSG and JAAA all expose the ERC-20 interface, with their issuers' restriction logic placed inside transfer.

ERC-721 solved a different problem, creating tokens that cannot be substituted for one another, but it adds no restriction logic either.

How Does ERC-721 Encode Unique Digital Ownership and Where Does Its Compliance Model Break?

ERC-721, created in January 2018 and now Final, defines the non-fungible token (NFT) standard (EIP-721, 2018). Every token has a unique integer ID, and ownership is tracked per token on-chain. No two ERC-721 tokens are interchangeable, which makes the standard the base for digital art, game items and deed-like records.

ERC-721 Non-Fungibility — Unique Token IDs, safeTransferFrom, and Metadata URI

ERC-721 tracks ownership through a tokenId-to-address mapping. ownerOf(tokenId) returns the current holder, and safeTransferFrom checks that a receiving contract can handle ERC-721 tokens before the transfer completes. Each token can link to a metadata URI, usually an off-chain JSON file with a name, description and image, which gives marketplaces a standard way to display it. A holder can approve one operator for a specific token or grant setApprovalForAll permission over a whole collection. Ethereum's own documentation lists Gods Unchained cards and Sorare's football cards among ERC-721 collections (ethereum.org, 2026).

ERC-721 Compliance Limitations — No KYC, No Transfer Lock, No Programmatic Restrictions

ERC-721 encodes uniqueness but no compliance logic. The standard has no mechanism to restrict transfers to KYC-verified wallets, block sales to ineligible investors or enforce a holding period. A security issued as a plain ERC-721 token, such as a fractional property deed or a revenue-share certificate, moves to any wallet unless the issuer adds its own restriction code to the contract. ERC-721 is also not ERC-20 compatible: its approve and transferFrom functions take a token ID rather than an amount, so fungible-token infrastructure cannot use it directly. For assets subject to KYC and anti-money laundering (AML) rules, ERC-721's gap is structural.

ERC-1155 addresses a different limit, the cost of deploying a separate contract for every token type, without solving the compliance problem.

How Does ERC-1155 Enable Fungible and Non-Fungible Assets in a Single Smart Contract?

ERC-1155, created in June 2018 by authors from Enjin and Horizon Games among others, lets one smart contract manage many token types, fungible and non-fungible, in a single deployment (EIP-1155, 2018). A game studio can issue currency, equipment and unique collectibles from one contract instead of separate ERC-20 and ERC-721 contracts.

ERC-1155 Multi-Token Contract — Fungible and Non-Fungible in One Deployment

ERC-1155 introduces a token ID system in which the issuer decides fungibility per ID. Token ID 1 can represent 10,000 identical in-game coins, and token ID 2 a single unique sword. The balanceOf function takes both a wallet address and a token ID and returns that account's balance of that type. Transfers use safeTransferFrom for one type or safeBatchTransferFrom for several types in one transaction, so a game that moves many items at once needs fewer transactions than it would with separate contracts.

ERC-1155 Batch Transfer Efficiency and Gaming-Native Adoption

Batch transfers make ERC-1155 a natural fit for game studios with large, mixed item sets, and the standard's authors built it for that use. Marketplaces such as OpenSea list ERC-1155 tokens alongside ERC-721 tokens. Like ERC-20 and ERC-721, ERC-1155 carries no built-in compliance logic, and like ERC-721 it is not ERC-20 compatible. Transfers execute without identity checks, so it needs the same added restriction layer before it can carry a regulated security.

ERC-1400 was one of the first attempts to standardize that restriction layer, drafted by Polymath and others in 2018.

What Is ERC-1400 and How Does It Embed Securities Compliance Into Token Transfer Logic?

ERC-1400 was opened as GitHub issue #1411 in September 2018 by Adam Dossa of Polymath with Pablo Ruiz, Fabian Vogelsteller and Stephane Gosselin (GitHub, 2018). It is an umbrella for four companion drafts: ERC-1410 for partitions, ERC-1594 for core transfer checks, ERC-1643 for documents and ERC-1644 for controller transfers. The draft states that a security token "MUST be ERC-20 compatible" and adds the functions a regulated issuer needs around that interface.

ERC-1400 Architecture — Partitions, Document Management, and Optional Signed Transfer Data

ERC-1400's partition system divides a holder's balance into labeled classes, such as "unvested", "Series A" or "restricted", each with its own transfer rules. A canTransfer function returns a reason code before a transfer runs, so a wallet can show why a transfer would fail. ERC-1643 links the token to documents such as an offering memorandum, and ERC-1644 lets a controller force a transfer to reverse fraud, recover lost keys or follow a court order (GitHub, 2018). The draft also says a token "MAY require signed data to be passed into a transfer transaction". Some implementations use that option for issuer-signed certificates, but the standard does not require it. The eligibility rules themselves stay in the issuer's contract code.

ERC-1400 Limitations — Draft Status, Fragmented Implementations, and Cap Table Complexity

ERC-1400's main weakness is its status. The issue was closed as stale, and as of 5 October 2026 eips.ethereum.org has no page for ERC-1400, ERC-1404, ERC-1410, ERC-1594 or ERC-1644. Without a Final specification, implementations differ: Taurus notes that Consensys's UniversalToken reference code uses its own migration mechanism instead of the proxy pattern newer standards use (Taurus, 2025). Partitions add complexity that most single-class funds do not need, and a token that relies on issuer-signed certificates inherits whatever availability the issuer's signing service has. Those are design choices, not inherent flaws. An ERC-1400 token keeps the ERC-20 interface, so wallets can read it, while transfers still pass through the issuer's checks.

ERC-3643 standardizes a different answer: eligibility comes from an on-chain identity registry rather than from issuer logic written per token.

How Does ERC-3643 T-REX Build Identity-Centric Compliance Natively Into Every Token Transfer?

ERC-3643, also called T-REX (Token for Regulated EXchanges), was proposed in July 2021 by authors from Tokeny and reached Final status on 12 December 2023 (Ethereum ERCs repository, 2023). It extends ERC-20 and must be used with an on-chain identity system. Every transfer checks the receiving wallet's eligibility and the token's compliance rules before any balance moves.

ERC-3643 Identity-Centric Model — On-Chain Registry, Wallet Whitelisting, and Transfer Validation

The specification lists the conditions for a transfer. The sender needs enough free balance, meaning total balance minus frozen tokens. The receiver must be registered in the Identity Registry and verified, which means its identity contract holds the required claims signed by a trusted issuer. Neither wallet may be frozen, the token must not be paused, and the compliance contract's canTransfer must return true (EIP-3643, 2021). Only the receiver faces the identity check; the sender faces the balance and freeze checks. Agents appointed by the token owner can freeze wallets, pause the token, force transfers and move a balance to a replacement wallet when an investor loses a key. The registry is controlled by the owner and agents, and the ERC3643 Association describes its contracts as upgradable (ERC3643 Association, 2026). One ONCHAINID identity can link several of an investor's wallets and serve several tokens, so one KYC check can cover several offerings. The ERC3643 Association states that more than $32B in assets have been tokenized with the standard, a figure it reports itself and that no independent tracker confirms (ERC3643 Association, 2026).

ERC-3643 vs ERC-1400 — Specification Status, Identity Reuse, and Issuer Control

ERC-3643 and ERC-1400 share more than older comparisons suggest. Both keep the ERC-20 interface, both offer a pre-transfer check, and both give an issuer-appointed party power to move tokens without the holder's signature, controllerTransfer in ERC-1644 and forcedTransfer in ERC-3643. The differences are status and where eligibility lives. ERC-3643 is a Final ERC with an audited reference implementation, while ERC-1400 remains a draft. ERC-3643 fixes eligibility to signed identity claims that several tokens can reuse, while ERC-1400 leaves the rules to each issuer. Neither design makes a token freely usable in DeFi: a pool, vault or lending market can hold an ERC-3643 token only if its address is registered as an eligible holder. A newer option, ERC-7943, reached Final status in May 2026 as a minimal interface with canTransfer, freeze and forced-transfer functions and no mandatory identity layer (Ethereum ERCs repository, 2026).

With the compliance designs mapped, a direct comparison shows which differences are real and which are labels.

How Do ERC-20, ERC-721, ERC-1400, and ERC-3643 Compare Across Fungibility and Compliance?

The five standards differ on fungibility, transfer restrictions, where compliance logic lives, ERC-20 compatibility and formal status. ERC-3643 is the only one that combines a Final specification with a built-in identity layer. That makes it the most fully specified open option for regulated assets, but not the one the largest issuers use.

Fungibility, Compliance Architecture, and Wallet Compatibility Across All Five Standards

ERC-20, ERC-1400 and ERC-3643 all expose the ERC-20 interface, so standard wallets can display balances and call transfer. ERC-721 and ERC-1155 use different interfaces built around token IDs and are not ERC-20 compatible. On compliance, ERC-20, ERC-721 and ERC-1155 carry none. The ERC-1400 family checks transfers against rules the issuer writes, with optional signed data. ERC-3643 checks the receiver against an identity registry and the transfer against a compliance contract. In both permissioned designs a transfer to an unapproved address reverts, so ERC-20 compatibility means a wallet can read and call the token, not that any DeFi protocol can hold it.

ISO Proposal, Formal Status, and What the Largest Issuers Actually Use

ERC-3643 is the only one of the five with an active proposal to become an International Organization for Standardization (ISO) standard. The ERC3643 Association, Tokeny and ONYZE announced in November 2025 an initiative led by the Spanish national committee of ISO/TC 307, which planned to submit a New Work Item Proposal (ERC3643 Association, 2025). No ISO standard has been issued. The association also reports talks with regulators including the U.S. Securities and Exchange Commission (SEC) and the Monetary Authority of Singapore (MAS), which is engagement, not endorsement (ERC3643 Association, 2024). In deployment, the largest issuers chose none of the open standards. Securitize's $4.3B in tokenized assets under management (AUM) at 30 June 2026 runs on its own DS Protocol (Securitize SEC filing, 2026). Ondo and Centrifuge use their own permissioned ERC-20 designs.

Data current as of October 2026.

Knowing how the standards compare is only half the decision. The other half is which design fits a specific asset and who will run its rules.

Which Token Standard Should a Project Choose for Equity, Debt, Real Estate, or Collectibles?

Standard selection shapes every later compliance, liquidity and exit option. The first split is simple: an asset either needs transfer restrictions or it does not. The second is harder: if it does, the issuer must decide whether to adopt an open standard or run its own permissioned ERC-20 design.

Token Standard Selection by Asset Type — Equity, Debt, Real Estate, Collectibles, Gaming

Fungible regulated assets, such as equities, bonds, fund units and revenue-share certificates, need a permissioned ERC-20 design. ERC-3643 suits issuers that want a Final, audited open standard and identities that investors can reuse across offerings. Issuers that act as their own transfer agent often build their own design instead, as Securitize, Ondo and Centrifuge did. Either route must answer the same questions about the offering's rules under the SEC's Regulation D, the EU's Markets in Crypto-Assets Regulation (MiCA) or MAS guidance, because the code enforces only what the issuer configures. Unique assets with no securities exposure, such as art, music rights, event tickets and game items, map to ERC-721 or ERC-1155 depending on whether batch transfers matter. Fungible protocol tokens with no investor eligibility rules stay on plain ERC-20 for maximum composability.

When ERC-1400 Wins — Complex Cap Tables and Partition-Level Vesting Schedules

ERC-1400 keeps a narrow but real use case: securities where several sub-classes with different rights must sit in the same wallet. An employee equity grant holds unvested and vested tokens that behave differently even though both sit at one address, and ERC-1410 partitions model that directly. ERC-3643 can approximate it with partial freezes or custom compliance modules, but it has no partition concept. The cost is the draft status: an issuer choosing ERC-1400 relies on a reference implementation rather than a Final specification, and Taurus's own tokenization platform offers ERC-1400 as one template beside CMTAT and ERC-3643 rather than as its default (Taurus, 2026). For DeFi use, ERC-1400 and ERC-3643 face the same requirement: the protocol's contracts must be approved as eligible holders.

Data current as of October 2026.

The selection framework looks different once the largest platforms' contracts are read directly.

How Are These Token Standards Used by Securitize, Ondo, Taurus, and Centrifuge Today?

Securitize, Ondo and Centrifuge each run a permissioned ERC-20 design of their own, and none of their flagship tokens implements ERC-3643. Taurus offers ERC-1400, ERC-3643 and the Swiss CMTAT standard as templates, and its own documented issuance used CMTAT. Polymath, whose staff wrote ERC-1400, moved its compliance logic into a separate blockchain.

Securitize, Ondo, and Centrifuge — Proprietary Permissioned ERC-20 Designs

BlackRock's BUIDL fund token runs on Securitize's DS Protocol. Securitize's developer documentation says its tokenized assets follow the DS Protocol, an ERC-20 extension with a registry service of verified investors and a compliance service of transfer rules (Securitize, 2026). On Ethereum the BUIDL contract answers getDSService queries with its trust, registry and compliance service contracts, and calls to ERC-3643's identityRegistry, onchainID and compliance functions revert, a check of the deployed contract on 5 October 2026 (Etherscan, 2026). Securitize reported $4.3B in tokenized AUM at 30 June 2026 and $14.4M in second-quarter revenue, and said BUIDL became available as yield-bearing collateral through a framework involving OKX and Standard Chartered (Securitize SEC filing, 2026). Ondo uses several designs of its own. Its OUSG and rOUSG contracts check holders against Ondo's KYC registry, USDY checks an allowlist, a blocklist and a sanctions list, and its tokenized stocks such as TSLAon call an Ondo compliance contract (Etherscan, 2026). Centrifuge's JAAA share token exposes ERC-1404's detectTransferRestriction and messageForTransferRestriction functions and routes each transfer through a separate restriction hook contract (Etherscan, 2026). None of the six contracts carries ERC-3643's identityRegistry, forcedTransfer or recoveryAddress functions.

Taurus and Polymath — ERC-1400, CMTAT, and a Purpose-Built Chain

Taurus, the Swiss digital asset infrastructure firm, lists CMTAT, ERC-1400 and ERC-3643 among the templates on its Taurus-CAPITAL tokenization platform (Taurus, 2026). Its documented production issuance, the SCCF-2 trade finance note on Ethereum, followed the Capital Markets and Technology Association (CMTA) standard (Taurus, 2024). CMTAT is an ERC-20 extension that exposes ERC-1404's restriction functions and checks transfers through an optional rule engine. Taurus's own analysis notes that ERC-1400 never reached Final status, unlike ERC-3643 (Taurus, 2025). Polymath, whose team wrote ERC-1400, later built Polymesh, a permissioned public blockchain that its developers say was inspired by ERC-1400 and that enforces identity and compliance rules in the chain itself rather than in token contracts (Polymesh, 2026).

Data current as of October 2026.

The gap between the open standards and what issuers deploy shapes where token standards go next.

How Will Token Standards Evolve as Cross-Chain Compliance and DeFi Composability Demands Grow?

The next phase runs on three tracks: the ERC-3643 ISO proposal, smaller shared interfaces such as ERC-7943 that let different designs speak to the same tools, and the plumbing that lets permissioned tokens move between chains and into DeFi without losing their checks.

Cross-Chain Portability and the ERC-3643 ISO Proposal

The ISO work on ERC-3643 is at an early stage: a national committee initiative announced in November 2025 that planned a New Work Item Proposal (ERC3643 Association, 2025). If ISO adopts it, ERC-3643 would gain a reference that traditional financial institutions already use, but no timetable has been published. On portability, ONCHAINID identity contracts deploy from a factory at the same address on every Ethereum Virtual Machine (EVM) chain, so a claim signed on one chain can be read on another (ONCHAINID documentation, 2026). Proprietary designs solve the same problem in their own ways, and Securitize, Ondo and Centrifuge all run their tokens on several chains. ERC-7943 points to a likely middle path: a minimal shared interface for checks, freezes and forced transfers that proprietary designs could adopt without giving up their own registries.

Composable RWA Tokens as DeFi Collateral in Lending and Money Markets

Permissioned tokens reach DeFi only through contracts the issuer approves. Securitize's VaultRegistrar lets approved DeFi protocols register vault addresses under an existing investor identity with the investor's signature (Securitize, 2026), and Securitize reported that BUIDL became usable as collateral in a framework with OKX and Standard Chartered (Securitize SEC filing, 2026). The same rule applies to ERC-3643 tokens, whose receiving addresses must be registered and verified. As more pools and vaults are approved, tokenized funds can serve as collateral, but each step runs through the issuer's registry, whichever standard sits underneath.

FAQ

References / Sources