Week 7 of 12 · Beginner+

Tokens: ERC-20, ERC-721, ERC-1155

You learn how a token is just a contract with a ledger inside it, and how the main Ethereum token standards differ. You also practice designing a token and reading and writing correct Solidity for it.

3 hours18 slides6 min read

Open slides Read study notes

Recap And What A Token Is Why Standards Exist ERC-20: Fungible Tokens Approve And transferFrom ERC-721: Non-Fungible Tokens ERC-1155: A Multi-Token Contract Token Design: Supply, Distribution And Purpose Writing Tokens Safely

You Will Be Able To

Explain what a token is and why a standard interface matters.
Describe how ERC-20 balances, allowances, transfer and transferFrom work.
Choose between ERC-20, ERC-721 and ERC-1155 for a given use case.
Write and deploy a simple ERC-20 contract on a test network.
Evaluate a token design for supply, distribution and purpose.

Recap And What A Token Is

In week 6 you wrote a first Solidity contract. A contract has storage, functions and events, and it lives at an address on the chain. That is all you need to build a token. A token is a contract that keeps a table of who owns how much, and that offers functions to change the table under agreed rules.

Ether, the native coin of Ethereum, is built into the protocol. Tokens are different: they are ordinary contracts. Anyone can create one in a few minutes, and the chain treats it like any other contract. The balance table is a mapping from an address to a number. When you 'own 50 tokens', it means that the mapping has the value 50 next to your address.

This also means that tokens do not sit inside your wallet. Your wallet only holds the keys. The tokens are records inside the token contract, and your keys give you the right to change your own entry.

Why Standards Exist

If every token used different function names, every wallet, exchange and app would need custom code for each one. Ethereum solves this with Ethereum Improvement Proposals, or EIPs. A subset of them, called ERCs (Ethereum Request for Comments), define interfaces that contracts agree to follow.

An interface is a list of function names, their inputs and outputs, and the events they emit. When your contract follows the ERC-20 interface, any wallet that knows ERC-20 can show your balance and send your token without knowing anything else about you. The standard is the shared language.

ERC-20: interchangeable (fungible) tokens such as currencies and points.
ERC-721: unique items, each with its own identifier.
ERC-1155: many token types, fungible and unique, in one contract.

Three Token Standards

Standard	Kind	Typical use
ERC-20	Fungible	Currencies, stablecoins, governance
ERC-721	Non-fungible	Unique items, collectibles
ERC-1155	Multi-token	Games, many item types

Standards let wallets and apps work with any compliant token. Source: EIP-20, EIP-721, EIP-1155

ERC-20: Fungible Tokens

Fungible means that one unit is worth the same as any other unit, like one euro coin and another euro coin. ERC-20 defines the functions totalSupply, balanceOf, transfer, approve, allowance and transferFrom, and the events Transfer and Approval.

The function balanceOf(owner) returns how many units an address holds. The function transfer(to, amount) moves units from the caller to another address and emits a Transfer event. Events matter because wallets and block explorers read them to build history without scanning all storage.

Decimals deserve attention. The EVM has no decimal numbers, only integers. A token with 18 decimals stores 1.5 tokens as 1500000000000000000. The decimals field is only a hint for display. All the arithmetic happens on whole numbers, which avoids rounding surprises.

Two small details help you read any token contract. The name and symbol are labels for humans, such as 'Dollar Coin' and 'USDC', and they are not unique, so two different contracts can use the same symbol. The contract address is the real identity of a token. When you add a token to a wallet, copy the address from the project's official source, because look-alike tokens with copied names are a common trap. The same care applies when an app asks you to approve spending for a token.

Decimals Of Well Known Tokens

decimals

A token amount is stored as an integer; decimals tell the interface where to place the point. Source: Token contracts as published on Ethereum mainnet

Approve And transferFrom

Sometimes a contract must move tokens on your behalf, for example a marketplace that takes payment. The contract cannot sign as you. ERC-20 solves this in two steps. First you call approve(spender, amount), which records an allowance: the spender may move up to that amount from your balance. Then the spender calls transferFrom(you, recipient, amount), and the token contract checks the allowance, reduces it and moves the tokens.

This pattern powers most of decentralized finance, which you meet in week 8. It also has a safety lesson. An allowance stays in place until you change it. Approving an unlimited amount for a contract you no longer use leaves a door open. In week 10 you will learn to review and revoke allowances.

Approve Then transferFrom

Owner calls approve
Spender is given an allowance
Spender calls transferFrom
Contract checks allowance
Balances update

