The distributed ledger
How a blockchain makes transactions binding — and what kind of binding that actually is.
This lesson has had no expert review. It was written for this platform and against the evidence it cites; nobody has gone through it independently.
Learning objectives
- You can explain what finality means and why it is not immediate.
- You can explain why “immutable” does not mean “correct”.
Check your prior knowledge
Answer these for yourself before reading on. Wherever you hesitate is where this lesson pays off.
- What is a ledger?
- Who maintains it in the traditional system?
- What happens with a mistaken entry?
Core concept
A ledger many parties keep at once
A blockchain is a ledger kept not by one party but by many at once — parties that agree on each next entry by a fixed rule. Every block carries a reference to its predecessor; changing something further back would invalidate every reference that follows.
Finality is a degree, not a state
A just-confirmed transaction is not yet final. With each further block, a later change becomes more expensive and less likely. Some networks define a point beyond which a change is economically ruled out; others merely make it ever less likely. For settlement, that point is precisely the figure that matters.
Immutable does not mean correct
A blockchain guarantees that an entry is not changed after finality. It does not guarantee the entry was correct. A transfer to the wrong address is just as final as one to the right address. The property regarded as a security feature is, in the event of a mistake, the opposite of one.
Definitions
- Finality
- The point beyond which a confirmed transaction can practically no longer be reversed.
- Gas
- The fee for the computation a transaction consumes on the network.
- Blockchain in the glossary
- A distributed, continuously chained ledger of transactions.
Model
Transaction signed and sent to the network
Accepted into the mempool — not yet part of the ledger
Included in a block — confirmed, but not final
k further blocks on top — practically final
Worked example
When has a payment arrived?
- Transaction confirmed in block
- n
- Recipient's assumption
- arrived immediately
- Actual finality
- n + k
Between block n and block n + k there is a window in which the transaction looks confirmed but could still be displaced. The size of k is a property of the network, not a choice by the recipient.
The payment has arrived only after k further blocks.
Reading: Anyone releasing goods against a payment needs to know k. “Confirmed” in an interface is no statement about finality.
Retrieval
Exercise on real data
Look at how many chains this platform's markets spread across. Note: the same brand on two chains is technically the same product twice, with two different infrastructure risks.
Compare chains in the Explorer →Application
A payment process is to settle on-chain. Which two network properties determine when goods may be released?
Related case studies
Institutional reading
- Bank
- How does the network's finality rule relate to the institution's own definition of settlement finality?
Key takeaways
- Finality is not immediate and is a property of the network, not a setting.
- Immutable does not mean correct — a mistake is just as final as a correct entry.