Most consensus protocols you've seen (Raft, Paxos) assume nodes fail by crashing, not by lying. Most Byzantine protocols you've seen (PBFT, HotStuff) assume a fixed validator set. Tendermint sits in an interesting spot: BFT-safe against liars, tolerant of validator set changes between blocks, and — critically — offers instant finality. Once a block commits, it's irreversible. No probabilistic waiting like Bitcoin's "wait 6 confirmations."

The protocol runs in rounds, each with three steps:

• Propose: A designated proposer (round-robin, weighted by stake) broadcasts a block.
• Prevote: Every validator broadcasts a prevote for that block (or nil if invalid/missing).
• Precommit: If a validator sees 2/3+ prevotes for a block (a "polka"), it broadcasts a precommit.

If 2/3+ precommits arrive for the same block, it's committed. If the round times out (no polka, no 2/3+ precommits), the next round starts with a new proposer.

Why two voting rounds? The prevote step ensures validators agree on what they saw before locking. Precommits enforce a rule: once you precommit a block in round R, you can only precommit a different block in round R+1 if you see a polka for it in round R+1. This "locking" is what prevents a Byzantine proposer from committing two different blocks in the same height — the classic safety violation.

Real-world example: The Cosmos Hub runs Tendermint with ~180 validators. When you send tokens, the transaction lands in a block, and within ~6 seconds you have final confirmation — the block cannot be reverted without at least 1/3 of stake being slashed for double-signing. Compare this to Ethereum's ~13 minutes to reasonable finality, or Bitcoin's ~60 minutes.

Rule of thumb for Byzantine tolerance: Tendermint tolerates f Byzantine validators where 3f + 1 ≤ N. So 100 validators tolerate 33 liars; 4 validators tolerate 1. If more than 1/3 collude, safety breaks — but they'll be provably guilty (their signed conflicting votes are evidence for slashing).

The tradeoff you're buying: Instant finality costs liveness under partition. If more than 1/3 of validators are unreachable, the chain halts entirely — no new blocks until connectivity returns. Ethereum keeps producing blocks during partitions (and reconciles later); Tendermint refuses to progress if it can't guarantee safety. This is a deliberate CAP choice: CP over AP. For a financial ledger where "we committed then reverted" is catastrophic, halting is the correct failure mode.

Tendermint's other lasting contribution: the ABCI interface, which cleanly separates consensus (the Tendermint engine) from application logic (your state machine). You write your app in any language, and Tendermint handles all the Byzantine agreement plumbing.