Final defence

One hour, with your application running live on Base Sepolia. One member may lead the presentation; the jury reserves the right to question any member, on any part of the project, and usually does. What is defended is the last commit pushed before the code freeze; work after that moment is not part of the defence, whichever of the two defence days your group is scheduled on.

At the start

The jury collects the code as the defence opens: the repository’s URL and the commit being defended. It has not read it beforehand. The hour is therefore where the project is discovered, and the walkthrough is where you make that discovery efficient: the jury reads your README, your roles and trust table, and your tests over your shoulder, and asks about what it sees.

This means the README does real work anyway. A repository a stranger can understand in ten minutes leaves fifty for the parts that earn something; one that needs explaining spends the hour on explanations.

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 the group shows what it knows.

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 the morning of a defence, 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 chooses whom it asks. It tends to ask 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 sessions. “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.