Assignment Overview: This hands-on activity places students in the role of security auditors, identifying vulnerabilities in smart contract code. It bridges theoretical cryptoeconomics concepts (mechanism design, game theory) with practical security analysis skills essential for blockchain development careers.

Learning Objectives & Course Alignment

Core Learning Goals:
  1. Technical Analysis: Identify common smart contract vulnerabilities (reentrancy, access control, integer overflow)
  2. Adversarial Thinking: Develop attack scenarios and understand attacker incentives
  3. Game Theory Application: Analyze rational decision-making in attack vs. report scenarios
  4. Mechanism Design: Understand how bug bounties align incentives for security
  5. Economic Valuation: Estimate vulnerability impact and appropriate compensation

Course Integration

This assignment works best after students have covered:

Pre-Class Preparation

⏰ Time Required

Activity Instructor Time Class Time
Pre-class preparation 30-45 minutes -
Introduction & setup - 10 minutes
Student work time - 35 minutes
Presentations (3 groups) - 15 minutes
Total Class Time - 60 minutes

Materials Checklist

Print for Each Group:
  • ✓ Instructions sheet (1 per group)
  • ✓ Contracts handout (1 per group)
  • ✓ Vulnerability reference guide (1 per group)
  • ✓ Attack worksheet (1 per group)
Instructor Materials:
  • ✓ Answer key (confidential)
  • ✓ Grading rubric
  • ✓ Timer for presentations
  • ✓ Whiteboard/projector for class discussion

Group Formation Recommendations

Minute-by-Minute Teaching Plan

Minutes 0-10: Introduction & Setup

Opening Hook (2 minutes):

"In 2016, The DAO hack exploited a reentrancy bug to steal $60 million. That vulnerability? Nearly identical to one of the contracts you'll analyze today. In 2021, Poly Network lost $600 million to an access control flaw. Today, you're going to find these same bugs before attackers do."

Activity Explanation (3 minutes):
  • Explain roles: "You're security auditors, not just students"
  • Emphasize real-world context: "These vulnerabilities have cost billions"
  • Clarify deliverables: worksheet + 5-minute presentation
  • Mention bonus challenges for advanced students
Materials Distribution (2 minutes):
  • Hand out packets to each group
  • Direct students to vulnerability reference guide first
Q&A (3 minutes):
  • Answer clarification questions
  • Set timer for 35 minutes work time

Minutes 10-45: Student Work Time

Instructor Role During Work Time:
  • Circulate actively: Visit each group at least once in first 15 minutes
  • Assess progress: Note which groups are struggling vs. excelling
  • Provide scaffolding, not answers: Use Socratic questions
  • Encourage peer teaching: Direct struggling groups to reference guide
  • Select presenters: By minute 30, identify which 3 groups will present (aim for diversity in contracts covered)
Common Student Struggles & Interventions:
Struggle Intervention
"We don't see any bugs" Ask: "What happens if I call withdraw() twice before balance updates?" or "Who can call setOwner()?"
Vague attack scenarios "Walk me through each line of code - what executes first, second, third?"
Confusion between vulnerabilities "Look at the detection signs in the reference guide for each type"
Unrealistic bounty calculations "Check Immunefi or HackerOne for real-world bounty ranges"

Minutes 45-60: Presentations & Discussion

Presentation Management:
  • Select 3 groups covering different contracts (ideally 1, 2, and 3)
  • Strict 5-minute timer: Give 30-second warning, hard stop at 5 minutes
  • Encourage questions: Save 30 seconds after each for peer questions
  • Take notes: Document exceptional insights for grading
Wrap-Up Discussion (5 minutes after presentations):
  • "What was the most surprising vulnerability?"
  • "Why do you think these bugs still appear despite known patterns?"
  • "Is a $1M bug bounty enough incentive not to exploit a $50M vulnerability?"
  • "How does this relate to mechanism design principles we've studied?"

Real-World Context & Examples

Connecting the assignment to real exploits makes the stakes tangible. Use these examples during introduction or wrap-up discussion.

📌 Contract 1 (Reentrancy): The DAO Hack (2016)

  • Loss: $60 million (3.6M ETH)
  • Vulnerability: Identical reentrancy pattern - external call before balance update
  • Consequence: Led to Ethereum hard fork, creating ETH and ETC chains
  • Key Insight: "Move fast and break things" doesn't work with immutable money
  • Link: ethereum.org/en/history/#dao-fork

