Most things presented as blockchain use cases are databases with extra steps.
That is not cynicism about the technology. It is the single most useful filter for anyone deciding whether to spend money on one, and applying it early saves an expensive detour. So before the use cases, the test.
The test
A blockchain earns its place when three things are true at once.
Several parties need to write to the same record, and they do not fully trust each other. One company keeping its own records has a database problem. Five competitors who all need to agree on a shared history is a different situation.
No single party can be allowed to control the record. If everyone involved would accept one organisation running the system, that organisation should run the system. It will be faster, cheaper and easier to fix.
The history must be verifiable by someone outside. A regulator, a customer, an auditor — somebody who was not there needs to check what happened without taking your word for it.
Two out of three is a database. All three, and a chain starts to make sense.
Most enterprise blockchain projects that quietly died failed this test at the first question, and everyone involved could see it at the time.
What passes
Provenance in supply chains. A product changes hands between a producer, a shipper, a customs broker, an importer and a retailer. None of them will host the others' data, all of them need the same view, and a regulator or an end customer may want to verify origin. This is the strongest non-financial case there is, and it is why food safety and luxury authentication keep coming up.
Settlement between competitors. Insurers reconciling shared claims, carriers splitting freight, banks settling between themselves. Parties with opposed commercial interests, needing one agreed record, with no natural neutral host.
Verifiable ownership of digital things. Licences, tickets, credentials, certificates. The value is that the holder can prove ownership to any third party without going back to the issuer — which matters when the issuer might be gone, or slow, or is the thing being checked.
Programmable settlement. Payment releasing automatically when an objectively checkable condition is met. The value comes from removing the reconciliation, not from decentralisation as such.
What usually does not
Internal record keeping. One company's data, one company's control. A database with a decent audit log does this better in every measurable way.
Voting. The ledger is the easy part. Verifying that a voter is who they claim, that they voted freely and privately, and that the whole thing is auditable without being traceable — none of those are solved by a chain, and some are made harder.
Storing documents. On-chain storage is expensive and permanent, which is an unfortunate combination when personal data is involved and someone exercises a right to erasure. Anchor a hash, keep the document elsewhere.
Loyalty points. Almost always a database. The chain gets added because it sounds modern, then someone has to explain wallets to customers who wanted a stamp card.
What it costs to be right about this
Even where a chain fits, it is not free.
Public networks are slow and priced by demand. Private ones are faster but reintroduce the question of who runs the infrastructure, which was the original problem.
Cross-chain bridges have been the most attacked surface in the space, so a design spanning two networks inherits that risk.
Regulation is not settled anywhere, and a structure built today should assume it will be revisited.
And someone still has to get real data onto the chain. A perfectly immutable record of a wrong reading is a very expensive wrong reading — the oracle problem does not disappear because the ledger is tamper-proof.
The version worth acting on
Ask what you would show an outsider to prove something happened, and who currently has to be trusted for that proof to hold. If the answer is "us", you probably want a database. If the answer is "a group of organisations who compete with each other", a chain is worth costing.
We build and audit this layer, and we will say when it is not needed. Tell us the problem rather than the technology, and we will tell you which one it is.
