What is ERC-20?
The token standard that ate Ethereum — and what its author built next.
on this page
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
- Canonical spec
- eips.ethereum.org / EIP-20
The origin story.#
- Nov 2015 Fabian Vogelsteller files GitHub issue #20 on the Ethereum repository, proposing a minimum interface for fungible tokens. ↗
- Nov 2015 Vitalik Buterin joins as co-author; the specification is finalized as EIP-20. ↗
- 2017 The ICO boom takes ERC-20 mainstream; hundreds of tokens deploy against the same ABI.
- 2017 Vogelsteller co-founds LUKSO with Marjorie Hernandez to ship the surrounding system ERC-20 deliberately left out. ↗
- 2018 Vogelsteller proposes ERC-725 — the smart-contract identity standard that becomes the seed of every later account-abstraction idea. ↗
- 2020 DeFi summer; Compound, Uniswap, and Aave embed the ERC-20 ABI as a load-bearing assumption.
- 2023 LUKSO mainnet launches with LSP-0, LSP-6, LSP-7, LSP-8, and the rest of the LSP suite as native standards. ↗
- 2026 Trillions of dollars in supply continue to move through the original six-function interface every week.
What ERC-20 actually is.#
// 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);
balanceOf · totalSupply · allowance transfer · transferFrom · approve Transfer · Approval name · symbol · decimals What's broken about ERC-20.#
-
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-20approve(spender, amount)LSP·7 + LSP·6authorizeOperator(op, amount, data)workarounds tried: revoke.cash · EIP-2612 permit · Permit2 · ERC-1363 approve-and-call
-
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-20transfer(to, amount)LSP·7 + LSP·1transfer(from, to, amount, force, data)workarounds tried: ERC-777 (deprecated by adoption) · ERC-1363 transferAndCall · wrapper routers
-
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-20name() / symbol() / decimals()LSP·4 + ERC-725YgetData(bytes32 key)workarounds tried: off-chain token lists · Coingecko APIs · wallet hardcoded icons
-
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.
addressEOA — one keypair, all-or-nothingLSP·0 + LSP·3 + LSP·6Universal Profileworkarounds tried: ERC-4337 bundlers · EIP-7702 delegated EOAs · multisigs · smart wallet SDKs
-
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 layersapprove · permit · permit2 · 1363 · 777 · 4337LSP suitedesigned as a connected systemworkarounds tried: EIP-2612 · Permit2 · ERC-1363 · ERC-777 · ERC-3009 · ERC-4626 · ERC-4337
So Fabian Vogelsteller built LUKSO.#
- LSP·0 ERC-725 Account A smart-contract account that is the user — not a wrapper around one. Owns assets, executes calls, holds typed key/value storage.
- LSP·3 Profile Metadata Name, avatar, bio, links — stored on the account itself under typed ERC-725Y keys. Profiles are first-class, not third-party.
- LSP·6 Key Manager Permissions are an account property, not a token allowance. Granular controllers with allowed calls, standards, value caps, and instant revocation.
- LSP·1 Universal Receiver Every transfer notifies sender and receiver through one entry point. The on-transfer hook ERC-20 left out, generalised across asset types.
- LSP·4 Digital Asset Metadata Typed token metadata under ERC-725Y. Icons, descriptions, links, attributes — schema'd, not stringly-typed.
- LSP·7 Digital Asset Fungible tokens with native receiver hooks, transfer data payload, and operator authorization that pairs with LSP·6 account permissions.
- LSP·8 Identifiable Digital Asset Non-fungible tokens with bytes32 token IDs, on-chain typed metadata, and the same receiver-aware transfer model.
- LSP·25 Execute Relay Call Signed messages that a third party can submit on-chain. Gasless onboarding without bundlers, paymasters, or a bolted-on mempool.
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
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.