This is how exchanges and apps move tokens you allow them to.

ERC-721: Non-Fungible Tokens

Non-fungible means that each unit is distinct. A concert ticket for seat 12 differs from a ticket for seat 40. ERC-721 gives every token a unique number called a token id, and the contract records one owner for each id through ownerOf(tokenId).

The standard includes transferFrom, safeTransferFrom, approve for a single token, and setApprovalForAll for an operator that manages all your tokens. The optional metadata extension adds tokenURI(tokenId), which points to a JSON description of the item, usually with a name, a description and an image link.

A common point of confusion is where the picture lives. Images are rarely stored on chain because storage is expensive. The token holds a link, and the link may point to a web server or to content-addressed storage such as IPFS. If the file behind the link disappears, the token still exists but the artwork may not. Always check what a token actually points to.

ERC-1155: A Multi-Token Contract

ERC-1155 puts many token types into one contract. Each type has an id, and the contract stores a balance for every pair of account and id. A game could use id 1 for gold coins (millions of identical units), id 2 for a sword (a limited run), and id 3 for a one-of-a-kind crown with a supply of one.

The standard supports batch operations: balanceOfBatch and safeBatchTransferFrom move several types in one transaction. Because a transaction costs gas, batching saves money for apps that handle many items. It also lets one deployment replace many separate contracts.

Token Design: Supply, Distribution And Purpose

Writing the contract is the short part. Designing the token takes more thought. Start with the purpose. Does the token represent access, a vote, a claim on a service, a reward or a collectible? A clear purpose guides every other choice.

Then decide on supply. A fixed supply is set at deployment and cannot grow. A mintable supply lets an authorized account create new units, which needs strict control over who holds that power. A burnable token lets holders destroy units. Then decide on distribution: who receives tokens at the start, in which shares, and when. Large allocations to insiders with no waiting period tend to erode trust, so many projects add vesting, which releases tokens gradually over time.

Finally, think about who has special powers. Pausing transfers, blocking addresses or upgrading the code are all possible, and each one is a trust assumption. Write them down, tell your users, and prefer the smallest set of powers that the purpose requires. This ties back to week 1: a token is only as trustworthy as the rules and the people who can change them.

Purpose: what does holding the token do?
Supply: fixed, mintable or burnable, and who controls it.
Distribution: initial shares, vesting and public access.
Powers: pause, mint, upgrade, and who holds the keys.

Writing Tokens Safely

Do not write token logic from scratch for real use. OpenZeppelin Contracts is a widely used, audited library with ready implementations of ERC-20, ERC-721 and ERC-1155. You inherit from it and add only what is unique to your project. Your own code stays small, which means fewer places for bugs.

Since Solidity 0.8, arithmetic reverts on overflow by default, which removes a whole class of older bugs. Keep the Solidity version fixed in your pragma, write tests for transfers that should fail, and deploy first to a test network such as Sepolia, where the coins are free.

In the exercise you will deploy an ERC-20 with OpenZeppelin, send some units to a second address, and read the Transfer event on a block explorer. That one loop of write, deploy, interact and inspect is the same loop you will use in the capstone in week 12.

Key Terms

Token: A record kept by a smart contract that says how many units of something each address owns.
ERC-20: The standard interface for fungible tokens, with balanceOf, transfer, approve and transferFrom.
ERC-721: The standard interface for non-fungible tokens, where each token id has exactly one owner.
ERC-1155: A standard that manages many fungible and non-fungible token types inside a single contract.
Allowance: The amount a spender may move from your balance, set by calling approve.
Decimals: A display hint that tells apps where to place the decimal point in an integer balance.
Mint and burn: Minting creates new units and raises supply, burning destroys units and lowers it.
Vesting: A schedule that releases allocated tokens to their owners gradually over time.
Token URI: A link inside an NFT contract that points to the JSON metadata for one token id.

Exercise: Deploy Your Own ERC-20 On Sepolia

Open remix.ethereum.org and create a file named ClassToken.sol.
Paste the contract from the slides. It imports OpenZeppelin ERC20 and mints the initial supply to you.
Compile with Solidity 0.8.20 or newer, then pick Injected Provider and switch your wallet to the Sepolia test network.
Get free Sepolia test coins from a public faucet, then deploy the contract with an initial supply of 1000.
Call transfer to send 10 tokens to a second address you control, then call balanceOf on both addresses.
Open the transaction on a Sepolia block explorer and find the Transfer event in the logs. Write down who, to whom and how much.