Weekly Homework Assignments

This document defines the four weekly homework assignments for the FHEVM Bootcamp 4-week program.

​

Grading Scale

​

Week 1 Homework: Encrypted Calculator

Due: End of Week 1
Covers: Modules 00-04
Estimated Time: 3-4 hours

​

Specification

Build an EncryptedCalculator.sol contract that:

1. Stores two encrypted values (euint32 a and euint32 b) per user
2. Provides setA(uint32) and setB(uint32) functions to set values from plaintext
3. Implements these operations, each returning and storing the result:
   • add() → a + b
   • subtract() → a - b
   • multiply() → a * b
   • divide() → a / b (plaintext divisor)
   • compare() → returns ebool (a > b)
   • minimum() → min(a, b)
   • bitwiseAnd() → a AND b
4. Each result is stored in a euint32 lastResult with proper ACL
5. Emits OperationPerformed(address indexed user, string operation) event
6. Inherits ZamaEthereumConfig

​

Required Tests (minimum 10)

• Test each of the 7 operations with known values
• Test ACL: verify sender has access to results
• Test divide by 1 (identity)
• Test compare with equal values

​

Grading Rubric

​

Submission Checklist

​

Week 2 Homework: Encrypted Vault with Access Control

Due: End of Week 2
Covers: Modules 05-09
Estimated Time: 4-5 hours

​

Specification

Build a SecureVault.sol contract that:

1. Allows users to deposit encrypted amounts using externalEuint64 + inputProof
2. Allows users to withdraw encrypted amounts with no-revert pattern
3. Owner can set an encrypted daily withdrawal limit per user
4. Withdrawal checks BOTH: sufficient balance AND within limit
5. Owner can grant read access to a third party for any user’s balance
6. Includes a generateLuckyNumber() function using FHE.randEuint32()
7. Users can make their own balance publicly decryptable via FHE.makePubliclyDecryptable()
8. Emits events: Deposited, Withdrawn, LimitSet, AccessGranted

​

Required Tests (minimum 12)

• Deposit with encrypted input and verify balance
• Withdraw within balance (succeeds)
• Withdraw over balance (silently sends 0, no revert)
• Withdraw over limit (silently sends 0)
• Owner sets withdrawal limit
• Non-owner cannot set limit
• Grant access to third party
• Generate random number
• Make balance publicly decryptable
• Multi-user isolation
• Deposit + withdraw + verify remaining balance
• Double deposit accumulation

​

Grading Rubric

​

Submission Checklist

​

Week 3 Homework: Confidential Token + Voting System

Due: End of Week 3
Covers: Modules 10-14
Estimated Time: 5-6 hours

​

Specification

Build TWO contracts that work together:

​

Contract 1: ConfidentialToken.sol

A simplified confidential ERC-20 with:

1. Encrypted balances (mapping(address => euint64))
2. mint(address to, uint64 amount) — owner only
3. transfer(externalEuint64 encAmount, bytes calldata inputProof, address to) — with no-revert pattern
4. balanceOf(address) returns euint64 handle
5. No amount in Transfer event (only from, to)
6. Total supply tracked as public uint64

​

Contract 2: TokenVoting.sol

An encrypted voting system:

1. References the ConfidentialToken contract
2. createProposal(string description, uint256 durationSeconds) — owner only
3. vote(uint256 proposalId, externalEuint64 encVote, bytes calldata inputProof) — vote weight = 1
4. Encrypted yesVotes and noVotes tallies per proposal
5. finalizeProposal(proposalId) — after deadline, makes tallies publicly decryptable
6. Duplicate vote prevention per proposal per address

​

Required Tests (minimum 15)

• Token: mint, transfer success, transfer fail (silent), balance check
• Token: transfer to self, transfer zero
• Voting: create proposal, cast yes vote, cast no vote
• Voting: prevent double vote
• Voting: finalize after deadline
• Voting: reject finalize before deadline
• Voting: reject non-owner proposal creation
• Integration: mint tokens then vote
• Multi-user: 3 users vote, verify tally
• Edge case: vote on non-existent proposal

​

Grading Rubric

​

Submission Checklist

​

Week 4 Homework: Capstone — Confidential DAO

Due: End of Week 4
Covers: Modules 15-19
Estimated Time: 8-10 hours

​

Specification

Build a complete Confidential DAO system:

​

Contract 1: GovernanceToken.sol

• Encrypted ERC-20 governance token
• Minting, encrypted transfers with no-revert pattern
• delegate(address) — delegate voting power
• Gas-optimized: use plaintext operands where possible

​

Contract 2: DAO.sol

• createProposal(string description, uint256 amount, address recipient, uint256 duration)
• castVote(uint256 proposalId, externalEuint64 encSupport, bytes calldata inputProof) — encrypted yes/no vote
• Encrypted tallies (euint64 yesVotes, euint64 noVotes)
• finalizeProposal(proposalId) — after deadline, make tallies publicly decryptable
• executeProposal(proposalId) — if yes > no, transfer ETH from treasury
• receive() — accept ETH donations to treasury
• Duplicate vote prevention
• LastError pattern for vote feedback

​

Security Requirements (MANDATORY)

​

Required Tests (minimum 20)

• GovernanceToken: mint, transfer, delegate
• DAO: create proposal, cast yes, cast no
• DAO: prevent double vote
• DAO: finalize after deadline, reject before
• DAO: execute passing proposal (treasury transfer)
• DAO: reject execution of failing proposal
• DAO: accept treasury funding
• Security: non-owner cannot create proposals
• Security: non-owner cannot mint
• Integration: full lifecycle (mint -> fund treasury -> propose -> vote -> finalize -> execute)
• Multi-user: 3+ voters with different votes
• Edge cases: vote on non-existent proposal, execute before finalize, empty treasury

​

Grading Rubric

​

Submission Checklist

​

Submission Guidelines

​

Format

Each homework should be submitted as:

1. Solidity contract(s) in contracts/
2. Test file(s) in test/
3. All tests passing with npx hardhat test

​

Late Policy

• On time: full credit
• 1 day late: maximum 90%
• 2 days late: maximum 80%
• 3+ days late: maximum 70%

​

Academic Integrity

• You may reference the bootcamp’s example contracts and lesson materials
• You may use the Zama documentation
• All code must be your own work
• AI-assisted code is acceptable but must be reviewed and understood by the student