Assignment Overview: This hands-on activity has students build, deploy, and extend an ERC-20 token using Remix IDE. It bridges the theoretical token concepts from Lesson 7 and the Solidity syntax from Lesson 10 into a practical, creative exercise. Students work in small groups, which reduces anxiety about coding while encouraging peer teaching.

Learning Objectives & Course Alignment

Core Learning Goals:
  1. Solidity Fluency: Translate understanding of ERC-20 specification into working code
  2. Development Workflow: Gain comfort with compile-deploy-test cycle in Remix IDE
  3. Design Thinking: Choose and implement a feature extension based on real-world token patterns
  4. Access Control: Understand why certain functions need owner restrictions
  5. Communication: Present technical work to peers in a clear, concise format

Course Integration

This assignment works best immediately after Lesson 10 (Solidity Basics). Students should have covered:

Pre-Class Preparation

Time Required

Activity Instructor Time Class Time
Pre-class preparation 20-30 minutes -
Introduction & setup - 5 minutes
Build base token - 25 minutes
Deploy & test - 10 minutes
Add custom feature - 15 minutes
Presentations - 5 minutes
Total Class Time - 60 minutes

Pre-Class Checklist

Before Class:
  • Verify remix.ethereum.org is accessible on the classroom network (not blocked by firewall)
  • Test the starter code compiles and deploys in Remix -- do a full run-through yourself
  • Prepare the reference solution (see Answer Key) deployed in your own Remix instance for live demos
  • Ensure classroom has stable internet (Remix is a web app)
  • Have the Starter Code page URL ready to share
Backup Plan (if internet fails):
  • Download the Remix desktop app in advance: remix-desktop
  • Alternatively, have the starter code available as a downloadable .sol file
  • In the worst case, students can write code in any text editor and discuss logic without compiling

Group Formation Recommendations

Minute-by-Minute Teaching Plan

Minutes 0-5: Introduction & Setup

Opening Hook (1 minute):

"Every token you have heard of -- USDT, LINK, UNI, AAVE -- is an ERC-20 contract. Today you are going to build one yourself. By the end of this hour, you will have deployed your own cryptocurrency. Not on the real Ethereum network, but the process is identical."

Setup (2 minutes):
  • Direct students to open remix.ethereum.org
  • Show how to create a new file: File Explorer -> click the new file icon -> name it MyToken.sol
  • Share the Starter Code URL -- students copy-paste the template
Quick Orientation (2 minutes):
  • Point out the TODO comments in the starter code -- "these are your tasks"
  • Remind them: compile with Ctrl+S (or the Compile tab) after each function
  • Mention the deliverables: working contract + custom feature + 2-minute presentation

Minutes 5-30: Build the Base Token

Instructor Role During Build Phase:
  • Circulate actively: Visit each group at least twice in the first 15 minutes
  • Check compiler output: If a group has red error markers, help them read the error message
  • Do not write code for them: Point them to the relevant Lesson 10 slide instead
  • Pace check at minute 15: Most groups should have constructor + transfer done. If not, help them catch up
  • Pace check at minute 25: Most groups should have all 4 functions done. Stragglers can skip approve/transferFrom and focus on deploy + custom feature
Common Struggles & Interventions:
Struggle Intervention
"It won't compile" Check: missing semicolons, wrong bracket count, incorrect function signature. Read the Remix error -- it points to the exact line
"What is msg.sender?" "msg.sender is the address that called this function. In Remix, it is the address selected in the Deploy panel dropdown"
"What is the difference between transfer and transferFrom?" "transfer = I send my own tokens. transferFrom = I send someone else's tokens because they approved me. Think of a bank: transfer = you go withdraw cash. transferFrom = you gave your friend your debit card and PIN"
"The allowance mapping is confusing" "allowance[Alice][Bob] = 50 means Alice has allowed Bob to spend up to 50 of Alice's tokens. It is a nested dictionary: first key is the token owner, second key is the spender"
"My transfer says Insufficient balance but I deployed with 1000" "Are you calling transfer from the same account that deployed? Check the account dropdown in the Deploy panel"

Minutes 30-40: Deploy & Test

Quick Demo (2 minutes -- do this on the projector):
  1. Show the Deploy & Run tab
  2. Enter constructor arguments (name, symbol, supply)
  3. Click Deploy
  4. Show the deployed contract in the bottom panel
  5. Call balanceOf -- "see, you own all the tokens"
  6. Call transfer to another account -- "now check both balances"

After the demo, let students deploy and test their own contracts. Remind them to test both transfer and transferFrom.

Minutes 40-55: Add Custom Feature

Feature Guidance:
  • Burn (easiest): Most students should attempt this. It is the most straightforward -- just subtract from balance and totalSupply. Direct struggling groups here
  • Mint (medium): Good for students who grasped the modifier concept in Lesson 10. Emphasize the importance of onlyOwner
  • Pause (hardest): For advanced groups who finish early. Requires understanding modifiers that apply to multiple functions. If they attempt this, celebrate the effort even if imperfect
If Groups Finish Early:
  • Challenge them to implement a second feature (bonus points)
  • Ask them to write a 3-line summary of what each function does (good for the presentation)
  • Have them test edge cases: transfer to address(0), approve then change approval amount, burn more than balance

Minutes 55-60: Presentations

Presentation Management:
  • Select 2-3 groups that implemented different features (ideally one burn, one mint, one pause)
  • Strict 2-minute limit per group
  • Encourage live Remix demo rather than just talking about code
  • Ask one follow-up question per group: "What would happen if you removed the onlyOwner check?"
