From Transactions to Finality

1. The problem: shared history without a central authority

In any digital system, history is an ordered record of events.

In centralized systems, a single authority decides the order and publishes it. In decentralized blockchains, no such authority exists.

Each participant observes the network from a different vantage point. Messages arrive at different times. Some nodes are faster, some are slower, some are temporarily offline. Transactions are created independently by users who do not trust one another.

The system must still converge on a single shared history that everyone agrees on. The core difficulty is not creating transactions, but deciding which transactions happened first, which are valid, and which are permanently part of history without trusting any single party.

This is the ordering problem. Everything that follows—blocks, confirmations, and finality—exists to solve it.

2. From intent to transaction

At the system level, a transaction is a signed intent to change shared state, not a button click or wallet action.

A transaction contains a description of the intended state transition, a cryptographic signature proving authorisation, a nonce or sequence marker to prevent replay, and a fee or gas parameter expressing willingness to pay for inclusion.

The signature binds the transaction to a specific identity or key. The nonce ensures that transactions from the same origin are processed in a defined order and only once. The fee expresses priority under congestion, aligning incentives between transaction senders and block producers.

A transaction is not part of history when it is created. It is only a proposal. Until the network agrees to include it, it has no effect on shared state and exists only as a data object outside consensus.

3. Propagation: how transactions reach the network

Once created, a transaction must be communicated to other participants. This happens over a peer-to-peer network using gossip-style propagation.

Each node maintains a mempool: a local collection of transactions it has seen but that are not yet included in a block. There is no global mempool. Every node’s view is slightly different, shaped by network latency, connectivity, and policy choices.

Propagation follows a simple rule: when a node receives a new transaction, it verifies basic validity and forwards it to peers. Over time, the transaction spreads through the network.

This process is intentionally redundant and probabilistic. No guarantee exists that all nodes see all transactions at the same time. The system tolerates this inconsistency because agreement does not happen at the mempool level. The mempool is a staging area, not history.

4. Validation vs execution

A crucial distinction exists between validation and execution, and confusing them leads to misunderstanding how blockchains work.

Validation answers the question: is this transaction well-formed and permissible to attempt? It includes checks such as correct signature, proper nonce, sufficient balance to cover fees, and adherence to protocol rules. Validation is relatively cheap and can be done before inclusion.

Execution answers a different question: what state changes result if this transaction is applied in a specific order? Execution depends on the current state, the ordering of transactions, and the effects of prior transactions. The same transaction can succeed or fail depending on what comes before it.

Nodes can validate transactions independently, but execution must be deterministic and agreed upon. Ordering is the bridge between validation and execution.

5. Ordering: how transactions become a block

A block is a proposed ordering of transactions.

Block producers, or validators, select transactions from their mempool, choose an order, and assemble them into a block candidate. The ordering is shaped by dependency constraints such as nonces and state access, fee incentives, protocol rules, and sometimes strategic behaviour such as MEV at a high level.

The block producer is economically incentivised to construct blocks that are valid, profitable, and likely to be accepted by the network. Invalid blocks are rejected. Uncompetitive blocks may be ignored.

This is the first moment where transactions stop being independent. By placing them into a block, the producer asserts an ordering in which these transactions should be applied to state. The block is still only a proposal; agreement has not yet been reached.

6. Inclusion and confirmations

When a block is accepted by the network and built upon, the transactions inside it receive confirmations.

A confirmation means that this block is now part of the best-known chain. Each additional block layered on top makes it increasingly costly to replace.

Confirmations are probabilistic. Multiple block producers may propose competing blocks at similar times, so temporary forks can occur. Some blocks are eventually abandoned in favour of others, and transactions in those blocks may return to the mempool or be dropped.

A reorganisation, or reorg, is the network revising its recent history to reflect a more favoured ordering. Confirmations measure depth, not permanence, and reflect increasing confidence rather than absolute finality.

7. Finality: when history stops changing

Finality answers the question of when history becomes effectively irreversible.

Probabilistic finality describes systems where history becomes safer the deeper it is buried but never strictly immutable. Reversal becomes exponentially unlikely as more blocks accumulate.

Economic finality relies on mechanisms such as slashing, where reversing finalised history would require economic penalties large enough to outweigh any benefit, making certain reorgs irrational beyond a point.

Cryptographic finality uses explicit consensus votes to mathematically finalise blocks. Once finalised, they cannot be reverted without breaking underlying cryptographic assumptions.

Finality exists because applications and systems need a clear point after which history can be treated as settled. Confirmations approximate safety; finality defines it.

8. Why reorgs do not mean blockchains are broken

Reorganisations are not failures. They are a natural consequence of decentralisation, network latency, and parallel block production.

The system allows temporary disagreement so that it can function without coordination bottlenecks. Reorgs are the cost of openness and liveness.

What matters is that reorgs are limited in depth, become increasingly unlikely over time, and are constrained by economic and cryptographic rules.

A blockchain that never reorganises would either be centralised or stalled. Controlled reorgs are a feature, not a flaw.

9. The full lifecycle as a mental model

A transaction begins as a signed intent, created independently and without permission.

It propagates through a peer-to-peer network, living temporarily in mempools with no global agreement.

Nodes validate it structurally, but it has no effect until ordered.

A block producer selects it, orders it with others, and proposes a block.

The network compares competing proposals and extends one history.

As blocks accumulate, confidence increases through confirmations.

Eventually, consensus mechanisms impose finality, making reversal impractical or impossible.

At that point, the transaction is no longer a proposal or even a recent event. It is part of shared, effectively irreversible history.

Decentralised systems turn untrusted actions into a single agreed past not by preventing disagreement, but by carefully constraining how disagreement resolves over time.