How Does a Blockchain Work?

A payment across a blockchain passes through five stations, and exactly one of them decides what accounting can do with it. This article walks the route once — from the key pair to the question of when an incoming payment can be relied upon.

A key pair is not an account number

At the start there is no account, only a pair of numbers. The private key stays with its holder; the public one becomes the address that payments arrive at. Whoever holds the private key can dispose of the funds — no further check happens at this level. There is no bank comparing a signature against a specimen, and no office that can pull a transfer back.

For a company, that shifts a familiar boundary. Authority to pay no longer rests on a mandate someone grants and revokes, but on where a key is kept. Which is precisely why companies rebuild the usual controls one level up: several keys for one approval (multi-signature), key shares held separately (MPC), hardware a key cannot be read out of (HSM), and pre-approved recipient lists (whitelists). The four-eyes principle does not disappear — it moves from the form into the technology.

What a transaction actually contains

A transaction is a short, signed record: sender address, recipient address, amount, a fee for being picked up by the network, and the signature covering all of it. What it does not contain matters more to accounting than what it does. There is no payment reference in the sense of a bank transfer, no name, no invoice number.

Those references therefore have to travel alongside — in the ERP, in the payment file, on the document. Anyone hoping to match an incoming payment to an open item purely from the chain will find an address, an amount and a timestamp. That is enough for reconciliation only if the address is unambiguously tied to a counterparty. In practice this is where the effort sits: not in the technology, but in master data.

The route from sending to a block

Once the transaction is signed and sent, a short and always identical sequence follows. Knowing it explains most of the questions that come up in daily operations — why a payment appears to be stuck, why fees fluctuate, why an amount shows up in the wallet before it should be posted.

1. Broadcast. The signed transaction goes to the network's nodes, which check its validity — signature correct, funds available — and pass it on.
2. Wait. It sits in the network's waiting area. Whoever offers a higher fee is picked up sooner; under load, waiting gets more expensive rather than more orderly.
3. Include. A participant bundles transactions into a block and appends it to the existing chain. Every block carries the fingerprint of its predecessor — which is why an old entry cannot be altered without altering every later one too.
4. Confirm. With every further block built on top, reversal becomes less likely. These are called confirmations, not postings.
5. Inspect. Through a block explorer the whole event is visible to anyone: amount, addresses, time, number of confirmations.

Step four is where expectation and reality usually part company.

Confirmed is not the same as final

In an open network, the finality of a payment is not a promise but a probability. The Bank for International Settlements put it plainly: the probability that a payment is final rises with each further block — but it never reaches one hundred per cent. Anyone arriving from conventional payments, where a credit either exists or does not, finds a gradient here instead of an edge.

In practice this means a company sets its own threshold. A machinery manufacturer receiving a 40,000 euro down payment in a stablecoin can define that the payment counts as received from a certain number of confirmations onwards — and that goods leave the plant only after that. This threshold is a business decision, not a technical one: it weighs waiting time against residual risk, and it may reasonably differ between a small payment and a down payment. What matters is that it exists at all and that it is written down.

This should not be confused with legal finality — the point at which a payment discharges the debt. That question is answered by the contract with the counterparty, not by the network.

What reaches the CFO

Three things change compared with a bank transfer, and all three are process questions rather than technical ones. First, an executed payment cannot be recalled: there is no recall and no request to a bank to reverse it, which is why verifying the recipient belongs before approval, not after. Second, the network fee introduces a small, fluctuating cost type that wants to be posted and visible on a cost centre. Third, the moment of recognition shifts: the amount appears in the wallet before the internal threshold is met, so accounting needs a rule on which point in time counts.

The biggest risk in this picture is not an attack on the blockchain. It is the typo in a recipient address and the key only one person knows. Both are internal control topics, and a company can address them with means it already has: approvals, segregation of duties, documented emergency procedures.

What follows from this

The technical process of a blockchain is simpler than its vocabulary suggests: sign, broadcast, bundle, stack. It gets demanding at the edges — where keys are kept, addresses are assigned and thresholds are set.

Which architecture is the right one for a given use case at all — open network, permissioned network, or simply a database — is a separate question, covered in Blockchain & DLT – Fundamentals. How participants agree on the next block, and what that agreement costs, is the subject of Consensus Mechanisms.

The more useful question after this walk-through is therefore not how a blockchain works. It is from which confirmation onwards your own organisation wants to treat a payment as received — and who gets to set that number.