📌 Contract 2 (Access Control): Poly Network (2021)

  • Loss: $600 million (largest DeFi hack in history)
  • Vulnerability: Keeper role could call privileged functions without proper validation
  • Twist: Hacker returned funds after realizing escape was impossible
  • Bounty Offered: $500,000 "bug bounty" after the fact
  • Key Insight: Access control is not optional - it's existential

📌 Contract 3 (Integer Overflow): BEC Token (2018)

  • Loss: Token value to zero (de-listed from exchanges)
  • Vulnerability: Batch transfer function had overflow bug allowing token creation
  • Exploit: Attacker created 57,896,044,618,658,100,000,000,000,000,000,000,000,000,000,000,000,000,000,000 tokens
  • Key Insight: Integer overflow can seem abstract until it creates quadrillions of tokens

📌 Bonus Contract 4 (Flash Loan): bZx Protocol (2020)

  • Loss: ~$1 million across multiple attacks
  • Vulnerability: Price oracle based on single Uniswap pool, manipulable with flash loans
  • Attack Complexity: Required coordinating actions across 5+ protocols in single transaction
  • Key Insight: Composability is DeFi's strength and weakness

📌 Bonus Contract 5 (Oracle Manipulation): Cream Finance (2021)

  • Loss: $130 million
  • Vulnerability: Price oracle manipulated through flash loans, allowing over-borrowing
  • Sophistication: Attacker used complex multi-step strategy across protocols
  • Key Insight: Oracles are critical infrastructure, not afterthoughts

Discussion Facilitation Tips

Socratic Questions for Deeper Understanding

For Reentrancy:
  • "Why doesn't the require() check prevent the attack?"
  • "What if we used transfer() instead of call()? Would that fix it?" (Answer: Helps but not foolproof)
  • "How would you test for this vulnerability without exploiting it?"
For Access Control:
  • "Who should be able to call setOwner()? How do we enforce that?"
  • "What's the difference between authentication and authorization here?"
  • "Why might developers forget to add access controls?" (Answer: Testing often uses owner account)
For Integer Overflow:
  • "Why does 0 - 1 become a huge number instead of -1?"
  • "Is this still a problem in newer Solidity versions?" (Answer: No, 0.8.0+ has built-in checks)
  • "How would you detect this in production before it's exploited?"
For Game Theory:
  • "If exploit profit is $50M but bounty is only $500K, why don't more people exploit?"
  • "What's the expected value of exploitation when factoring in capture probability?"
  • "How do bug bounties change the payoff matrix?"

Common Misconceptions to Address

Misconception Reality
"Audits make contracts 100% safe" Even audited contracts get hacked. Audits reduce but don't eliminate risk. Bug bounties provide ongoing security.
"Using transfer() prevents reentrancy" Transfer() limits gas (2300), making many attacks harder but not impossible. Best practice is checks-effects-interactions.
"Only affects old Solidity versions" While 0.8.0+ fixed overflow, reentrancy and access control still require developer vigilance.
"Hackers are always external" Many exploits are insider jobs or by sophisticated attackers posing as community members.
"Bug bounties encourage hacking" Data shows bug bounties reduce successful attacks by ~70% by channeling security research.

Assessment & Grading Tips

Quick Grading Strategy

During Presentations (take notes on):

  • Technical accuracy (can grade content immediately)
  • Clarity of explanation
  • Individual contribution (for differentiated scoring)
  • Questions asked by group members during others' presentations

Worksheet Grading (post-class):

  • Batch grading: Grade all groups' Contract 1 first, then all Contract 2, etc. (maintains consistency)
  • Use answer key rubric: Don't require exact wording - focus on conceptual accuracy
  • Partial credit is your friend: Students showing understanding deserve credit even with minor errors
  • Time estimate: 10-15 minutes per group = ~2 hours for 8 groups

Recognizing Excellence

Look for and reward:
  • Creative attack scenarios: Students who think beyond obvious exploits
  • Multiple fix proposals: Showing understanding of different mitigation strategies
  • Economic sophistication: Nuanced game theory analysis (e.g., considering reputation value)
  • Real-world connections: Citing actual hacks or security best practices
  • Attempting bonus contracts: Reward effort even if answers aren't perfect

Adaptations for Different Class Sizes

Class Size Modifications
Small (12-15) • Groups of 2-3 students (4-5 groups total)
• All groups present (3 minutes each)
• More time for discussion (10-15 minutes)
Medium (20-30) • Groups of 3 students (7-10 groups)
• Select 3 groups to present
• Standard 60-minute format
Large (40+) • Consider 90-minute session
• Groups of 4 students
• Select 4-5 groups to present
• Alternatively: Assign different contracts to different groups

