We build distributed ledger systems. We also talk more clients out of them than into them, and we think that is the responsible position for anyone who sells the technology.
The reason is simple arithmetic. A blockchain buys you one property — a shared history that no single participant can quietly revise — and charges you a great deal for it. Slower writes, harder upgrades, key management as a permanent operational burden, and a class of failure where a mistake is immutable too. If you can obtain that property some cheaper way, you should.
The test
Three conditions have to hold together. Not one, not two.
- There are several parties, and they are genuinely independent — different organisations with different interests, not different departments of one.
- They do not fully trust each other, specifically about the record. It is not enough that they disagree; they must have reason to suspect the other could alter history in their own favour.
- The record will be disputed, and the dispute will have consequences — payment withheld, a shipment rejected, a claim litigated.
If any one of those fails, a well-designed relational database with an append-only audit table and signed entries will serve better, cost less, and be maintainable by people you can actually hire.
A case that passes
Agricultural supply chains pass all three cleanly. A producer, a distributor and a retailer are separate businesses. Their commercial interests diverge precisely at the moment of dispute — quantity delivered, condition on arrival, origin claimed. And the disputes are routine, not hypothetical: they are why payment sits unreleased for months.
Put the custody events on a ledger and the argument changes character. It stops being one party's records against another's and becomes a question about a single history nobody can rewrite. Settlement can then be automated against it, because there is finally something trustworthy to automate against.
A case that fails
A single government agency wanting a tamper-evident audit trail of its own decisions fails the first condition, and it fails it decisively. There is one party. What they actually need is append-only storage, cryptographic signing, off-site replication and separation of duties so that no individual administrator can alter a record unobserved. That is a weekend of careful engineering, not a distributed consensus network.
We have seen that requirement dressed as a blockchain project more than once, usually because the word was in the funding proposal. The system that results is slower, more fragile and no more trustworthy than the boring version.
An immutable ledger only proves that somebody typed something. What ties an entry to the physical world is a tag, a signature, a witness — and that part is not solved by consensus.
The part everyone underestimates
Key management. A ledger's guarantees rest entirely on private keys held by people, and those people lose phones, leave jobs and share credentials. Every serious deployment we have delivered spent more design effort on custody of keys than on the contracts themselves. If a proposal does not have a detailed answer for what happens when a producer's key is lost, it is not finished.