Skip to content

17. Challenge 1: Staking

Challenge 1 is optional extension practice after you’ve shipped Challenge 0. It builds a staking app: users deposit ETH toward a shared goal by a deadline, and the contract either executes or lets everyone withdraw depending on whether the threshold was met. It introduces application patterns — deposits, deadlines, conditional execution — that recur throughout DeFi.

  • Staking as a pattern — users lock funds into a contract under rules, and the contract releases or acts on them based on conditions. This “escrow with rules” shape underlies far more complex protocols.
  • Time and deadlines — the contract reads block timestamps to know whether a deadline has passed. Time-based logic is a new tool compared to Challenge 0.
  • Threshold / conditional execution — if total stake reaches a threshold by the deadline, one path runs; otherwise users can reclaim their funds. Modeling both outcomes correctly is the crux.
  • Handling ETH safely — the contract receives and returns ETH, which forces care around payable functions and withdrawal patterns (a first taste of the security concerns in Module 4).
  • Second exposure to the SpeedRun flow — repeating fork → build → deploy → submit on a new problem cements the workflow from Challenge 0.
  • Getting the deadline comparison backwards (before vs. after), which breaks the whole state machine.
  • Mishandling the failure path so users can’t reclaim funds — the kind of bug that, on mainnet, permanently locks money.
  • Treating optional as “skip it entirely.” Even if you don’t submit it, the staking pattern directly informs the Module 5 capstone.
  • What two outcomes must the contract handle at the deadline, and what happens to user funds in each?
  • How does the contract know whether the deadline has passed?
  • Why does receiving and returning ETH raise security concerns that Challenge 0 didn’t?

Module 3 extension.