c8ntinuum uses CometBFT-style Byzantine fault tolerant consensus. Blocks become final after validator agreement rather than waiting through probabilistic proof-of-work confirmations. The expected block time is 4s.

​
Protocol finality vs operational confirmations

ConceptMeaningTypical use
Protocol finalityA committed block is final after one block under standard CometBFT assumptions.Smart contracts, wallets, and normal dapp UX can treat included transactions as final.
Operational confirmationsA business policy that waits additional blocks even after protocol finality.Exchanges and custodians may wait 60 confirmations to absorb scanner lag, provider delay, and operational risk.
Both statements can be true: the protocol provides one-block finality, while high-value business workflows may choose a larger confirmation policy.

​
Developer-facing effects

AreaEffect
FinalityTransactions are final after one committed block under standard CometBFT assumptions.
Expected block time4s
ReorganizationsApplication logic should not expect Ethereum-style probabilistic reorg handling.
ValidatorsNative staking and validator state are exposed through Cosmos modules and selected precompiles.
JSON-RPCMining-related Ethereum RPC methods return compatibility values rather than proof-of-work state.
IndexingIndexers should still use cursors, receipt checks, and retry logic because infrastructure can lag even when consensus has finalized.

​
Failure model

CometBFT finality assumes less than one-third Byzantine voting power and a network that can eventually make progress. The Learn pages describe developer-facing behavior, not validator operations or incident handling. Operator procedures belong in Node Operations.