Blockchains are usually taught as a topic: consensus algorithms, hash functions, the history of Bitcoin. This module teaches them as a platform. Somewhere around 2015 it became possible to deploy a program that nobody, not its author, not a company, not a government, can stop, alter, or quietly take offline, and that anyone can call. That changed what kinds of applications can exist. Not every contract has that property, though: most contracts in production can be upgraded or paused by someone, and Base, the network this module deploys to, has a single sequencer, run by Coinbase, that decides what goes into each block. Learning to tell which is which is a large part of the module. The point of these four days is to make you fluent in that platform: its vocabulary, its ecosystem, its tooling, and above all its trade-offs, so that when you meet it in a job you know what it is good for, what it is bad for, and what to do next.
You will leave having written, tested, and deployed smart contracts on a public network, built a web frontend that talks to them through a wallet, and shipped, as a team of three, a decentralised application in which the chain actually matters.
What this module is
- A working introduction to the Ethereum ecosystem, Ethereum itself, the Layer 2 networks built on it, and the standards, protocols, and tools that surround it.
- A development module. Most of your time is spent with an editor open. Solidity, Hardhat, viem, wagmi, OpenZeppelin, a block explorer (Basescan), a wallet (MetaMask).
- A module about judgement. The single most important skill taught here is knowing when a blockchain is the right tool, which is rarer than the industry suggests, and being able to say why.
- A module about culture and vocabulary. Tokens, gas, rollups, AMMs, oracles, account abstraction, MEV: you will be able to hold a technical conversation about all of these without bluffing.
What this module is not
- Not a cryptography course. You will use signatures and hashes constantly; you will not prove anything about them.
- Not a course on consensus. Proof of Work and Proof of Stake get the time they deserve for a developer, which is about twenty minutes.
- Not an investment or trading module. Prices are never discussed, except as an attack vector.
- Not a survey of every chain. Everything is EVM. Once you know one EVM chain, moving to another is a configuration change; moving to a non-EVM chain is a different module.
Format
| Part | Format | When |
|---|---|---|
| Day 1, seminar | On site, hands-on | Opens the module |
| Day 2, seminar | On site, hands-on | The next day |
| Day 3, remote lesson | Remote, lecture | About two weeks later |
| Intermediate defence | 30 minutes per group | About three weeks after Day 2 |
| Day 4, remote lesson | Remote, lecture | About four weeks after Day 2 |
| Final defence | 1 hour per group | Over two defence days, about six weeks after Day 2 |
The schedule gives the sequence of the module and the spacing between its parts. Dates, times, and rooms are on the school’s intranet, which is the reference.
The two on-site days are the seminar proper, and they are practical by design: installation, first contract, first tests, first deployment, first frontend. That is where having someone at the next desk helps most. The two remote lessons are lecture-shaped, also by design: the ecosystem, security, architecture, and the wider world: material that a good lecture carries well, and that you can revisit afterwards since everything is published here.
How the sessions are taught
Each session page on this site holds the full notes for that day and the practical exercises, with the starter code and the demo code linked where a practical uses them. The sessions are taught from the notes; where one uses slides, they are added to its page after the session. Notes are published after each session rather than before; the session itself adds the live demos, the mistakes made in real time, and the questions.
The notes also link outwards, constantly. Where a topic has a canonical reference, a cheatsheet, a specification or a protocol worth reading, it is in a bordered block like the one below, next to the paragraph it belongs to. None of it is mandatory and all of it is chosen; the resources page collects every one of those links in one place.
Practical exercises during the sessions are not assessed. They exist to illustrate the material and to get you unstuck in a room where help is available. Some of them will take longer than the slot allows; finishing them at home is expected and encouraged, and the reference solutions are published on the practicals page.
The project
You work in groups of three. Each group builds and deploys a decentralised application in which at least one feature genuinely depends on the chain, where replacing the blockchain with a database and a trusted administrator would break something that matters. Three subjects are proposed; a group may propose its own, subject to approval.
The project starts at the end of Day 2 and runs to the code freeze, about six weeks later. The project page has the full brief; the decentralisation test is the criterion every subject, proposed or chosen, has to pass.
Defences
The intermediate defence is mandatory. It exists so that neither you nor the jury is surprised at the end: you show where the project stands, the jury tells you whether it is heading somewhere defensible, and you leave knowing exactly what the final defence will look like.
The final defence is the assessment of the module. It is held against the commit that exists at the code freeze, on the public testnet, live. One member may lead the presentation; the jury reserves the right to question any member, on any part of the project.
Tooling
| Category | Choice |
|---|---|
| Network | Base Sepolia (an Ethereum Layer 2 testnet); local Hardhat node for development |
| Language | Solidity 0.8 |
| Framework | Hardhat 3, TypeScript |
| Libraries | OpenZeppelin Contracts |
| Client | viem, wagmi, with React (Vite or Next.js) |
| Wallet | MetaMask |
| Explorer | Basescan |
| Advanced testing | Foundry, introduced on Day 4. The Hardhat template already ships a Foundry-style Solidity test; ignore it until then |
You may add whatever you like on top for the project, any frontend framework, any indexer, any storage layer. The core is fixed so that the whole room shares one vocabulary and one debugging surface.
Rules
- Groups are three people. You form them yourselves. Fourth-year and fifth-year students may mix.
- The project lives on the school’s GitHub, in a repository the group creates. The teacher does not need access during the project: the code is collected at the start of the defence.
- Declare your group and your subject within a week of Day 2, on Teams. Groups proposing their own subject get an answer within the week; a subject that fails the decentralisation test is sent back with the reason.
- The code freeze is one moment for every group, the day before the first final defence, whichever defence day you are scheduled on. The last commit before it is the one defended. The date is on the intranet.
- Every member must be able to explain and modify any part of the code. The defence tests this. A group where one member cannot answer for the contract, or the frontend, or the tests, is a group with a problem.
- AI assistants are allowed, for the session exercises and for the project, in the same way they are allowed at work: as a tool whose output you are responsible for. Code you cannot explain is code you did not write. The defence will find out.
- Never put real funds in a wallet used for this module. Create a dedicated development wallet on Day 1 and keep it that way. Never commit a private key. The sessions show you how to avoid both mistakes; the module does not cover losses.
Contact
Everything goes through Teams: questions, group declarations, subject proposals, and the addresses to fund with testnet ETH. Expect answers within two working days during the project period, faster around the defences.