Final defence

One hour, in front of a jury that has read your repository, with your application running live on Base Sepolia. Every member of the group speaks. Every member of the group is questioned. What is defended is the commit tagged freeze on Friday 27 November; work after that date is not part of the defence, whichever Saturday your group is scheduled on.

Before the defence

The jury reads your repository in the days before — the README, the roles and trust table, the decentralisation justification, the contracts, the tests, the deployment script, and DEMO.md. It arrives knowing what you built and with questions ready. The hour is not spent discovering your project; it is spent verifying it and probing it.

This means the README does real work. A jury that cannot run your tests from the README will ask you why, and the answer costs you time you needed for something else.

Format

The clock is firm. A demo that overruns eats into the walkthrough; a walkthrough that overruns eats into the questions — and the questions are where each member shows what they know.

The live demonstration

Fifteen minutes, on the public testnet, from DEMO.md. It has to include:

• The happy path of your application, end to end, with transactions confirmed on the testnet and visible on the explorer.
• The decentralised feature, shown doing the thing a centralised version could not — funds moving only by rule, a verification that needs no issuer, an execution that needs no administrator.
• At least one failure path: a transaction that the contract rejects, with the reason surfaced in the interface. The jury will likely ask for a second one of its choosing.
• The explorer: the verified contract, the transactions the demo just produced, the events they emitted.

A public testnet is a public network. RPC endpoints stall, faucets run dry, blocks take longer than they did in rehearsal. Have a local node with the same deployment ready as a fallback, and say so if you switch to it; the jury knows what a testnet is like on a Saturday morning, and a group that handles it calmly makes a better impression than one that did not prepare for it.

The walkthrough

Fifteen minutes, screen-shared, in the code. Not slides — one architecture diagram is useful, more are a way to avoid the code. The walkthrough covers:

• The roles and trust table, and what in the contract enforces each line of it.
• The contract: its state, its rules, its events, and the two or three decisions you are least sure about.
• The tests: what they cover, what they do not, and one test you are proud of.
• The deployment: how it is reproduced, and where the addresses are recorded.
• The frontend: how it talks to the chain and how it handles a transaction from click to confirmation.
• What you would do differently, and what you cut.

Split this between the three of you by feature, not by layer.

The questions

Twenty minutes. The jury asks each member in turn, and it asks each member about parts they did not present — and, often, parts they did not write. The questions come from four places:

• Your code. “What happens on this line if the caller is a contract?” “Why is this external and that public?” “Show me where this event is consumed.”
• Your design. “What if the arbiter’s key is stolen?” “What stops a member voting twice?” “Who can change this parameter, and what would it take?”
• The seminar. “Your treasury holds an ERC-20. What does approve mean, and why does it exist?” “Explain what Base is to someone who knows Ethereum.” “What is the difference between your tests and a fuzz test?”
• The wider world. “Name a protocol that does what you do, in production. How does it handle the problem you struggled with?”

A member who cannot answer for a part of the project is a finding about the group, not about the member; the grade is the group’s. A group that knows this arrives having taught each other the code.

The close

The jury does not announce a grade. It tells you what it saw — what held up, what did not, what it would have wanted to see — and that is the end of the module.

Preparing

• Rehearse DEMO.md on the testnet from a clean browser profile, with the exact wallets you will use, at least twice, once the evening before. Fund those wallets in advance; ask for testnet ETH on Teams before the freeze, not on the morning.
• Pre-stage anything that depends on time. A timeout that needs a day to elapse is demonstrated on a job you created yesterday.
• Read your own README as a stranger. Better: hand it to another group and watch them try.
• Teach each other the code. Two hours where each member explains their part to the other two, and takes questions, is the best preparation for the twenty minutes that decide the most.
• Know your trust boundaries cold. Every question about design comes back to the roles table. If you can recite it, you can answer.