Where Blockchain Does Not Make Sense

Being able to say where a technology does not apply is not scepticism. It is the same skill as knowing where it does — you cannot have one without the other, and a recommendation from someone who has never said no is not worth much.

Here are five that recur.

1. Supply chain provenance, with one dominant buyer#

The proposal. Put every step of the chain of custody on a ledger so nobody can falsify the record.

What breaks. The ledger faithfully records whatever it was told. If a supplier scans a pallet at the wrong dock, the wrong location is now permanently and verifiably recorded. Immutability protects the record after entry; it does nothing about entry.

And the second condition fails outright. There is usually a dominant buyer setting the terms for everyone else. They are the natural authority, they already have the leverage, and the ledger does not change that.

What is usually wanted. Shared read access to data currently sitting in somebody's ERP, with an audit trail. That is an integration problem.

2. Medical records on a chain#

The proposal. Patient-controlled records, portable between providers, tamper-proof.

What breaks. Two things, and both are fatal.

First, the record must be erasable. Under GDPR and similar regimes, a patient can require deletion. A structure whose defining property is that history cannot be removed is the wrong shape for data with a legal right to erasure. Storing pointers on-chain and data off-chain works, but at that point the chain is a pointer table and you should ask what it is for.

Second, medical data is confidential. A ledger every participant replicates is the opposite of that. Encrypting it helps until you consider that today's ciphertext is being archived by everyone, and key compromise or a break in the scheme is retroactive.

What is usually wanted. Interoperability standards and a consent model. Both exist and neither needs a chain.

3. Internal audit for a single company#

The proposal. Put internal records on a private chain so they cannot be altered.

What breaks. One organisation, one writer, one authority. Condition two fails before you start. Whoever runs the nodes can also change the software they run.

What is usually wanted. An append-only, signed audit log with separated duties and off-site copies. Achieves the same control, in a system your auditors already know how to assess.

4. Voting#

The proposal. Elections on a chain — verifiable, tamper-proof, publicly auditable.

What breaks. Voting has a requirement almost nothing else has: the result must be public and verifiable while individual votes stay secret, and a voter must not be able to prove how they voted, or votes can be bought and coerced.

A transparent ledger gives you verifiability by making things visible, which is the wrong tool for a problem that requires the opposite. There is serious cryptographic work on this — homomorphic tallies, mix networks, zero-knowledge proofs — and it is mostly independent of blockchain.

There is also the endpoint. Compromise the device where the vote is cast and the ledger records the compromised vote perfectly.

5. Micropayments for content#

The proposal. Readers pay a fraction of a cent per article, settled on-chain.

What breaks. Usually the economics. If settling a payment costs more than the payment, the model is inverted. Layer-two systems and payment channels genuinely address this, so the technical objection is weakening.

The behavioural one is not. Per-item pricing imposes a decision on every item, and the friction of deciding costs the reader more than the fraction of a cent does. This has been tried repeatedly since the 1990s and fails at the same place each time, which suggests the problem is not the settlement layer.

The shape of the pattern#

Look across all five and the same three failures repeat:

• An acceptable authority already exists. Then the expensive part is buying you nothing.
• The data should not be public or permanent. Then the ledger's defining properties work against the requirement.
• The hard part is at the boundary. Getting truthful data in, or acting on it outside the system. Consensus does not reach either.

Run any proposal past those three before anything else. Most stop there — and the ones that do not are worth taking seriously, because whatever they are solving genuinely has no simpler answer.