Jae Kwon's Tendermint (whitepaper 2014, formalized further by Buchman, Kwon & Milosevic) takes a design stance that's worth contrasting directly with HotStuff (6.3): rather than optimizing communication complexity as the primary goal, Tendermint's central design commitment is immediate, deterministic finality — once a block commits, it is final, full stop, with no probabilistic "wait for more confirmations" period of the kind proof-of-work blockchains require. This article covers Tendermint's round-based propose/prevote/precommit structure, how it achieves this finality guarantee, its accountability mechanism (slashing) for punishing provable misbehavior, and the Cosmos SDK ecosystem it underlies — closing in on this phase's throughput-focused finale with Narwhal/Bullshark next.
Immediate finality: the design commitment that shapes everything else
Worth pausing on why this specific guarantee matters enough to organize a whole protocol around. Proof-of-work blockchains (Bitcoin's original design, most notably) don't have a moment where a transaction is "final" in the deterministic sense this series has used throughout (article 3.2's "committed" — majority-replicated, never rolled back). Instead, confidence in a PoW transaction's permanence grows probabilistically as more blocks are mined on top of it — "6 confirmations" is a convention, not a proof, and a sufficiently powerful attacker can, in principle, still reorganize even a well-confirmed chain, just at increasing and eventually prohibitive cost. Tendermint, building on the classical BFT lineage this whole phase has traced (Byzantine Generals through PBFT and HotStuff), instead gives you article 3.2's exact, familiar guarantee: once a block is committed by a quorum, it is committed, permanently, with the same absolute (not probabilistic) safety guarantee every algorithm since Phase 5 has provided.
Round-based consensus: propose, prevote, precommit
Tendermint organizes each block's consensus into a sequence of rounds, each with a designated proposer (rotating deterministically through the validator set, weighted by stake in the typical proof-of-stake deployment — a detail distinct from anything in Phase 5's crash-fault algorithms, where leader selection wasn't tied to any economic stake). Each round has three steps:
- Propose — the round's designated proposer broadcasts a candidate block.
- Prevote — every validator broadcasts a signed prevote for the proposed block (or a special "nil" prevote if the proposal is invalid, missing, or the validator's timeout expires first). If a validator collects prevotes from more than two-thirds of voting power for the same block, that block has a Polka — Tendermint's own term for this specific quorum threshold.
- Precommit — upon seeing a Polka, validators broadcast a signed precommit for that block. If more than two-thirds of voting power precommits the same block, the block commits, immediately and finally — no further rounds, no probabilistic wait.
If a round fails to reach a Polka or a commit (proposer was faulty, network hiccup, insufficient votes within the round's timeout), validators move to the next round with a new proposer — directly analogous to Phase 5's leader-timeout-and-retry pattern (article 4.2, 5.5), just explicitly organized as numbered rounds within the process of finalizing one specific block, rather than open-ended terms spanning an entire log.
Fig 1 — Two consecutive two-thirds thresholds (Polka, then commit) inside one round give Tendermint's immediate finality.
2N/3) guarantees the quorum includes strictly more than 2f honest participants — enough that two different two-thirds quorums, at the same round, provably cannot both certify different, conflicting blocks (the same overlap-based safety logic as articles 3.3 and 6.1-6.3, expressed in Tendermint's specific fractional-threshold framing rather than an explicit node count).Accountability: slashing for provable misbehavior
Tendermint's proof-of-stake deployment context (most prominently the Cosmos ecosystem) adds a mechanism with no real analog in Phase 5's crash-fault or even 6.1-6.3's abstract Byzantine setting: because every prevote and precommit is individually signed, a validator that signs two conflicting votes for the same round and height (evidence of exactly the kind of active misbehavior article 6.1 modeled) produces cryptographic, publicly verifiable evidence of that misbehavior. This evidence can be submitted on-chain, triggering slashing — an automatic, protocol-enforced penalty that destroys a portion of the offending validator's staked economic collateral. This is a genuinely novel addition beyond the pure distributed-systems mechanism this series has focused on: it's an economic incentive layer bolted onto the cryptographic/algorithmic safety guarantee, making Byzantine misbehavior not just theoretically detectable but economically punished, directly disincentivizing exactly the adversarial behavior article 6.1's failure model assumes participants might attempt.
The Cosmos SDK ecosystem
Tendermint Core (now maintained under the CometBFT name following a project fork) is the consensus engine underlying the Cosmos SDK, a framework for building independent, purpose-built blockchains ("application-specific blockchains," in Cosmos's own framing) that each run their own Tendermint-based validator set while interoperating via the separate Inter-Blockchain Communication (IBC) protocol. This architecture — many independent chains, each with its own Tendermint consensus instance, rather than one single monolithic chain — is a direct, large-scale illustration of this series' recurring theme (most explicitly from article 3.1 onward): the consensus/replication layer is a reusable, swappable component that different applications can build on independently, the same separation-of-concerns argument made for Raft's etcd usage (Phase 8.1) and Multi-Paxos's various deployments, just at blockchain-ecosystem scale.
FAQ
Does immediate finality mean Tendermint chains can never experience a chain reorganization?
Correct, under Tendermint's own liveness assumptions (enough honest voting power actively participating) — this is precisely the trade Tendermint makes against probabilistic-finality chains: no reorgs of committed blocks, ever, as long as the Byzantine-fault assumption (fewer than a third of voting power malicious) holds. If that assumption is violated (more than a third of stake is malicious or offline), the chain can halt (a liveness failure, per article 4.1) rather than silently producing an unsafe reorg — safety is preserved even in that worst case, exactly the priority ordering article 4.1 established.
Is slashing a consensus-safety mechanism or something separate?
Something separate, layered on top — the underlying Tendermint consensus algorithm's safety proof (the two-thirds-threshold argument above) holds regardless of whether slashing exists; slashing is an economic deterrent that makes actually attempting a Byzantine attack costly, reducing the real-world likelihood of ever needing the safety guarantee to be tested against a genuinely malicious quorum fraction.
How does Tendermint's round-based structure compare to HotStuff's chained blocks?
Tendermint finalizes each block within its own bounded sequence of rounds before moving to the next block height; HotStuff pipelines the three-chain commit rule (article 6.3) across consecutive blocks continuously, without each block needing its own fully separate round structure. Both achieve BFT safety at the same 3f+1 bound; the difference is in how finality is structured across the sequence of blocks, a genuine design trade-off rather than one being strictly better.
Why did the project rename from Tendermint Core to CometBFT?
A 2023 organizational fork/rename within the Cosmos ecosystem's tooling — CometBFT is the actively maintained continuation of the original Tendermint Core codebase; the underlying consensus algorithm and its guarantees, as described in this article, are unchanged by the rename.
Takeaways
- Tendermint's central design commitment is immediate, deterministic finality — a direct contrast with probabilistic-finality proof-of-work chains, giving article 3.2's exact "committed means permanent" guarantee.
- Each round: Propose → Prevote (Polka at >2/3) → Precommit (>2/3 = commit) — two consecutive supermajority thresholds within one round produce immediate finality.
- The >2/3 threshold connects directly to article 6.1's 3f+1 bound — guaranteed to include enough honest participants that two conflicting quorums at the same round-height are provably impossible.
- Slashing adds an economic accountability layer beyond pure algorithmic safety — cryptographic evidence of double-signing triggers automatic, protocol-enforced stake destruction, a genuinely novel addition in the proof-of-stake context.
- Tendermint (now CometBFT) underlies the Cosmos SDK ecosystem of independent, interoperating application-specific blockchains — a large-scale instance of consensus-as-a-reusable-component, this series' recurring theme since article 3.1.
References & further reading
- Buchman, Kwon & Milosevic — The Latest Gossip on BFT Consensus (Tendermint, 2018) — the primary formal reference.
- CometBFT documentation — the actively maintained continuation of Tendermint Core.
- cvam.sight — Consensus 6.1: The Byzantine Generals Problem — the 3f+1 bound underlying Tendermint's two-thirds threshold.
- cvam.sight — Consensus 6.3: HotStuff — the contrasting communication-efficiency-first design philosophy.