Extension Activities

For Advanced Students

  • Code the Attack: Have students write actual Solidity attacker contracts
  • Formal Verification: Introduce tools like Certora or Mythril for automated vulnerability detection
  • Bug Bounty Simulation: Create mock bounty program where students compete to find bugs
  • Audit Report: Write professional security audit report instead of worksheet

For Struggling Students

  • Pre-class prep: Assign vulnerability reference guide as homework before class
  • Scaffolded analysis: Provide additional hints or partial answers in worksheet
  • Peer teaching: Pair with stronger groups for first 10 minutes
  • Focus on one contract: Allow deep analysis of single contract instead of all three

Follow-Up Opportunities

Next Class Session:
  • Debrief with real-world hack videos/case studies
  • Invite guest speaker from Web3 security firm (Trail of Bits, OpenZeppelin, ConsenSys Diligence)
  • Demonstrate actual vulnerability exploitation on test network
  • Discuss formal methods and verification tools
Longer-Term Projects:
  • Students audit real open-source DeFi protocol
  • Create bug bounty program for course project contracts
  • Research paper on economics of security incentives
  • Participate in real bug bounty programs (Immunefi, Code4rena, Sherlock)

Resources for Instructors

Professional Development

Stay Current on Vulnerabilities:
  • Rekt News: rekt.news - Weekly DeFi hack reports with technical analysis
  • Immunefi Blog: medium.com/immunefi - Bug bounty case studies
  • Trail of Bits Blog: blog.trailofbits.com - Security research and tools
  • OpenZeppelin Forum: forum.openzeppelin.com - Security best practices
Teaching Materials:
  • Ethernaut: ethernaut.openzeppelin.com - Interactive vulnerability challenges
  • Damn Vulnerable DeFi: damnvulnerabledefi.xyz - CTF-style challenges
  • SWC Registry: swcregistry.io - Comprehensive vulnerability classification
  • Secureum Bootcamp: secureum.substack.com - Free security training resources
Audit Reports to Study:
  • Trail of Bits audits: github.com/trailofbits/publications
  • OpenZeppelin audits: blog.openzeppelin.com/security-audits/
  • ConsenSys Diligence: consensys.net/diligence/audits/

Troubleshooting Common Issues

Problem Solution
Students finish too quickly Direct them to bonus contracts immediately; encourage deeper analysis of attack variations
Students can't finish in time Allow completion of 2 contracts minimum; let them focus on depth over breadth
Presentations run over time Use strict timer; prepare to cut Q&A or reduce discussion time
Technical skill disparities Pre-assign groups mixing skill levels; emphasize conceptual understanding over code syntax
All groups struggle with same contract Pause for mini-lecture addressing common confusion point; provide targeted hint
Students request to code solutions Great! But time-box to 5 minutes or make it homework extension

Learning Outcome Assessment

How to Measure Success

Students successfully met objectives if they can:
  • ✓ Name and describe 3+ vulnerability types from memory
  • ✓ Explain why external calls before state updates enable reentrancy
  • ✓ Design a basic attack scenario given vulnerable code
  • ✓ Articulate why bug bounties reduce exploitation (incentive alignment)
  • ✓ Estimate vulnerability severity and economic impact
Evidence of Deep Learning:
  • Students reference assignment concepts in later course discussions
  • Students apply security thinking to course project contracts
  • Students pursue security careers or contribute to bug bounties
  • Students can explain vulnerabilities to non-technical peers

Feedback & Continuous Improvement

After teaching this assignment, reflect on:
  • Which contracts were too easy/hard?
  • What questions did multiple groups ask? (Add to next year's instructions)
  • Did any groups find alternative vulnerabilities not in answer key? (Document them!)
  • Were real-world examples effective? Which resonated most?
  • Did bonus contracts add value or just stress?

Student Feedback Questions:

  • "What was most challenging about this assignment?"
  • "Did the vulnerability reference guide help? What would improve it?"
  • "Would you be interested in security careers after this?"
  • "How could we make this more realistic/engaging?"
⚠️ Important Reminder: Some students may find vulnerabilities not in the answer key. This is EXCELLENT and should be celebrated! Document novel findings and consider updating materials. Security is about creative thinking, not just pattern matching.

© Joerg Osterrieder 2025-2026. All rights reserved.