What is ERC-20?

How ERC-20 came to be.#

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 LSP0, LSP6, LSP7, LSP8, 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.

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);

What's broken about ERC-20.#

1. 01

   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

   becomes

   +

   LSP7 + LSP6 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. 02

   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

   becomes

   +

   LSP7 + LSP1 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. 03

   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

   becomes

   +

   LSP4 + ERC-725Y getData(bytes32 key)

   typed JSON ·VerifiableURI ·extensible at runtime

   workarounds tried

   • off-chain token lists
   • Coingecko APIs
   • wallet hardcoded icons
4. 04

   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

   becomes

   +

   LSP0 + LSP3 + LSP6 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. 05

   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

   becomes

   +

   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

So Fabian Vogelsteller built LUKSO.#

• LSP0 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. →
• LSP3 Profile Metadata Name, avatar, bio, links — stored on the account itself under typed ERC-725Y keys. Profiles are first-class, not third-party. →
• LSP6 Key Manager Permissions are an account property, not a token allowance. Granular controllers with allowed calls, standards, value caps, and instant revocation. →
• LSP1 Universal Receiver Every transfer notifies sender and receiver through one entry point. The on-transfer hook ERC-20 left out, generalised across asset types. →
• LSP4 Digital Asset Metadata Typed token metadata under ERC-725Y. Icons, descriptions, links, attributes — schema'd, not stringly-typed. →
• LSP7 Digital Asset Fungible tokens with native receiver hooks, transfer data payload, and operator authorization that pairs with LSP6 account permissions. →
• LSP8 Identifiable Digital Asset Non-fungible tokens with bytes32 token IDs, on-chain typed metadata, and the same receiver-aware transfer model. →
• LSP25 Execute Relay Call Signed messages that a third party can submit on-chain. Gasless onboarding without bundlers, paymasters, or a bolted-on mempool. →

How ERC-20 and LSP7 Digital Asset compare.#

full matrix → erc-20 vs lsp7 →

When to use ERC-20 vs LSP7 Digital Asset.#

FAQ.#

• 01

  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.

• 02

  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 LSP7 Digital Asset standard as a more complete replacement.

• 03

  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.

• 04

  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.

• 05

  What is LSP7? #

  LSP7 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, LSP1 universal-receiver notifications on both sides, and amount-scoped operators with typed events. Paired with LSP6 on the account side, the authorization model stops being a forever-promise to a token contract.

• 06

  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.

• 07

  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.

• 08

  Can I migrate an ERC-20 token to LSP7? #

  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 LSP7 equivalent and bridging holders. The site's own walkthrough is at ercsolved.dev/build/migrate/erc20-to-lsp7/.

• 09

  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.

Keep reading.#

• erc-725 account → LSP0
• profile metadata → LSP3
• key manager → LSP6
• universal receiver → LSP1
• digital asset metadata → LSP4
• digital asset → LSP7
• identifiable digital asset → LSP8
• execute relay call → LSP25
• erc-20 vs lsp7 (full matrix) → comparison
• all ERC ↔ LSP mappings → matrix
• start from your problem → problems