Most applications that are built on a blockchain should not have been. The industry has spent a decade proving this, at considerable expense. This module asks you to build one that should — and the way to tell the difference is a single question.
The question
Replace the blockchain with a Postgres database and one trusted administrator. What breaks?
If the answer is “nothing anyone would notice”, the chain is decoration. The application would be faster, cheaper, and simpler without it, and a project built on it will spend six weeks fighting the platform for no return.
If the answer names something specific — a thing the administrator could now do, or a thing a user could no longer verify — then that thing is your decentralised feature, and it is what your project is about.
What a chain actually provides
There are only a handful of properties a blockchain gives you that a database with an administrator does not. Your feature has to rest on at least one of them.
Nobody can seize, freeze, or redirect what the contract holds. Funds in an escrow contract move only according to its rules. The platform that deployed it cannot decide otherwise, cannot go bankrupt with the money, cannot be ordered to hand it over. This is the property behind escrow, treasuries, and anything where strangers put value in the same place.
Nobody can rewrite the record. What was written is what was written, and anyone can check it against what they were told. This is the property behind registries, credentials, provenance, and anything where a claim needs to be checked by someone who does not trust the claimant.
The rules are enforced by execution, not by policy. A vote tallies the way the code says, a payout splits the way the code says, a deadline passes the way the code says. No administrator “reviews” the outcome. This is the property behind governance, automated agreements, and anything where the parties would otherwise need to trust a referee.
Anyone can act, and anyone can build on top. There is no account to be approved for, no API key to be revoked, no terms of service. A contract deployed for one purpose can be called by another. This is the property behind composability, and it is why the ecosystem exists at all.
Ownership is transferable, and the transfer is final. A token moves from one address to another and the previous holder has no recourse. This is the property behind everything called a token, and it is more often a liability than a feature — but when transferability is the point, nothing else gives it.
Notice what is not on the list: speed, cost, privacy, storage, or convenience. A chain is slower, more expensive, more public, and holds less than any alternative. You accept that to get one of the properties above. If you do not need one of them, do not pay for them.
Worked examples
A to-do list stored on chain. Fails. The only actor is the user editing their own data. The administrator of the database version could delete your list, but so could an outage, and you would not build an application around either. Nothing anyone cares about depends on the chain.
A loyalty-points programme for a single café. Fails. The café issues the points, decides what they are worth, and decides what they buy. Putting them on a chain makes the balance unforgeable, but the café was the only party who could forge them and the only party who honours them. The trust relationship is unchanged.
A supply-chain tracker that records each step of a shipment. Usually fails, and it is the most instructive failure. The chain guarantees that what was recorded cannot be altered. It says nothing about whether what was recorded was true — a warehouse that scans a crate it did not receive produces an immutable lie. The trust problem is at the point of data entry, and the chain does not reach it. This is called the oracle problem, and it is on the exam.
An escrow between two strangers, with an arbiter for disputes. Passes. Without the chain, whoever holds the funds during the job — the platform — can disappear with them, freeze them, or side with whoever pays more. With the chain, the funds move only when the rules say, and both parties can read the rules before they commit. The arbiter is still trusted, and the roles table has to say so; but the platform is not.
A diploma registry that employers can check. Passes. Without the chain, verifying a diploma means asking the school, which may be slow, offline, defunct, or lying. With the chain, the school’s attestation is public, timestamped, and checkable by anyone against the school’s known address, forever, without the school’s involvement. Revocation stays with the school; verification does not.
A community fund where members vote on spending. Passes. Without the chain, whoever holds the bank account decides, and the vote is advisory. With the chain, the treasury moves only when a vote passes under rules that were public before the vote started, and anyone can trigger the execution. The question the roles table has to answer is who can change the rules.
A social network with posts on chain. Partial. Censorship resistance is real — no one can delete a post — and it is a genuine property. But storing text on a chain costs more per kilobyte than almost any other place to put it, and the feature that is actually decentralised is not “posting”, it is “not being deletable”. A version that stores content hashes on chain and content elsewhere passes; a version that stores everything on chain demonstrates that the group has not thought about cost.
A raffle where the draw is provably fair. Passes, with a trap. The draw’s fairness is verifiable — anyone can check that the winner was chosen by the published rule. But the source of randomness is the whole design: a block hash can be influenced by whoever produces the block, and a value supplied by the organiser is the organiser choosing the winner. The subject is fine; the naive implementation is not.
Writing the justification
The README of every project contains this, in this shape, in no more than half a page:
- The feature. One sentence. “Funds locked for a job cannot be moved by anyone except through completion, refund, or arbitration.”
- The centralised version. What a platform with a database could do that yours cannot. Be concrete: name the action.
- Who cares. Which user, in which situation, is protected by that. If you cannot name one, go back to the question.
- What is still trusted. Every party your design relies on, and what happens if they misbehave. This is the honest part, and the jury weighs it more than the previous three.
A justification that claims the application is “fully decentralised” is wrong — every design trusts something, if only the deployer at deployment time — and reads as if the group did not look. One that says “the arbiter is trusted to be honest in disputes; a dishonest arbiter can direct disputed funds to either party but cannot touch undisputed ones” is the kind of sentence that gets a nod.