The project

Build and deploy a decentralised application that actually needs the chain: at least one feature that stops working, or stops being trustworthy, if you replace the blockchain with a database and an administrator. Three subjects are proposed below; you may also propose your own.

The project runs from the end of Day 2 to the code freeze, about six weeks later. It is defended live, on the public testnet, in the final defence, after a mandatory intermediate defence about three weeks in. Dates are on the intranet; the schedule has the sequence.

Timeline

Six weeks, alongside other modules and, for some of you, a job. Plan for that. A project that reaches the intermediate defence with a deployed contract, a test suite, and a frontend that does one thing is in a far better place than one that reaches it with a beautiful design document.

What every project must include

Whichever subject you pick, these are the parts of a complete delivery.

1. At least one smart contract deployed on Base Sepolia, verified on Basescan, with logic that does something, state that changes according to rules, with more than one actor involved. A contract that stores a value and returns it is not a project.

2. The decentralised feature, identified by name, and its justification written in the README in the form the decentralisation test asks for: what a centralised version could do that yours cannot, and why that matters to the people using it.

3. A frontend that lets a user connect a wallet, see the relevant state, perform the application’s actions as transactions, and see the result, including when it fails. Any framework; wagmi and viem are what the sessions teach.

4. Tests for the contracts, covering the behaviour that matters: the happy path, every rule that can reject a transaction, and every role boundary. A test suite that only checks the constructor is not a test suite.

5. A roles and trust table: every role in the system (the deployer, an admin if there is one, each kind of user, any arbiter or oracle), what each one can do, and what happens to everyone else if that role acts maliciously or disappears. This is the most important page of your README and the first thing the jury reads.

6. A reproducible deployment: a script that deploys the contracts to a named network from configuration, the deployed addresses recorded in the repository, and no secrets in git.

7. A README that lets a stranger clone the repository, run the tests, run the frontend against your testnet deployment, and understand the architecture in ten minutes: what is on chain, what is off chain, and why.

Going further

The list above is the shape of a complete project. Depth comes from what you build on it, and there are many directions; pick the ones that fit your subject and your group’s interests rather than trying to touch all of them.

• Indexing. Read the chain’s events into a queryable store, your own small indexer with viem, or Ponder, or a subgraph, and use it to build a view a contract cannot serve directly (history, search, aggregates).
• Property-based and invariant testing with Foundry, alongside your Hardhat suite. Write down the invariants of your contract and let the fuzzer try to break them.
• A security self-review: run Slither, address or explicitly dismiss each finding, and write a short threat model that goes beyond the roles table, what an attacker with a flash loan, a front-running bot, or a compromised key could do.
• Signature-based flows: EIP-712 typed data for off-chain approvals, permits, or vote-by-signature, with proper replay protection.
• Gasless or sponsored transactions through account abstraction, so a user without ETH can still act.
• Composition with an existing protocol on the testnet, accept an ERC-20, hold funds in a yield-bearing position, price something through an oracle, with the trust implications spelled out.
• Off-chain content on IPFS, with the content hash on chain and the frontend resolving it.
• Upgradeability, only with a written justification of who controls the upgrade and why users should accept that.
• Engineering quality: continuous integration running the tests on every push, gas reporting, a deployment that is deterministic across networks, a frontend that handles the whole transaction lifecycle gracefully.
• A post-mortem of a real incident in the same category as your project: a drained escrow, a governance attack, a credential forgery, and what in your design addresses it.

What will not work

• A token with no purpose. “We made an ERC-20” is a git clone.
• CRUD on a chain. If the only actor is the user editing their own data, there is nothing to decentralise.
• Decentralisation in the UI only. A frontend calling a backend that calls a contract the backend owns is a centralised application with an expensive database.
• A tutorial with the names changed. The jury knows the tutorials.
• Anything on a mainnet. Testnet only. No real funds, anywhere, at any point.
• A group where one person did the contract and the others watched. Every member answers for every part at the defence.

Subjects

Three subjects, on three different themes, described on their own pages:

• Escrow for freelance work, money and commerce. Funds that a platform cannot run away with.
• A community treasury, governance. Rules that no administrator can override.
• Verifiable credentials, identity and provenance. Claims that anyone can check without asking the issuer.

Each subject page lists the actors, the core features that make it that subject, suggested extensions, the traps, and what the demo at the defence should show.

Proposing your own

A group may propose a subject of its own. Write it up on Teams within a week of Day 2: a paragraph on what it does, the roles and trust table in draft, and the decentralisation test applied to it. You get an answer within the week, accepted, accepted with changes, or sent back with the reason. The bar is the same as for the three subjects: the application has to need the chain, and the scope has to fit six weeks alongside your other work.

Delivery

At the code freeze, the repository must contain:

• The commit to be defended is the last one pushed before the freeze. No tag is needed; do not push anything after it that you do not intend to defend.
• The README described above, with the deployed addresses on Base Sepolia.
• The deployment script and the configuration it reads.
• A DEMO.md: the exact sequence you will run at the defence, step by step, with the addresses and accounts involved. You will follow it live; writing it down is how you find out it does not work before the jury does.

Anything pushed after the freeze is not part of the defence. A group that discovers a bug afterwards fixes it on a branch and says so at the defence, which is a perfectly good answer.

A plan that fits six weeks

The schedule below is what a group that finishes comfortably looks like. It is a suggestion, not a requirement, but a group that is a week behind it at the intermediate defence will be told so.

The weeks are not equal. Week 1 is the hardest to start and the most valuable to finish; week 6 should contain no new code.

Working as three

Some advice, from watching groups do this.

• Deploy something in week one. A contract with two functions, on Base Sepolia, verified, with a page that reads it. Everything after that is iteration. Then expect your ABI and your deployed address to drift apart as you iterate, and make your page say so out loud: a read that fails must not look like a read that returned zero. Groups that wait to deploy “until it is ready” discover the deployment problems the night before the defence.
• Write the roles table before the contract. It is the design. If you cannot fill it in, you do not know what you are building yet.
• Split by feature, not by layer. Three people each owning a vertical slice, contract, tests, frontend for one feature, learn the whole stack. Three people owning “the contract”, “the tests”, and “the frontend” produce three people who can each answer a third of the questions.
• Rehearse the demo. On the testnet, from a clean browser profile, with the wallet you will use on the day. Transactions on a public testnet take seconds; a demo that has not been rehearsed takes minutes.