Project · Advanced · about 24 hours

A staking rewards contract with fair accounting

Build a contract that pays rewards to stakers pro rata over time, using the reward-per-token accumulator pattern, and prove the accounting with invariant tests.

Skills:DeFi, Smart contracts and Solidity, Automated testing

Part of: Blockchain Developer

Data and licences

Brief

Staking and liquidity-mining contracts must share rewards fairly among people who join and leave at different times, without looping over every staker. The accumulator pattern solves this, and it is a favourite interview topic. Use a local Anvil chain and, when you deploy publicly, a testnet such as Sepolia with free test ether from a faucet. Never use real funds or a wallet that holds any, and never paste a private key into code or a website.

What to build

  1. Implement stake, withdraw and claim for an ERC-20 staking token and an ERC-20 reward token

  2. Track reward per token stored and each user reward-per-token paid, updated on every action

  3. Let the owner fund a reward period with a fixed duration and rate, and handle top-ups mid-period

  4. Write a Python model that computes exact rewards for random sequences of actions, and differential fuzz tests against it

  5. Write invariant tests: rewards paid never exceed rewards funded, and total staked equals the sum of balances

Deliverables

  • Repository with src/, test/, model/ and DESIGN.md

How it is graded

Reviewers run long fuzz campaigns and check that no user can claim more than their share and that dust does not accumulate unfairly.

Stretch

Add a boost for long lock-ups and show how it changes the accounting.

Deliverables

  • A staking contract with stake, withdraw and claim, funded reward periods and a reward rate
  • The reward-per-token accumulator pattern so every action is constant gas regardless of the number of stakers
  • Invariant tests that total rewards paid never exceed rewards funded, and a Python model for comparison
  • A design note on rounding, precision and edge cases

How a reviewer grades it

CriterionWeightWhat good looks like
Accounting is correct and fair across stakers and time35%
Gas does not grow with the number of stakers15%
Invariant and model-based tests pass with many fuzz runs30%
Design note explains precision and edge cases20%