Token Standards Explained

Standards like ERC-20 for fungible tokens and ERC-721 for non-fungible tokens (NFTs) provide essential functions, but contracts can still add extra logic and rules.

At the simplest level, a token on Ethereum is not a separate blockchain, but a smart contract that keeps a ledger of balances. For a wallet or decentralized application (dApp) to interact with a token, it needs the contract's address, not a separate chain ID.

For fungible tokens, ERC-20 is the foundational standard. It defines core functions like approve(address _spender, uint256 _value), allowance(address _owner, address _spender) , and transfer(address _to, uint256 _value). The allowance functions support delegated spending. An owner can set an allowance for a spender address, who can then transfer tokens up to that limit without the owner's direct approval for each transaction.

The ERC-20 docs show the standard defining an interface, not a total policy for a token. The two core events defined are Transfer and Approval, which notify listeners of observable actions, but not the full legal and economic context applied by the contract.

For non-fungible tokens, ERC-721 defines the standard focused on uniqueness. Each ERC-721 token combines a contract address with a tokenId that is unique across the contract. This means a user can hold multiple items from the same contract, each distinguished by its tokenId.

Metadata for ERC-721 tokens is typically served through a JSON file, with the token’s metadata URI stored in the contract. This lets the NFT reference data like images, which is usually stored off-chain, outside the size limits of on-chain transaction data. The contract specifies a pointer to the metadata.

For more complex collections that mix fungible and non-fungible items, ERC-1155 is the standard. It uses a single-contract model to represent multiple types of balance in a gas-efficient way. Games and decentralized applications that handle a mixed inventory of items, like weapons and plants, often use ERC-1155. The fungibility-agnostic model lets a single contract represent different categories of items together.

While ERC-20 defines core functions, it does not force a contract to implement them in a specific way. Contracts can include extra logic beyond the base interface, like permit-style approvals or mechanisms to add minting, blacklist, or transfer fee rules. The standard is an interface, not a guarantee of behavior.

This is also visible in wrapped ether, a popular ERC-20 token. A base ERC-20 contract might not cover the native ether handling of Ethereum. Wrapped ether serves as a way to handle ETH within an ERC-20 framework, providing a consistent interface where the standard contract does not exist.

Token standards let wallets, dApps, and other systems interact with given contracts in a meaningful way. But users should be aware that a contract can follow a standard while still enforcing its own rules beyond that interface. The flexibility of standards is crucial to Ethereum's adaptability, but lets users shape the behavior of each specific token.