Crypto & Blockchain Foundations

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

Proof-of-work, proof-of-stake and other systems distribute authority differently. They change who can propose or finalize state, the cost of attacking history and the failure modes around censorship or liveness. A security review should name those assumptions rather than hide them behind the word decentralized.

This concept matters because Different consensus systems fail differently.

Consensus distributes the ability to extend or finalize history but each design concentrates different failure modes.

Identify validator/miner concentration, liveness assumptions and bridge dependencies.

At protocol and execution level, inspect safety and liveness and censorship and economic security and centralization. Protocol identifiers remain untranslated because they are part of the technical payload.

Application teams often inherit consensus assumptions without documenting how censorship, reorg or halted finality affects the workflow.

The practical consequence is that Economic security and application security are separate layers. Unknown is not equivalent to safe.

• generic 'decentralized' claim
• no adversary model
• ignoring validator/miner concentration
• assuming liveness under every partition
• same finality policy across all chains

Require an explicit operating assumption for finality and liveness before treating the chain as a trusted dependency.

The practical consequence is that Economic security and application security are separate layers.

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

Verify the request through independent evidence before irreversible authorization.

1. 01

   name consensus actors

2. 02

   identify safety/liveness assumptions

3. 03

   identify attack/economic threshold

4. 04

   inspect concentration dependencies

5. 05

   set workflow-specific finality requirement