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.
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:
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.
- Checks sender has sufficient balance using
require() - Deducts amount from sender's balance
- Adds amount to recipient's balance
- Returns
trueon success - Emits
Transferevent
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
2-3 points: Approve sets allowance but missing event or return value.
0-1 points: Function missing or does not update allowance correctly.
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:
2-3 points: Partial implementation -- checks balance but not allowance, or does not decrease allowance.
0-1 points: Function missing or completely incorrect.
- 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
Transferevent
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
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.
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:
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.
- 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.
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
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.
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.
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:
1-2 points: Vague or surface-level explanation. Only one group member speaks.
0 points: No presentation or incomprehensible explanation.
- 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
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.
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.
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.