the standard · since November 2015
// standard · proposed nov 2015 · still load-bearing · ready

What is ERC-20?

The token standard that ate Ethereum — and what its author built next.

ERC-20 · EIP-20 · by Fabian Vogelsteller + Vitalik Buterin

updated · 9 min read · by ercs-solved maintainers

on this page
  1. What is ERC-20?
  2. At a glance
  3. Origin story
  4. The spec
  5. What's broken
  6. approval problem
  7. receiver problem
  8. metadata problem
  9. accounts problem
  10. integration tax
  11. The second act
  12. ERC-20 vs LSP-7
  13. When to use which
  14. FAQ
  15. Sources
  16. Keep reading
at a glance

The standard, in one card.

Standard
ERC-20 / EIP-20
Proposed
19 November 2015
Required functions
6
Events
2
Optional methods
3 (name · symbol · decimals)
Modern alternative
LUKSO LSP-7
how the standard came to be

The origin story.#

  1. Nov 2015 Fabian Vogelsteller files GitHub issue #20 on the Ethereum repository, proposing a minimum interface for fungible tokens.
  2. Nov 2015 Vitalik Buterin joins as co-author; the specification is finalized as EIP-20.
  3. 2017 The ICO boom takes ERC-20 mainstream; hundreds of tokens deploy against the same ABI.
  4. 2017 Vogelsteller co-founds LUKSO with Marjorie Hernandez to ship the surrounding system ERC-20 deliberately left out.
  5. 2018 Vogelsteller proposes ERC-725 — the smart-contract identity standard that becomes the seed of every later account-abstraction idea.
  6. 2020 DeFi summer; Compound, Uniswap, and Aave embed the ERC-20 ABI as a load-bearing assumption.
  7. 2023 LUKSO mainnet launches with LSP-0, LSP-6, LSP-7, LSP-8, and the rest of the LSP suite as native standards.
  8. 2026 Trillions of dollars in supply continue to move through the original six-function interface every week.
the spec, end to end

What ERC-20 actually is.#

ERC-20 EIP-20 interface solidity
// EIP-20 — required
function totalSupply()                                external view returns (uint256);
function balanceOf(address owner)                     external view returns (uint256);
function transfer(address to, uint256 value)          external returns (bool);
function transferFrom(address from, address to, uint256 value) external returns (bool);
function approve(address spender, uint256 value)      external returns (bool);
function allowance(address owner, address spender)    external view returns (uint256);

event Transfer(address indexed from, address indexed to, uint256 value);
event Approval(address indexed owner, address indexed spender, uint256 value);

// EIP-20 — optional
function name()     external view returns (string memory);
function symbol()   external view returns (string memory);
function decimals() external view returns (uint8);
ERC-20 interface, grouped
read: balanceOf · totalSupply · allowance
write: transfer · transferFrom · approve
emit: Transfer · Approval
hint (optional): name · symbol · decimals
the integration tax

