Blockchain beyond the hype: where distributed ledgers actually pay off
9 June 2026 · 8 min read · Nintech Engineering
Blockchain has spent a decade as a solution in search of problems, and most of the enterprise pilots from 2016-2020 died quietly — including flagships like Maersk and IBM's TradeLens, which shut down in 2023 despite real technology and real backing. That history is worth taking seriously, because it sharpens the question rather than closing it. Distributed ledgers do solve a real problem; it is just a much narrower problem than the pitch decks claimed, and recognising it requires an honest test most projects never apply.
The honest test
Strip away the terminology and a blockchain is a database with unusual properties purchased at unusual cost: multiple parties maintain a shared, append-only record, and no single party can unilaterally rewrite it. That is the whole offer. So the qualifying test has three parts, and all three must hold. First: are there multiple independent organisations involved — not departments of one company, but entities with separate legal existence and separate interests? Second: do they need shared, agreed-upon state — the same view of who owns what, or what happened when? Third: is there no party they all trust to hold that state — no regulator, no industry utility, no dominant player whose database everyone would simply accept?
Most proposed use cases fail the third question. Banks already trust clearing houses. Supply-chain partners already trust the retailer who dominates the relationship. Government registries are trusted by construction. If a trusted operator exists or can be created, a conventional database run by that operator is faster, cheaper, easier to fix when something goes wrong, and legally simpler. The test is not 'could this work on a blockchain' — almost anything could — it is 'does the trust gap actually exist, and is it expensive enough to justify the machinery'.
Where the machinery earns its keep
The genuine wins cluster in three areas. Provenance across adversarial or fragmented supply chains: pharmaceutical serialisation and conflict-mineral tracking involve many parties with incentives to falsify records and no operator all of them accept — an append-only shared ledger raises the cost of quiet retroactive edits, which is precisely the property paper trails and vendor databases lack. Settlement between financial institutions: when banks trade assets, each maintains its own ledger and reconciliation armies spend days making them agree; a shared ledger collapses reconciliation because there is only one record to disagree about. JPMorgan's Kinexys (formerly Onyx) processing billions in daily repo settlement is the standing example that this is not theoretical — atomic delivery-versus-payment reduces counterparty risk measured in real money.
The third cluster is multi-party workflows with contested state transitions: trade finance, reinsurance claims, syndicated loans — processes where a document passes through five organisations, each of which historically kept its own copy and disputed the others'. Here smart contracts function as workflow automation with a shared audit trail: the letter of credit releases payment when the shipping data lands, and every party sees the same event at the same moment. Note what all three clusters share: the value is in the reconciliation and dispute costs avoided, which are quantifiable. If a project cannot state its reconciliation cost today, it has no business case.
Usually, the answer is Postgres
The far larger set of cases fails the test, and it is worth being blunt about the pattern. Internal audit trails: one organisation, so an append-only table with write-once permissions and off-site log shipping delivers the same tamper-evidence at a thousandth of the cost. Loyalty points, ticketing, document notarisation, most 'supply chain visibility' projects: a trusted operator exists — it is you — and your customers were never going to run validating nodes. The oracle problem compounds this: a ledger guarantees that recorded data cannot be silently changed, not that it was true when recorded. If a warehouse operator scans the wrong pallet, the blockchain faithfully immortalises the error. Garbage in, immutable garbage out.
A useful tell is asking who runs the nodes. If the honest answer is 'we run all of them' or 'one vendor runs them and everyone else has read access', you have built an expensive, slow, awkward database with extra steps, and the immutability claim is theatre — whoever controls the validator set controls the history. Many of the dead enterprise pilots were exactly this: single-operator chains wearing decentralisation as a costume. The boring alternative — a conventional database with proper access controls, signed audit logs, and an API — would have shipped in a quarter of the time and survived contact with the operations team.
Enterprise realities: governance eats technology
Real enterprise deployments are permissioned chains — Hyperledger Fabric, Corda, Besu — not public networks, because regulated industries cannot put transaction data where anyone can read it and cannot accept probabilistic finality or public gas markets. This is the pragmatic choice, but be clear-eyed about what it trades away: a permissioned chain's trust model is only as strong as its membership governance, which means the hard problems are contractual, not cryptographic. Who admits new members? Who pays for shared infrastructure? What happens when a member is acquired by a competitor, or when a bug requires rewriting 'immutable' history — as consortiums have quietly done? These questions consume more of the project than the technology does, and TradeLens died on exactly this ground: competitors declined to join a platform their rival part-owned.
Integration cost is the other systematically underestimated line. The ledger is perhaps a fifth of the build; the rest is connecting it to each participant's ERP, KYC, and reporting systems — multiplied by every member of the consortium, each with their own IT backlog and their own compliance sign-off. A realistic appraisal: expect years, not quarters; expect the governance agreement to take longer than the software; and expect the business case to live or die on whether reconciliation savings exceed integration spend. Where all of that holds — genuinely multi-party, genuinely trust-scarce, genuinely expensive reconciliation — distributed ledgers are the right tool, and the survivors in settlement and trade finance prove it. Everywhere else, the boring database was the right answer all along.
Working on something like this? Talk to an engineer.