Every other token standard in this chapter either extends ERC-20 or replaces a specific part of it. Before talking about institutional standards (ERC-1400, ERC-3643, ERC-7540) it is worth being precise about what ERC-20 actually does, what it deliberately does not do, and why USDC, USDT, JPMD and the underlying BUIDL token all sit on top of it. The interesting question for a regulated issuer is not whether to use ERC-20, it is what to add on top of it so the token can satisfy investor-eligibility, jurisdictional, and forced-transfer requirements that ERC-20 was never designed to express.
What ERC-20 actually defines
A minimum interface, nothing more. ERC-20 is a six-function interface plus two events: transfer(to, amount), transferFrom(from, to, amount), balanceOf(owner), approve(spender, amount), allowance(owner, spender), and totalSupply(), with Transfer and Approval events emitted on state changes. Anything else (mint, burn, pause, role-based access, freeze) is implementation detail layered above the interface, not part of the standard.
The interface tells a wallet, a DEX, a custodian, or an indexer how to talk to the token without having to read the contract. That is the entire value proposition. ERC-20 succeeded because it gave the ecosystem a stable schema, not because it was clever.
What ERC-20 deliberately does not do
No identity, no jurisdiction, no eligibility, no forced transfer. The standard has no concept of who a holder is, where they sit, what licence the issuer holds, or whether a transfer should be allowed for any reason other than balance and allowance. From the contract's perspective every address is interchangeable. If balanceOf(from) >= amount and the caller has the necessary allowance, the transfer goes through. There is no canTransfer hook, no jurisdiction tag, no investor-class field, and no way for the issuer to claw a token back.
This is by design. ERC-20 was specified in 2015 inside a permissionless-by-default ethos. Adding identity into the base standard would have made it unimplementable across the wallets and exchanges of the day. The decision to leave compliance out of the interface is exactly what made the standard universal and exactly what makes it insufficient on its own for a regulated security.
Why payment stablecoins live happily on ERC-20
USDC, USDT, JPMD and the bearer-style payment-stablecoin family are happy with ERC-20 because their compliance posture is "freeze and burn at the issuer's discretion, otherwise let the token move freely." The eligibility test for holding a USDC token is essentially "do not appear on a sanctions list," and that test is enforced by an off-chain sanctions screen feeding an on-chain blocklist that the issuer maintains. The token contract itself remains a vanilla ERC-20 with a blacklist(address) extension and pause() capability tacked on. Circle's USDC contract is the reference shape for this: ERC-20 plus a pausable, blacklistable, mintable role.
This pattern works for payment instruments because the regulator's expectation is "stop the bad addresses, otherwise the token is bearer." It does not work for a security because the regulator's expectation flips: only approved addresses may hold the token, and every transfer must be checked.
Where the underlying tokens for tokenised MMFs sit
BlackRock's BUIDL, issued through Securitize, runs on Ethereum at the protocol level as something that looks ERC-20-shaped to a wallet but is wrapped with permissioning logic that ERC-20 does not specify. The same is true of MONY, Franklin Templeton's FOBXX, and Ondo Finance's OUSG. A wallet querying balanceOf on these tokens gets a sensible answer; an attempt to call transfer to a non-whitelisted address reverts. The contract is presenting the ERC-20 surface so that the existing custody, indexing, and DeFi-adjacent infrastructure can read balances, while enforcing eligibility checks below the interface that ERC-20 itself does not require.
That layering, ERC-20 surface plus institutional-grade compliance below it, is the architectural pattern the rest of this chapter unpacks. The institutional standards (ERC-1400, ERC-3643, ERC-7540) all keep the ERC-20 interface visible because the cost of breaking it (every wallet, every block explorer, every DeFi protocol has to be told about a new standard) is too high. They differ in how they implement the layer above it.
What this means for the rest of the chapter
ERC-20 is the floor, not the building. When an institutional issuer says "the token is on Ethereum," the relevant follow-up is not "is it ERC-20" (the answer is almost always yes, in the sense that the interface is present) but "what compliance layer sits between the ERC-20 surface and the underlying state changes, and is that layer expressed at the protocol level or only enforced off-chain." Part 2 walks through the first serious attempt to encode that layer at the protocol level (ERC-1400) and why it lost to a cleaner design. Part 3 covers the design that won (ERC-3643 / T-REX). Part 4 covers the asynchronous case (ERC-7540) where the deposit-and-redemption mechanic itself has to be re-shaped because the underlying asset cannot settle instantly. Part 5 ties the architectural pattern back to the operational consequences for custody, transfer agents, and secondary markets.