Consensus - c8ntinuum Docs

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

Concept	Meaning	Typical use
Protocol finality	A 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 confirmations	A 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

Area	Effect
Finality	Transactions are final after one committed block under standard CometBFT assumptions.
Expected block time	`4s`
Reorganizations	Application logic should not expect Ethereum-style probabilistic reorg handling.
Validators	Native staking and validator state are exposed through Cosmos modules and selected precompiles.
JSON-RPC	Mining-related Ethereum RPC methods return compatibility values rather than proof-of-work state.
Indexing	Indexers 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.