Seven objectives, from the broadest to the most practical. Each one says what you will be able to do, where in the module you will practise it, and where it will be observed. Everything assessed in this module derives from this list.
1. Explain what a blockchain is, what it guarantees, and when not to use one
You can describe a blockchain as a developer sees it: a replicated state machine that advances only by transactions someone authorised, in an order everyone agrees on, that anyone can read and that nobody can rewrite once it is final. You can name what that buys: neutrality, censorship resistance, public verifiability, guaranteed execution, and what it costs: latency, expense, publicity, immutability of mistakes. Given a proposed application, you can say whether a chain adds anything, and defend the answer either way.
Practised on Day 1 and throughout. Observed in the choice and justification of the project’s decentralised feature, and in the defence.
2. Navigate the Ethereum ecosystem and its vocabulary
You know the layers: Ethereum, rollups, Base, and why they exist. You know the standards: ERC-20, ERC-721, ERC-1155, and what “approve” means. You know what an AMM does, what lending protocols do, what a stablecoin is and the different ways one can fail. You know what oracles, indexers, IPFS, MEV, account abstraction, and audits are, and where each fits. You can read a verified contract on a block explorer and follow a transaction through it. You can hold a technical conversation on any of this without bluffing.
Practised on Days 1, 3, and 4. Observed in the defence’s questions, and in how the project positions itself against existing protocols.
3. Write, test, and deploy smart contracts with a professional toolchain
You can write Solidity: types, storage, mappings, structs, events, modifiers, custom errors, value transfer, inheritance, interfaces. You can set up a Hardhat project, write tests that actually exercise the contract’s behaviour including its failure paths, deploy to a local node and to a public testnet with a reproducible script, and verify the source on a block explorer.
Practised on Days 1 and 2, and in the project. Observed in the project’s contracts, tests, and deployment, and in the code walkthrough at the defence.
4. Build a frontend that interacts with contracts through a wallet
You understand the path from a browser to a chain: wallet, provider, RPC node. You can connect a wallet, read contract state, send a transaction, wait for it, react to its events, and handle the ways it fails: rejection, revert, wrong network. You can do this with viem and wagmi, and explain what each layer is doing.
Practised on Day 2 and in the project. Observed in the live demonstration at the defence.
5. Reason about security and trust in an adversarial, immutable setting
You know the common classes of smart contract vulnerability: access control, reentrancy, oracle manipulation, front-running, signature replay, denial of service, unsafe upgradeability, and the defensive patterns that address them. You can write down, for a contract, who can do what, and what happens if each of those parties is malicious. You understand why immutability changes how software is written, and what an audit is for.
Practised on Day 3 and in the project. Observed in the project’s threat model and code, and in the security questions at the defence.
6. Design a decentralised application that actually needs the chain
You can split an application between on-chain and off-chain parts and say why each piece is where it is. You can design a contract that holds the minimum state and trusts the minimum set of parties, use events as the read interface, and explain the trade-offs you made, including the ones that argue against your own design.
Practised in the project. Observed in the architecture, the README, and the defence.
7. Deliver and defend software as a team
You can plan and split work across three people over six weeks, keep a repository in a state where a stranger can run it, present a live system under time pressure, and answer for any part of it individually.
Practised in the project. Observed across both defences.