State is the thing being agreed on

A blockchain is not a magic database. Nodes apply rules to proposed state transitions and converge on a history according to a consensus mechanism. Security analysis starts by asking which state is authoritative, which assumptions establish it, and how much reorganisation risk remains.

This concept matters because Consensus chooses an accepted history; it does not make every application safe.

Consensus determines which history is accepted, while finality policy determines when your operation treats that history as settled.

Start with chain, confirmations and value at risk.

At protocol and execution level, inspect state and transition and consensus and reorg and finality. Protocol identifiers remain untranslated because they are part of the technical payload.

A valid transaction can still be operationally premature if reorg tolerance and treasury policy disagree.

The practical consequence is that Finality is a spectrum whose meaning depends on the chain and threat model. Unknown is not equivalent to safe.

• treating inclusion as absolute finality
• ignoring reorg assumptions
• confusing consensus security with app safety
• wrong confirmation threshold
• no chain-specific finality model

Escalate when confirmation depth is below the value-specific settlement policy.

The practical consequence is that Finality is a spectrum whose meaning depends on the chain and threat model.

Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.

Verify the request through independent evidence before irreversible authorization.

1. 01

   identify consensus mechanism

2. 02

   define confirmation/finality criterion

3. 03

   measure reorg exposure

4. 04

   separate protocol validity from economic intent

5. 05

   document settlement assumption