Project · Intermediate · about 18 hours
An escrow contract with disputes and deadlines
Build a two-party escrow with an arbiter, deadlines and refunds, model its states explicitly, and prove its safety properties with invariant tests.
Skills:DeFi, Smart contracts and Solidity, Automated testing
Part of: Blockchain Developer
Data and licences
Brief
Escrow is a classic contract: a buyer pays, a seller delivers, an arbiter settles disputes. The hard part is making sure every possible sequence of actions ends somewhere safe. 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
Design the state machine on paper first, with who may trigger each transition and when
Implement it with custom errors, events and pull-based withdrawals
Add deadlines: automatic refund if the seller does not deliver, and a default resolution if the arbiter does not act
Write unit tests for each transition and fuzz tests for random sequences of actions
Write invariant tests: the contract balance equals what is owed, and after the deadline some party can always withdraw
Deliverables
Repository with
src/,test/,docs/state-diagram.mdandREADME.md
How it is graded
Reviewers call transitions out of order, as the wrong party and after deadlines, and read your invariants.
Stretch
Support ERC-20 payments as well as ether, including tokens that take a fee on transfer.
Deliverables
- [object Object]
- Deadline handling so funds can never be locked forever
- Unit, fuzz and invariant tests, including an invariant that funds are always recoverable by someone
- A state diagram and a list of design risks in the README
How a reviewer grades it
| Criterion | Weight | What good looks like |
|---|---|---|
| State machine is explicit and every transition is guarded | 30% | |
| No path locks funds forever; deadlines and roles are enforced | 25% | |
| Invariant tests capture the key safety properties | 30% | |
| Documentation with state diagram and risks | 15% |