Skip to content

LibraryConsensus2014Design paperCorpus record

Tendermint: Consensus without Mining

Tendermint. Jae Kwon.

A practical Byzantine-fault-tolerant state machine for a known validator set, with instant finality on commit. It became the consensus engine under Cosmos SDK chains. The 2014 note is the origin, not the current CometBFT specification.

Tendermint runs a round of propose, prevote and precommit among a known weighted set. If more than two thirds prevote and precommit the same block, the block is final. It does not get unfinalised by a longer fork.

The five-minute read

The validator set is known

This is a Byzantine protocol for a named set with voting power. It is not a protocol that discovers its peers from proof of work. Membership changes are themselves a protocol step.

Two rounds of voting, not one

A prevote says the block is acceptable. A precommit says the voter is ready to commit. Splitting them is how the protocol avoids locking onto a value the rest of the set will abandon.

Two thirds plus one is the quorum

Safety needs more than two thirds of the voting power to be honest. A smaller quorum would let two quorums decide two blocks. The fraction is the design.

Finality means final

Once a block is committed, a later round does not reorg it. An application can act on the block. The cost of that promise is that the chain halts if the quorum goes offline.

The paper is the consensus core

Cosmos, the application framework, and interchain packets came around this core. Tendermint does not by itself move a token from one chain to another.

One action, walked through

  1. A proposer for the round broadcasts a block.
  2. Validators broadcast prevotes for that block, or for nil if the proposal is missing or invalid.
  3. Each validator waits until it has seen prevotes from more than two thirds of the power.
  4. It then broadcasts a precommit. If more than two thirds precommit the same block, the node commits and moves to the next height.
  5. If the round fails, the protocol moves to a new round with a new proposer, under timeout rules that the paper specifies.

The argument, unpacked

Safety and liveness are traded in public

A chain that never reorgs must sometimes stop. Tendermint chooses that trade and writes it down. A product page that promises both instant finality and progress through arbitrary partitions is promising two protocols.

Nil votes are doing real work

A validator who prevotes nil is not abstaining out of politeness. Nil is how a round is allowed to end when the proposer failed. Removing nil, or treating silence as a yes, breaks the round structure.

Accountability is the forensic claim

If two quorums ever commit two blocks, a large set of validators must have signed both. The paper treats those signatures as evidence. That only matters if the application has a political or legal place to take the evidence. The protocol does not punish by itself.

What has to be true

  • Voting power is delegated to a set small enough to gossip votes. A million equal voters is outside the design.
  • More than two thirds of the power is honest and can talk to each other within the timeouts.
  • Clocks are roughly synchronised for round timeouts. Safety does not depend on clocks. Liveness does.
  • The application defining validity is deterministic. A non-deterministic check splits the set.

What happened after the paper

CometBFT and the Cosmos stack carried this core into production, with evidence handling, light clients and later proposer-based timestamps. Those are descendants. The 2014 paper is still the clean statement of the three-phase round and the two-thirds quorum.

What to check before you use the idea

  • How many validators are in the set, and how is voting power distributed among them?
  • Does the application wait for a commit, or for a block that can still be reorged?
  • What is the timeout path when the proposer is silent?
  • Where does double-sign evidence go, and does anything happen to the signer?

Terms

Prevote
A signed statement that a proposed block is acceptable, before the validator locks in.
Precommit
A signed statement that the validator will commit the block if a quorum agrees.
Commit
The point at which more than two thirds have precommitted one block. The block is final.
Voting power
The weight of a validator. Quorums are measured in power, not in headcount.

The problem the paper names

Proof-of-work chains confirm by depth. Application builders still have to decide how many blocks is 'enough', and reorgs remain possible. Tendermint treats a block that received a supermajority of precommits as final.

What the design proposes

  • Validators are known for the round. Voting weight is assigned, not discovered by hashing.
  • Rounds move through proposal, prevote and precommit. A lock rule stops a validator equivocating across values.
  • Accountability: if safety breaks, evidence of double-signing can be shown.

How the mechanism is specified

  • The protocol assumes partial synchrony for liveness and a bound on faulty voting power for safety.
  • Applications sit above the engine. They do not invent their own fork choice.
  • Membership changes are a protocol concern of their own. The note does not make an open set of anonymous miners.

What this page does not treat as proven

  • A named validator set is a governance object. The paper does not tell a venture who should hold the keys.
  • Cosmos zones, IBC and the SDK are later. See the Cosmos paper for the network-of-ledgers claim.
  • Finality is only as good as the assumption that less than one third of voting power equivocates.

Why a venture studio still reads it

This is the right reference when a consortium or a zone needs a final vote rather than a probabilistic chain. It is the wrong reference if the venture cannot name who is allowed to sign.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.