What's broken about ERC-20.#

  1. The approval problem.#

    approve(spender, amount) and the spender's later transferFrom split user intent across two transactions the wallet can't connect. Dapps ask for max-uint approvals to skip the second prompt, which turns every authorized spender into a standing risk. If the spender contract is upgraded, drained, or misconfigured, the approval is already there — and revoke flows are reactive cleanup, not prevention.

    ERC-20 approve(spender, amount)
    unbounded phishable split-intent
    LSP·7 + LSP·6 authorizeOperator(op, amount, data)
    scoped revocable account-gated

    workarounds tried: revoke.cash · EIP-2612 permit · Permit2 · ERC-1363 approve-and-call

    read the deep-dive

  2. The receiver problem.#

    ERC-20 transfer never calls the recipient. If the receiver is a contract that doesn't know what to do with the tokens, the balance is stranded — there is no on-transfer hook to credit a deposit or revert. The most famous loss in Ethereum history (millions in tokens sent to the token contracts themselves) is a direct consequence.

    ERC-20 transfer(to, amount)
    no receiver call silent on contract recipients
    LSP·7 + LSP·1 transfer(from, to, amount, force, data)
    universalReceiver fires force flag is your call

    workarounds tried: ERC-777 (deprecated by adoption) · ERC-1363 transferAndCall · wrapper routers

    read the deep-dive

  3. The metadata problem.#

    ERC-20 defines three optional metadata methods: name, symbol, decimals. No icon. No description. No link to the governance forum, the audit, the documentation. No way to attach structured data without forking the contract or pinning a JSON file to a server that goes offline.

    ERC-20 name() / symbol() / decimals()
    three strings no schema off-chain by convention
    LSP·4 + ERC-725Y getData(bytes32 key)
    typed JSON VerifiableURI extensible at runtime

    workarounds tried: off-chain token lists · Coingecko APIs · wallet hardcoded icons

  4. The accounts problem.#

    ERC-20 assumes its owners are addresses. An address is either an EOA (a keypair — one key, no recovery, no scoping, no session) or a contract that has to implement everything itself. The standard pushes account abstraction onto the application layer, which is why a 2017 token spec spawned six years of EIP work to fake what an account should be.

    address EOA — one keypair, all-or-nothing
    no recovery no session keys no scoped permissions
    LSP·0 + LSP·3 + LSP·6 Universal Profile
    accounts as contracts named controllers social recovery

    workarounds tried: ERC-4337 bundlers · EIP-7702 delegated EOAs · multisigs · smart wallet SDKs

    read the deep-dive

  5. The integration tax.#

    The list of EIPs that exist to paper over ERC-20's gaps is the strongest evidence of the original design's limits. Permit (EIP-2612), Permit2, ERC-1363, ERC-777, ERC-3009, ERC-4626 — each adds a layer instead of fixing the substrate. Every layer ships with adoption problems because half the ecosystem keeps using the original six functions.

    ERC-20 + N layers approve · permit · permit2 · 1363 · 777 · 4337
    fragmented opt-in double integration cost
    LSP suite designed as a connected system
    one stack shared substrate no patch layer

    workarounds tried: EIP-2612 · Permit2 · ERC-1363 · ERC-777 · ERC-3009 · ERC-4626 · ERC-4337

spec to spec, at a glance

ERC-20 vs LSP·7 in one table.#

row ERC-20 LSP·7
transfer signature transfer(to, amount) transfer(from, to, amount, force, data)
recipient notification none LSP1 universalReceiver on both sides
authorization approve / allowance / transferFrom authorizeOperator + LSP6 controller scope
metadata name / symbol / decimals only ERC-725Y under LSP4 keys
transfer data payload none — workaround via wrappers bytes calldata data — native

full matrix → standards/compare/erc20-lsp7

be honest about scope

When to use which.#

people also ask