If Time is Short:
  • Have 1-2 groups demo instead of formal presentations
  • Ask the class: "Who implemented burn? Mint? Pause?" -- brief show of hands
  • Pick one interesting group for a 1-minute demo

Scaffolding for Struggling Groups

If a Group Cannot Complete the Base Token

Provide these progressive hints (do not give the full answer):

  1. Hint 1 -- transfer: "You need three lines: a require, a subtraction, and an addition. Then emit the event."
  2. Hint 2 -- approve: "One line sets the allowance, one line emits the event. That's it."
  3. Hint 3 -- transferFrom: "It is like transfer, but you check two things (balance AND allowance), and you decrease the allowance after."

If a group is completely stuck after 20 minutes, show them the transfer function from the Lesson 10 slides and let them adapt it. The goal is learning, not suffering.

Common Misconceptions to Address

Misconception Reality
"We deployed on the real Ethereum" Remix VM is a local simulation. No real ETH is used. Real deployment would cost gas fees ($5-$50 depending on network conditions).
"Our token has value now" A token has value only when people agree it does. Listing on exchanges, building utility, and gaining users create value. Code alone does not.
"decimals = 18 means I have 18 tokens" Decimals sets the precision for display. 1 token with 18 decimals is stored as 1000000000000000000 (10^18) internally. Wallets divide by 10^18 for display.
"Anyone can mint tokens because the function is public" The function visibility (public) just means it can be called. The onlyOwner modifier INSIDE the function restricts WHO can call it successfully.
"Burning tokens deletes them from the blockchain" Nothing is deleted from the blockchain. Burning reduces the balance and totalSupply variables, but the transaction recording the burn exists forever.

Assessment & Grading Tips

Quick Grading Strategy

During Class (take notes):

  • Note which groups deployed successfully (5 pts quick check)
  • Note which feature each group chose
  • Observe presentation quality and individual contributions

Post-Class Grading (if collecting code):

  • Ask groups to copy their final contract code to a shared document or LMS before leaving
  • Paste into Remix, compile, deploy, and run the test checklist from the Answer Key
  • Time estimate: 5-8 minutes per group

Alternative (faster):

  • Grade during class by walking around and testing live
  • Use a simple checklist: compiles? deploys? transfer works? feature works?
  • This saves grading time at the cost of less thorough evaluation

Adaptations for Different Class Sizes

Class Size Modifications
Small (10-15) Groups of 2. All groups present (1.5 min each). More time for individual help. Consider extending to 75 minutes if schedule allows.
Medium (20-30) Standard format. Groups of 2-3. Select 3 groups to present.
Large (40+) Groups of 3. Select 2-3 groups to present. Consider having a TA circulate to help with Remix issues. Projector-share the starter code URL prominently.

Extension Activities

For Advanced Students

  • Token Swap: Have two groups deploy tokens and try to manually swap them using approve + transferFrom
  • Capped Supply: Add a maximum supply limit to the mint function
  • Transfer Fee: Implement a 1% fee on transfers that goes to the contract owner
  • Testnet Deployment: Deploy to Sepolia testnet using MetaMask (requires testnet ETH from a faucet)

For Struggling Students

  • Focus on just the constructor and transfer function (minimum viable token)
  • Skip approve/transferFrom -- these can be assigned as homework
  • For the custom feature, burn is the simplest option (no access control needed)
  • Allow groups to present their code explanation instead of a live demo if deployment fails

Follow-Up Opportunities

Next Class Session (Lesson 11):
  • Reference students' tokens when introducing the DEX assignment (A13): "Remember the token you built last time? Now we are going to trade it"
  • Use a student's deployed token as a live example when explaining approve/transferFrom in a DEX context
Homework:
  • Students who did not finish can complete the contract at home (Remix works anywhere with internet)
  • Write a 1-page reflection: compare your token to a real ERC-20 (e.g., USDT) -- what features does the real token have that yours does not?

Troubleshooting Common Issues

Problem Solution
Remix is slow or unresponsive Clear browser cache, try a different browser, or use Remix desktop app as backup
Compiler version mismatch Ensure students select Solidity 0.8.20 or higher in the Compiler tab. The pragma in the starter code specifies ^0.8.20
Deploy button greyed out The contract has compilation errors. Students must fix all errors (red markers) before deploying
Transaction reverted Check the error message in the Remix console. Most common: insufficient balance, wrong account selected, or missing onlyOwner check
Students accidentally close Remix tab Remix auto-saves to browser local storage. Reopening Remix should restore the file. If not, they re-paste from the starter code
"My contract disappeared after deploy" Scroll down in the Deploy panel -- deployed contracts are listed at the bottom. Or re-deploy if needed

Real-World Token Examples for Discussion

Use these examples to connect the assignment to the real world:

  • USDT (Tether): Uses mint + burn + pause. The company mints USDT when users deposit USD. Burn on redemption. Pause for emergencies (has been used to freeze stolen funds)
  • UNI (Uniswap): Fixed supply, no mint. Pure governance token. Shows that not all tokens need a mint function
  • WETH (Wrapped Ether): Mint when ETH is deposited, burn when ETH is withdrawn. 1:1 backing
  • BNB (Binance Coin): Quarterly burn events to reduce supply over time. Burns are announced publicly as a deflationary mechanism
Important Reminder: Emphasize to students that deploying tokens on mainnet without proper legal review can have regulatory implications. This is an educational exercise on a simulated environment. Creating tokens that appear to be securities could violate financial regulations.

© Joerg Osterrieder 2025-2026. All rights reserved.