Intermediate defence

Three weeks into the project, each group spends thirty minutes with the jury. Nothing said in that room affects your grade. Everything said in that room is meant to change what you do in the three weeks that follow.

The intermediate defence exists because the final defence is one hour, live, against a frozen commit, and there is no second attempt. Groups that arrive there with a fundamental problem — a feature that is not actually decentralised, a contract that cannot be deployed, three people who each know one third of the code — have usually had that problem since week two. This is where it gets caught.

Format

Thirty minutes is short. The jury will hold you to the clock so that the next group is not penalised.

What to bring

• Something that runs. On Base Sepolia if you have deployed — and you should have — or on a local node if you have not. A contract with two working functions and a page that calls them is a good intermediate state. A slide deck describing a contract that will exist is not.
• The roles and trust table, in whatever state it is. This is the design; the jury will read it before anything else.
• The decentralisation test, applied to your feature, written down.
• The repository, with the teacher already a collaborator, and a look at who has committed what.
• A plan for the remaining three weeks: what is left, in what order, and who owns each piece.
• Your questions. This is the only scheduled time you have the jury’s full attention before it matters. Use it.

No slides are needed. A diagram of the architecture on a whiteboard, a screen share of the app, and the README are enough.

What the jury looks at

None of this is scored. All of it predicts the final defence.

• Is the decentralised feature real? Can the group name it in one sentence, and say what a centralised version could do that theirs cannot? Groups that hesitate here are building the wrong thing.
• Is there a deployed contract, or a credible path to one within a week? Deployment is where hidden problems live — configuration, keys, verification, gas — and the sooner they surface the better.
• Have the tests started, and do they test rules rather than constructors?
• Does the split of work spread the knowledge? The jury will ask each member a question about a part they did not write. Not to catch anyone out, yet — to show the group what the final defence does.
• Is the scope survivable? Six weeks alongside other work. A group planning four extensions and no tests will be told so.
• What is the risk list? What could stop the project from being defensible, and what is the fallback.

What you leave with

• A verdict, in plain words: on track, on track with changes, or at risk — and in the last case, what would make it not at risk.
• Specific feedback on the design, especially the roles table.
• The exact format of the final defence, from the jury’s side: what it reads beforehand, how the hour is split, what the live demo has to include, how the questions work.

Common findings

From experience of this kind of checkpoint, the things groups most often hear:

• “Your feature is decentralised, but your frontend calls a backend that holds the only key. Your users trust your server.”
• “The admin can do everything. Either remove the admin or write down what it can do, in the table, in bold.”
• “You have not deployed. Deploy this week, with whatever you have.”
• “Your tests check that the constructor sets the owner. Test the rule that rejects a non-owner.”
• “One of you wrote all of the contract. In three weeks, all three of you will be asked about it.”
• “This is too much. Cut the second extension and finish the first.”