Track 8 · Capstones · lesson 7
Staking vault
180 min
Last one. No spec, no tests, no signatures. One paragraph.
Scaffolding tier: brief. This is the proof that the course worked. You have everything you need — you have had it for a while. Go.
The brief
Build a staking vault. Users deposit an ERC-20 token and earn a second reward token over time, proportional to how much they staked and for how long. They can claim rewards and withdraw their stake whenever they like. Deploy it to Sepolia, verified, with a UI that shows a user's stake, their pending rewards updating live, and buttons to stake, claim and withdraw.
That is the whole assignment.
Nothing more — but a few honest warnings
You are on your own for the design, and that is the point. Two things the course has taught you that this problem quietly demands:
- The reward maths is the hard part. The naive approach — loop over all stakers to pay everyone — is the denial-of-service trap from track 7. The real pattern is reward-per-token-stored, an accumulator that lets each user compute their share without a loop. Look it up; understand it; that lookup is a skill too.
- A vault takes deposits and sends withdrawals, so checks-effects-interactions and reentrancy are not optional. The reentrancy you drained in track 7 lives in exactly this shape of contract.
When it works
You will have taken an idea to a deployed, defended, usable product with no hand-holding. That is what a Web3 developer does. Everything after this is more of the same, larger — and track 9 is about where to point it.
Check
Why is looping over all stakers to distribute rewards the wrong design?
Worth remembering
- Capstone 7, brief scaffolding: one paragraph, nothing else — the proof the course worked.
- A staking vault: deposit, earn a reward token over time, claim, withdraw, with a live UI.
- Use a reward-per-token accumulator, not a loop over stakers (the track 7 DoS).
- A vault sends value, so checks-effects-interactions and reentrancy defence are mandatory.