Blockchain & DLT – Fundamentals

"Do we need a blockchain for this?" is usually asked as a technical question, and it is not one. It is settled by three questions that come before any architecture sketch: who may write, who may read, and who is right when two parties disagree?

Sharing reads is easy; sharing writes is the problem

Companies have been able to share data with business partners for decades. Interfaces, portals, file exchange — none of that requires a new kind of database. It only becomes demanding when several parties write, and none of them is willing to accept another party's records as authoritative.

That is exactly the domain of distributed ledger technology (DLT). A classic database has an operator, and that operator holds the truth; anyone who does not trust them keeps their own copy and reconciles regularly. A distributed ledger replaces that reconciliation with a shared state that all participants see at the same time and that none of them can change alone.

An example from the supply chain makes the difference tangible. A machinery manufacturer, its castings supplier and a testing laboratory exchange quality certificates for safety-relevant parts. All three need the same evidence, all three carry different liability, and none wants one of the others' databases to be decisive in a dispute. Today this is solved with three separate systems plus coordination by email. That is the shape a shared ledger was built for.

When a database is enough — which is most of the time

The honest counter-check belongs here, because it ends most initiatives before they cost money. If there is a natural operator that all parties follow anyway — the group ERP, the bank, the marketplace — then a distributed ledger is the more expensive solution with no additional benefit.

Three conditions have to coincide before the effort is even arguable: several parties write, there is no operator everyone accepts, and the shared state has to be demonstrable to third parties as well — auditors, authorities, courts. If one of them is missing, the answer is a database with clean interfaces.

Once a payment enters the picture, the frame shifts again. As soon as event and payment are meant to form one transaction — goods handed over and money moved, with no step in between — the money has to sit on the same infrastructure. That is why the discussion regularly travels from the data question to the money question and arrives at stablecoins or tokenised deposits.

Public or permissioned: the question of the doorkeeper

Once a shared ledger is decided, the actual architecture question follows. In a public network anyone can read, write and enforce the rules; nobody grants admission. In a permissioned network the circle is known and contractually bound, admission is granted and can be withdrawn.

Institutions studying payments and settlement work predominantly on the second model. The analytical framework of the Committee on Payments and Market Infrastructures at the BIS says so explicitly: it is directed primarily at arrangements involving restricted ledgers, that is, ledgers access to which is for approved users only. The Eurosystem's exploratory work on settling DLT transactions in central bank money followed the same line — it ran from May to November 2024 with 64 participants and more than 50 trials, and tested three ways of connecting DLT platforms to existing infrastructure rather than replacing it.

The counter-argument is just as real: reach exists where nobody has to ask for admission. A company sending a euro stablecoin to a counterparty in Asia will find that counterparty on a public network, not inside its own consortium. A permissioned network buys control at the price of network effect — and a public one buys reach at the price of rules it does not set.

What belongs on the ledger and what belongs beside it

This decision is often taken too late, and it is harder to correct than the previous one. Immutability is the core of the benefit — until personal data sits in the ledger. Then it stands against the obligation to be able to delete, and that conflict cannot be resolved after the fact: whatever is in a distributed ledger sits with every participant.

The usual way out is a clean separation. Only a fingerprint of the document, with its timestamp, goes onto the ledger; the content stays in your own system. Proof still works exactly as before — you can show at any time that a particular document existed at a particular moment — without the document itself leaving the building. That is sufficient for the audit trail, and it is sufficient for deletion duties too.

The second, less considered point concerns commercial confidentiality. On a public network, amounts, times and counter-addresses are visible to everyone. Addresses carry no names, but they carry a pattern: a company that pays the same five addresses at every month-end publishes the outline of its supplier structure. That is not a reason to rule it out, but it is a trade-off to settle before the first production run.

What the decision really rests on

From a finance perspective, the costs of both routes are easy to grasp: connection, operation, auditability. The risks sit deeper and are unevenly distributed. A permissioned network makes the company dependent on a consortium and its rules — on membership terms, voting rights, and on whether the consortium still exists in five years. A public network makes it dependent on rules nobody in-house influences: fees move with demand, and technical changes arrive without contract negotiations.

Soberly viewed, the architecture therefore follows a single question: who is right when two parties hold different numbers? Anyone with a solid answer to that has already decided the architecture — everything else is implementation.

What follows from this

The choice between a database, a permissioned ledger and a public one is not a matter of belief, nor of being modern. It is the translation of a trust and liability situation into technology, and it comes out differently for every use case: quality certificates in a supply chain land on different answers than a cross-border supplier payment.

How a single transaction technically runs through such a ledger — signature, broadcast, block, confirmation — is covered in How Does a Blockchain Work?. Who has the right to write the next entry in a network, and what that agreement costs in energy, capital or contract, is the subject of Consensus Mechanisms.

The question that saves an initiative the most time therefore sits right at the beginning, not at the end: is there really nobody in this process to whom all parties would concede authority over the data?