Blockchain is often specified before the trust requirement is defined. The result is a project that carries the operating cost and complexity of a distributed ledger while solving a problem that a database with audit logging would have solved for a fraction of the cost.
This is not an argument against distributed ledgers. It is an argument for defining the requirement before selecting the tool. Digital trust is a property of a system's design, not of a particular database technology.
The test
A ledger is justified when three conditions hold at once.
- Multiple independent organisations need to rely on the same record.
- No single organisation should be able to alter that record unilaterally.
- The participants do not want to depend on one party's database as the source of truth.
If any of the three fails, a conventional database is usually the better answer. If one organisation owns the process and the data, it owns the record, and a ledger adds cost without adding trust.
It is worth being strict about the third condition, because it is the one most often assumed rather than tested. Participants frequently accept a trusted operator with contractual audit rights and export guarantees once the cost of the alternative is on the table.
What trust actually means in a business system
Trustless is a misleading word in commercial software. Participants in a business network do not need to trust nobody. They need specific guarantees that survive staff changes, commercial disputes and the possibility that the operator becomes a competitor.
Those guarantees are usually narrower than a ledger. The common requirements and the mechanisms that satisfy them:
- The record has not been altered since it was written. Append-only storage, hash chaining and signed entries inside one system.
- Both parties hold the same version of events. Shared interfaces with immutable event history, or scheduled reconciliation with a defined dispute process.
- An action happened at a specific time. Trusted timestamping or an external notarisation service.
- A third party can verify a claim without seeing the underlying data. Signed hashes and selective disclosure.
- No participant can rewrite history alone. This is the requirement that genuinely points toward a distributed ledger.
Only the last of these generally needs more than a disciplined conventional architecture.
The costs a ledger adds
| Conventional database | Permissioned ledger | Public chain | |
|---|---|---|---|
| Operating cost | Standard hosting and backup | Multiple nodes, governance and network operations | Transaction fees plus node or provider costs |
| Data privacy | Controlled by the operator | Shared ledger visibility must be designed | Assumes public or encrypted payloads |
| Performance | Predictable | Consensus adds latency | Throughput and finality constraints |
| Change management | Internal release process | Coordinated upgrade across participants | Contract and protocol constraints |
| Skills and support | Widely available | Scarce and network specific | Scarce and volatile |
| Exit path | Export and migrate | Requires participant agreement | Data remains public |
None of these costs is prohibitive on its own. All of them recur, and they are incurred whether or not the trust requirement was real.
Where a ledger does apply
Cases where the test is genuinely met tend to involve asset provenance across a chain of independent holders, shared audit records between counterparties who do not share a system owner, or verified participant identity across a network.
In most of those cases the practical design writes critical proofs and events to the ledger while operational systems continue to run the business and synchronise with it. Writing all operational data to a public chain is expensive and rarely necessary.
One pattern that works well: the ledger stores a hash of a record, the identity of the participant that signed it and a timestamp. The record itself stays in the systems that need to use it. Verification is possible for anyone entitled to check, without publishing commercial data.
For a device provenance network that might mean serialised asset identifiers, custody transfer events and grading attestations recorded as signed proofs, while inventory, pricing and logistics data stay inside each participant's own systems.
Achieving integrity without a ledger
Most programmes described as needing blockchain actually need these, in this order.
Append-only event history. Every state change is an event with actor, timestamp and reason. Nothing is overwritten.
Hash chaining. Each record includes a hash of the previous one, so tampering breaks the chain detectably.
Signed records. Device, service or user keys sign important events, so authorship is provable.
Reconciliation. Participants compare records on a schedule and resolve differences through a defined process.
External anchor. Periodically publish a hash of the current state somewhere independent. It is cheap and provides tamper evidence without operating a network.
Together these give most enterprises the auditability they actually need, at a fraction of the operational burden.
When a hybrid design is right
Where the multi-party requirement is real but full decentralisation is not, a permissioned ledger among known participants is often the pragmatic middle. Participation is governed by contract, identity is verified at onboarding and consensus is limited to the parties that matter.
The design questions then shift from technology to governance: who admits new participants, who may upgrade the contracts, what happens when a participant leaves, who pays for operation and how the network is wound down if the operator exits.
What to ask before committing
What exactly must be verifiable? By whom? Who is entitled to write to the record, and who may read it? What does it cost per year to operate? What happens when the network changes hands or the vendor disappears?
Add four practical questions. Can you name the organisations that must rely on the record, and have they agreed to participate? What is the per-transaction cost at expected volume? Which data can be shared and which cannot, and does the design keep it private by default? And if the ledger were replaced tomorrow by a conventional database with audit logging, which specific guarantee would be lost?
If those questions cannot be answered plainly, the requirement is not yet a trust requirement. It is a technology preference, and it should be treated as one.
How Sardo Group can help
We design and build the systems around these decisions: platform architecture, API integration between participants and ecosystem platforms where multiple organisations transact on shared records.
Where a ledger is justified we scope it narrowly, with proofs and events recorded on chain and business logic kept in systems that can change at commercial speed. Where it is not, we say so, and design the auditability, entitlements and reconciliation that deliver the actual guarantee.
Start a project to discuss a specific requirement.
Frequently asked questions
When is blockchain genuinely necessary?
When multiple independent organisations must rely on the same record, no single party should be able to alter it, and the participants do not accept one party's database as authoritative. All three conditions must hold together.
Can a conventional database be auditable?
Yes. Append-only event history, hash chaining, signed records and periodic reconciliation provide strong tamper evidence without operating a distributed network.
Is a permissioned ledger a real blockchain?
It uses distributed ledger technology with restricted participation. It is decentralised among known parties rather than open to anyone, which suits most commercial networks.
How much does a ledger cost to operate?
It varies with network choice and volume. The reliable answer comes from modelling node or fee costs, governance overhead, specialist skills and upgrade effort against the value of the specific guarantee.
Does Sardo Group build blockchain systems?
Yes, where the trust requirement justifies one. We also build conventional auditable architecture where it does not, alongside the integration work that connects participants.