When blockchain is the wrong answer (and what to use instead)

Why teams reach for blockchain

The motivations are usually reasonable. They just don’t always require a ledger. These are the ones we hear most often:

Trust and auditability.

The business wants a record nobody can quietly alter. That is a legitimate requirement, and it has several well-understood solutions.

Sharing data across organizations.

Partners need the same view of shipments, payments or claims, and today they reconcile spreadsheets by email.

Removing an intermediary.

A process runs through a clearing house, broker or platform operator, and someone wants to take out the fees and the delay.

Programmable assets.

Fund units, bonds or loyalty points, where the asset and the rules for transferring it live in the same system.

Strategic pressure.

A competitor announced a pilot, or the board asked about tokenization. This is the weakest reason, and it deserves a direct conversation.

Each can point toward a ledger. Most can also be met with tools that are cheaper to build, simpler to operate and better understood by the auditors and regulators who will examine the system.

Four questions to ask first

Before anyone writes a smart contract, we work through four questions with the client’s architects and business owners. Together, the answers show whether a ledger belongs in the design.

Are there multiple writers who don’t trust each other?

If one organization writes all of the data, a ledger adds nothing that access controls and an audit log cannot. The case for DLT begins when several independent parties must write to the same record and none will accept another as its sole keeper.

Do you need a shared, tamper-evident record across organizational boundaries?

Tamper evidence inside one company is a solved problem. The harder requirement is a record that several organizations can each verify for themselves, without taking anyone’s word for it.

Can a trusted operator exist?

Many markets already have one: a clearing house, a registry, an industry body. If the participants would accept a neutral operator running a conventional system under contract and independent audit, that is usually the simpler design.

Is disintermediation actually wanted?

Removing the intermediary sounds attractive until someone has to take over its work: onboarding, dispute resolution, compliance and support. If the participants want those functions to stay with an accountable party, a ledger will not remove the intermediary. It will only move the cost.

If only one party writes, or a trusted operator exists and everyone accepts it, a ledger is almost certainly the wrong tool. If several parties who don’t trust each other must share a record, and no single operator is acceptable to all of them, DLT deserves serious consideration. Most real initiatives land somewhere in between, which is why we write the reasoning down.

What to use instead

When the four questions point away from a ledger, the underlying requirement does not go away. It needs a different design. These are the substitutions we recommend most often.

When DLT is the right answer

None of this is an argument against distributed ledgers. We build them, and some of our longest-running systems depend on them. DLT earns its place when several of these conditions hold at once:

• Several independent organizations write to a shared record, and none will let another hold the master copy.
• Each participant needs to verify the record for itself rather than rely on an operator’s reports.
• The rules for changing the record must be enforced by the system, not only by a contract someone would have to litigate.
• Assets need to move between parties with clear settlement finality, as with tokenized fund units or securities.
• The participants are prepared to fund and govern shared infrastructure for the long term.

Consortium traceability is a good example: members compete, none will host the others’ data, and each must prove provenance to regulators. A permissioned Hyperledger Fabric network with channels and private data collections fits that shape. So does tokenizing private-markets fund units, where ERC-3643 permissioned tokens on a Besu or Quorum network enforce transfer eligibility on-chain, with keys in MPC or HSM-backed custody.

Even then, the ledger is one component among many. Identity, ERP integration, indexers, reporting and support processes usually account for most of the engineering effort. A ledger that sits beside a company’s IT estate, rather than inside it, rarely makes it past the pilot.

How our feasibility assessment works

When a client is unsure, we propose a DLT Feasibility Assessment before any build. It is fixed price, takes two to three weeks, and ends with a written recommendation that we stand behind whichever way it points.

Discovery.

Workshops with business owners, architects, security and compliance. We map the participants, trust relationships, data flows and regulatory context.

Options analysis.

We compare at least one conventional design with the relevant ledger options on the four questions, cost, operability and risk.

Recommendation.

We write it up, review it with your team and take the hard questions in the room.

You receive a written recommendation, including a plain “don’t use blockchain” where that is the right answer; an architecture sketch of the recommended design with its key decisions and trade-offs; and a cost model covering build, infrastructure, operations and governance over three years.

The short version

A blockchain is a specific tool for a specific problem: shared state among parties who will not trust a single operator. When that problem is present, a well-architected ledger is worth the effort. When it is not, a database, a signed API or an append-only log will do the job at lower cost and lower risk.

If you are weighing a ledger for a live initiative, book a DLT Feasibility Assessment. You will have a written answer within three weeks, even if that answer is a database.