Assessment Overview: This rubric evaluates students' ability to implement a working ERC-20 token contract, extend it with custom functionality, and communicate their design decisions. The assignment assesses both practical Solidity coding skills and conceptual understanding of token mechanics.

Point Distribution Summary

Component Points Percentage
Part 1: Working Base Contract (25 points)
Contract Compiles & Deploys 5 10%
transfer() Works Correctly 6 12%
approve() Works Correctly 4 8%
transferFrom() Works Correctly 6 12%
Events Emitted Correctly 4 8%
Part 2: Custom Feature (15 points)
Feature Implementation 10 20%
Access Control (if applicable) 3 6%
Feature Testing / Demo 2 4%
Part 3: Presentation (10 points)
Technical Explanation 5 10%
Live Demo / Screenshot 3 6%
Reflection & Design Rationale 2 4%
TOTAL 50 100%
Bonus: Multiple Custom Features (Optional) +10 -

Detailed Rubric

Part 1: Working Base Contract (25 points)

1A. Contract Compiles & Deploys (5 points)
5 points: Contract compiles without errors in Remix and deploys successfully. Constructor sets name, symbol, decimals, and totalSupply correctly. Initial balance assigned to deployer.

3 points: Contract compiles with warnings but deploys. Minor issues with constructor parameters (e.g., hardcoded values instead of parameters).

1 point: Contract compiles but does not deploy, or deploys with incorrect initial state.

0 points: Contract does not compile.
1B. transfer() Works Correctly (6 points)
6 points: Function correctly:
  • Checks sender has sufficient balance using require()
  • Deducts amount from sender's balance
  • Adds amount to recipient's balance
  • Returns true on success
  • Emits Transfer event
4-5 points: Transfer works but missing one element (e.g., no return value, or missing event emission).

2-3 points: Transfer partially works but has logic errors (e.g., no balance check, or balance not updated correctly).

0-1 points: Function missing or completely incorrect.
1C. approve() Works Correctly (4 points)
4 points: Function correctly sets the allowance mapping for the spender and emits an Approval event. Returns true.

2-3 points: Approve sets allowance but missing event or return value.

0-1 points: Function missing or does not update allowance correctly.
1D. transferFrom() Works Correctly (6 points)
6 points: Function correctly:
  • Checks sender has sufficient balance
  • Checks caller has sufficient allowance
  • Deducts from sender's balance, adds to recipient
  • Decreases the allowance by the transferred amount
  • Emits Transfer event
4-5 points: TransferFrom works but missing one check or the allowance is not decreased after transfer.

2-3 points: Partial implementation -- checks balance but not allowance, or does not decrease allowance.

0-1 points: Function missing or completely incorrect.
1E. Events Emitted Correctly (4 points)
4 points: Both Transfer and Approval events are properly declared and emitted in the correct functions with correct parameters.

2-3 points: Events declared but not emitted in all required locations, or parameters are incorrect.

0-1 points: Events not declared or never emitted.

Part 2: Custom Feature (15 points)

2A. Feature Implementation (10 points)
9-10 points: Chosen feature is fully implemented and works correctly:
  • Burn: Reduces both sender's balance and totalSupply. Uses require() for balance check. Emits event.
  • Mint: Increases recipient's balance and totalSupply. Restricted to owner only. Emits event.
  • Pause: Boolean flag checked in transfer/transferFrom. Only owner can toggle. Emits event.
6-8 points: Feature mostly works but has minor issues (e.g., burn doesn't reduce totalSupply, or mint has no access control).

3-5 points: Feature partially implemented. Function exists but has logic errors or does not compile.

1-2 points: Feature attempted but non-functional.

0 points: No custom feature attempted.
2B. Access Control (3 points)
3 points: Where appropriate, feature uses onlyOwner modifier or require(msg.sender == owner) to restrict access. Owner is set in constructor.

1-2 points: Access control attempted but incomplete (e.g., owner variable declared but not checked in function).

0 points: No access control where it is needed (e.g., anyone can mint tokens).

Note: For burn (which any holder can call on their own tokens), full credit is given if no access control is used, since none is required.
2C. Feature Testing / Demo (2 points)
2 points: Student demonstrates the feature working in Remix -- shows before and after state (e.g., totalSupply before and after burn).

1 point: Feature is shown but not fully demonstrated (e.g., claims it works but does not show state changes).

0 points: No demonstration of custom feature.

Part 3: Presentation (10 points)

3A. Technical Explanation (5 points)
5 points: Clearly explains:
  • What the token does (name, symbol, supply)
  • How the custom feature works at a code level
  • Why the feature is useful in real-world tokens
  • All group members contribute to the explanation
3-4 points: Explanation is mostly clear but lacks code-level detail or real-world connection.

1-2 points: Vague or surface-level explanation. Only one group member speaks.

0 points: No presentation or incomprehensible explanation.
3B. Live Demo / Screenshot (3 points)
3 points: Shows a live Remix interaction or screenshots proving the contract works. Demonstrates at least one transaction (transfer or custom feature).

1-2 points: Shows Remix but does not execute a transaction, or only shows the code without deployment.

0 points: No visual demonstration.
3C. Reflection & Design Rationale (2 points)
2 points: Articulates why they chose their feature, what they learned, and what was challenging. Shows genuine reflection.

1 point: Brief or generic reflection ("it was interesting").

0 points: No reflection provided.

Bonus: Multiple Custom Features (Optional +10 points)

Bonus Evaluation

Students implementing two or more custom features earn bonus points. Each additional working feature is worth +5 points, up to +10 maximum.

Per Additional Feature (+5 points each, max +10):
  • Feature compiles and deploys: +1
  • Feature logic is correct: +2
  • Feature has appropriate access control: +1
  • Feature is demonstrated working: +1

Note: Partial credit available for partially correct bonus features. Students who attempt all three features with minor bugs should receive more credit than students who attempt none.

Grading Scale

Grade Points Percentage Description
A 45-50 90-100% Fully working ERC-20 with polished custom feature, excellent presentation
B 40-44 80-89% Working ERC-20 with working custom feature, good presentation
C 35-39 70-79% Mostly working ERC-20, custom feature has minor issues
D 30-34 60-69% Contract compiles but has significant bugs, weak presentation
F 0-29 <60% Contract does not compile or deploy, no custom feature, no presentation

Additional Grading Guidelines

Academic Integrity

  • Collaboration: Encouraged within groups. Each group submits one contract
  • Resources: Students may use Lesson 10 slides, Remix documentation, and Solidity docs
  • Plagiarism: Copying from other groups or pasting a complete contract from the internet results in 0 points
  • AI Tools: May be used for learning but students must understand every line of their code

Late Submission Policy

  • Contract: Must be deployed and demonstrable during the class period
  • Presentation: Must be delivered during class. Missed presentations cannot be made up without prior approval
  • Reflection: Can be submitted by end of day if not included in presentation

Special Considerations

  • Individual Grading: If one group member clearly did not contribute, the instructor may assign a lower individual grade for the presentation component
  • Technical Difficulties: If Remix is unavailable, students may show code on screen and explain expected behavior for partial credit
  • Partial Credit: A contract that compiles but has a bug in one function should receive credit for the working functions
Instructor Notes:
  • The most common mistake is forgetting to decrease the allowance in transferFrom()
  • Students who choose "pause" demonstrate higher ambition -- grade the attempt generously even if imperfect
  • Reward creative token names and symbols -- it shows engagement
  • Use the presentation to gauge individual understanding beyond the group submission

© Joerg Osterrieder 2025-2026. All rights reserved.