How ERC-20 Tokens Work

Most tokens on Ethereum follow the same rulebook. Not because they're built by the same team, but because they conform to a shared standard — ERC-20 — that defines exactly how a token contract must behave so that wallets, exchanges, and other smart contracts can interact with any of them without custom code for each one.

The interesting part isn't any specific token. It's the interoperability that this standard makes possible, and the mechanism underneath it — particularly the approve/transferFrom pattern that powers most DeFi interactions and introduces most of the approval-related risk that users encounter.

The Standard and Its Required Interface

ERC-20 stands for Ethereum Request for Comment number 20. Proposed in 2015 and finalized in 2017, it defines six mandatory functions and two events that every compliant token contract must implement:

Required functions:

• totalSupply() — returns the total token supply
• balanceOf(address) — returns the token balance of a given account
• transfer(address, amount) — moves tokens from the caller to a recipient
• transferFrom(address, address, amount) — moves tokens on behalf of another account, after approval
• approve(address, amount) — grants another address permission to spend tokens on your behalf
• allowance(address, address) — returns how much an approved address is still permitted to spend

Required events:

• Transfer — emitted every time tokens move between addresses
• Approval — emitted every time an allowance is set or modified

Any contract that exposes these functions with these exact signatures is ERC-20 compatible. Wallets can display balances, exchanges can list the token, and protocols can accept deposits — all without knowing anything else about the specific token.

The Approve/TransferFrom Mechanism

This two-step pattern deserves attention because it governs most DeFi interactions, and misunderstanding it is the source of a lot of user-facing risk.

When you deposit tokens into a DeFi protocol — a lending platform, a DEX, a yield vault — you don't send tokens directly to the contract. Instead:

1. You approve the contract to spend a specified amount of your tokens by calling approve(contractAddress, amount)
2. The contract calls transferFrom to pull the approved tokens into itself when you trigger the deposit

The protocol never holds your private key. It uses the allowance you granted to pull tokens at the moment the transaction executes.

The structural implication: approvals persist on-chain until explicitly revoked. If you approve a protocol to spend unlimited tokens and that contract is later exploited or upgraded with malicious logic, the attacker can drain your entire approved balance — not just what you intended to deposit. The ERC-20 standard doesn't enforce expiry, spending caps relative to current deposits, or time limits on approvals. That's left entirely to implementation choice.

Tokens are smart contracts deployed on Ethereum. There's nothing in the Ethereum protocol itself that natively supports ERC-20 — ETH isn't ERC-20 compliant. The standard is a social and technical convention: if your contract exposes these functions, infrastructure will treat it as a token.

Anyone can deploy an ERC-20 contract. The standard doesn't constrain supply caps, minting authority, burn mechanisms, or any other economic property. Two tokens can share the same ticker symbol — there's no registry enforcing uniqueness. Token identity is the contract address, not the name.

Where Constraints Live

ERC-20 operates inside Ethereum's execution layer, which means every token transfer costs gas. High network congestion makes token interactions more expensive, and complex multi-step operations (approve, then deposit, then stake) compound that cost.

One architectural constraint: ERC-20's transfer function triggers no logic in the receiving contract. If you accidentally send tokens directly to a contract address that doesn't know how to handle them, they may be permanently locked. This is different from ETH transfers, which can trigger fallback functions. ERC-721 addressed this with safeTransferFrom, but ERC-20 has no equivalent safety check.

The optional name(), symbol(), and decimals() fields exist by convention but aren't enforceable. Malicious tokens frequently impersonate legitimate ones by copying names and symbols — the only reliable identifier is the contract address.

What's Changing

ERC-20 itself is stable. Modifying the standard would break compatibility with thousands of deployed contracts, so the interface isn't going anywhere.

What's evolving is the execution layer around it. ERC-2612 adds a permit function enabling approvals via signed messages (off-chain signatures) rather than on-chain transactions. This collapses the approve + action pattern into a single transaction, reducing gas and improving UX. Adoption is expanding gradually across newer protocols and tokens.

Account abstraction (EIP-4337) allows wallets to batch multiple operations into a single user transaction — approve and deposit in one step, from the user's perspective, even if they're technically sequential on-chain. The ERC-20 interface doesn't change; the execution context gets smarter around it.

What Would Confirm This Direction

ERC-2612 permit adoption expanding to major token contracts (USDC already supports it). Rising share of DeFi interactions using permit-based approvals rather than separate approve transactions. Account abstraction wallet deployments that surface token interactions without requiring users to manage raw approvals manually.

What Would Break or Invalidate It

A successor standard displacing ERC-20 would require near-universal migration — unlikely given the switching costs and network effects involved. ERC-777 was proposed as an upgrade and largely abandoned after repeated re-entrancy exploits introduced by its callback mechanism. No current successor is positioned to replace ERC-20 at scale.

The more realistic scenario is Ethereum losing token issuance dominance to chains where ERC-20 compatibility is irrelevant or implemented differently. That would change where the standard matters, not whether it works as designed.

Timing Perspective

Now: ERC-20 is the operative standard for tokens on Ethereum and all EVM-compatible chains. The approve/transferFrom mechanism is active in essentially every DeFi interaction.

Next: ERC-2612 permit adoption is growing — relevant when auditing which protocols require fewer approval transactions.

Later: Any systemic account abstraction shift that changes how approvals are managed in aggregate. Not an active variable in the current cycle.

Boundary Statement

This covers how the ERC-20 standard works mechanically. It doesn't evaluate any specific token — standard compliance means nothing about what a token represents, who controls the mint function, or whether the surrounding contract logic is trustworthy.

The interface is a convention, not a guarantee. Interface compliance only means the contract answers the right questions in the expected format. What it does with the answers is a separate question entirely.