ERC-20 standardised transfer, not a token's worth

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A six-function interface, dated precisely

EIP-20 was created on 19 November 2015, authored by Fabian Vogelsteller and Vitalik Buterin. The standard specifies six required functions, transfer, transferFrom, approve, balanceOf, totalSupply and allowance, plus two required events, Transfer and Approval. Optional name, symbol and decimals functions supply display metadata for wallets. The document's own framing is narrow: it 'allows for the implementation of a standard API for tokens within smart contracts,' so that 'any tokens on Ethereum' can be 're-used by other applications: from wallets to decentralized exchanges.' It is an interface specification, not a description of what any particular token represents or is worth.

What the interface deliberately leaves silent

Nothing in EIP-20 requires that a token have any exchangeable value, a working product behind it, a capped or auditable supply, or any legal claim attached to holding it. The standard's job ends at making balances transferable and approvable in a predictable way; a contract that satisfies all six functions has met the standard whether it backs a functioning payments network or nothing at all. This is by design, and it is also the standard's principal risk in practice: a shared interface makes issuing a token cheap, and cheapness of issuance says nothing about the issuer's honesty. The ethereum.org documentation, as retrieved on 16 September 2026, states that at least $83,656,418 worth of ERC-20 tokens have been permanently lost by being sent to contracts not built to receive them, a loss the interface itself has no mechanism to prevent or reverse.

A fungibility guarantee, not a value guarantee

What EIP-20 does guarantee, when correctly implemented, is fungibility: one unit of a given token contract is interchangeable with any other unit of that same contract, verified by reading balanceOf and totalSupply rather than by trusting an issuer's word. That guarantee sits on top of Ethereum's contract-storage model described in the original whitepaper, in which a token's balances are simply entries in that contract's own storage. The distinction that matters for a reader is between the standard's technical guarantee, which is real, checkable and enforced by every validating node, and any promotional claim about a token's usefulness or future price, which the interface neither evaluates nor enforces.

• Does the token contract implement all required functions correctly, or only the ones a particular wallet interface happens to call?
• What, if anything, backs the token's claimed usefulness beyond satisfying this interface?
• Has a transfer to a specific contract address been verified as compatible, given that incompatible transfers are irreversible?

A standard interface solved a real coordination problem: wallets and exchanges no longer need bespoke code for every token. It did not, and was never meant to, solve the separate problem of knowing whether any given token is worth holding.