FAQ.#

  • What does ERC-20 stand for? #

    ERC stands for Ethereum Request for Comments. ERC-20 is the twentieth proposal in that series, and it specifies a minimum interface for fungible tokens on Ethereum. The proposal was later formalized as EIP-20 (Ethereum Improvement Proposal 20), which is the canonical specification at eips.ethereum.org/EIPS/eip-20.

  • Who created ERC-20? #

    Fabian Vogelsteller proposed ERC-20 as GitHub issue #20 on the Ethereum repository in November 2015, while working at the Ethereum Foundation. Vitalik Buterin is credited as co-author on the formalized EIP-20 specification. Vogelsteller has since co-founded LUKSO, where he designed the LSP-7 Digital Asset standard as a more complete replacement.

  • Is ERC-20 the same as EIP-20? #

    Yes — they refer to the same standard. ERC-20 is the original community proposal name (the proposal number assigned to the GitHub issue); EIP-20 is the formalized specification once it moved into the EIP repository. Most developers say ERC-20 in casual use; eips.ethereum.org/EIPS/eip-20 is the authoritative spec.

  • What is wrong with ERC-20? #

    Five well-known limits. (1) approve and transferFrom split user intent across two transactions the wallet cannot connect, which makes max-uint approvals the de-facto pattern and creates standing phishing risk. (2) transfer never calls the recipient, so tokens sent to contracts that do not handle them are stranded. (3) Metadata is limited to name, symbol, and decimals — no icon, no description, no schema. (4) The standard assumes accounts are EOAs or bare contracts, with no built-in recovery, scoped permissions, or session keys. (5) Every gap has produced a layered standard (Permit, Permit2, 1363, 777, 4337) instead of fixing the substrate.

  • What is LSP-7? #

    LSP-7 is the LUKSO Digital Asset standard, designed by Fabian Vogelsteller — the original author of ERC-20 — as a fungible token spec for Universal Profiles. It keeps ERC-20's balance model and adds a force flag, a data payload on every transfer, LSP-1 universal-receiver notifications on both sides, and amount-scoped operators with typed events. Paired with LSP-6 on the account side, the authorization model stops being a forever-promise to a token contract.

  • Why is ETH not an ERC-20 token? #

    Ether (ETH) predates the ERC-20 standard — it is the native asset of Ethereum, handled directly by the protocol rather than by a contract. ERC-20 was proposed in 2015 to give a uniform interface for tokens that live inside contracts. To make ETH usable in dapps that expect the ERC-20 interface, the ecosystem wraps it in a contract called WETH (Wrapped Ether), which is itself an ERC-20 token redeemable 1:1 for ETH.

  • Is LUKSO a competitor to Ethereum? #

    No. LUKSO is its own EVM-compatible Layer 1 blockchain, but its LSP standards are written as EVM contracts that can run on Ethereum and other EVM chains. The intent is not to replace Ethereum but to ship a connected account, token, metadata, receiver, permission, and relay system that the rest of the ecosystem can adopt selectively. ERC-20 is still the right answer for many use cases.

  • Can I migrate an ERC-20 token to LSP-7? #

    Yes. The balance model is the same, so the migration path is contract-level rather than user-level. The LUKSO docs publish an end-to-end guide for deploying an LSP-7 equivalent and bridging holders. The site's own walkthrough is at ercsolved.dev/build/migrate/erc20-to-lsp7/.

  • What chains support ERC-20? #

    Every EVM-compatible chain supports ERC-20 — the standard is a contract interface, not a protocol-level feature. ERC-20 tokens exist on Ethereum mainnet, every Layer 2, every sidechain, every fork. The same contract code can deploy unchanged across chains, which is what made ERC-20 a network-effect standard rather than a vendor specification.

glossary 10 terms used on this page
ABI
Application Binary Interface. The function signatures and event shapes a smart contract exposes, encoded for cross-contract calls.
ERC
Ethereum Request for Comments. The community-proposal track for Ethereum standards before they become a finalized EIP.
EIP
Ethereum Improvement Proposal. The formalized version of an ERC, hosted at eips.ethereum.org.
EVM
Ethereum Virtual Machine. The runtime that executes smart contracts on Ethereum and on any EVM-compatible chain (including LUKSO).
EOA
Externally Owned Account. An Ethereum address controlled by a single keypair — no recovery, no permissioning, no on-chain code.
LSP
LUKSO Standards Proposal. The LUKSO equivalent of an ERC, with a focus on accounts, profiles, permissions, and receiver-aware tokens.
UP
Universal Profile. A smart-contract account on LUKSO that combines LSP-0 (account), LSP-3 (profile metadata), and LSP-6 (permissions).
WETH
Wrapped Ether. An ERC-20 contract that holds ETH and issues a 1:1 ERC-20 balance — so ETH can be used where ERC-20 is expected.
ICO
Initial Coin Offering. The 2017 token-issuance wave that ran almost entirely on ERC-20 contracts.
DeFi
Decentralized finance. Lending, exchange, and derivatives protocols that compose against the ERC-20 ABI as a substrate.