Tendermint: Byzantine Fault-Tolerant Consensus

• Tendermint is a Byzantine fault-tolerant consensus protocol that utilizes rotating leadership and deterministic finality to secure blockchain state replication.
• It separates the consensus layer from the application layer using the ABCI interface, allowing integration with diverse state machines like relational databases.
• The protocol guarantees safety under partial synchrony with f < n/3 and has inspired further studies on liveness, fairness, and composable termination in distributed systems.

Searching arXiv for recent and foundational Tendermint papers to ground the article. Tendermint is a Byzantine fault-tolerant consensus protocol and consensus engine for blockchain-style state machine replication. In the literature it is treated as a permissioned BFT protocol, best described as a variant of PBFT, structurally close to PBFT but with deterministic leader rotation, a common-case messaging pattern related to Bracha’s Byzantine reliable broadcast, and deterministic finality under eventual synchrony with the standard threshold $f < n/3$ (Cachin et al., 2017). Subsequent work formalized its protocol logic, analyzed liveness pathologies and their fixes, and later established machine-checked safety and universally composable termination results, making Tendermint a central reference point in the theory and engineering of blockchain BFT consensus (Amoussou-Guenou et al., 2018, Dong et al., 1 Oct 2025).

1. Position in the Byzantine consensus landscape

Tendermint belongs to the classical BFT family: it is leader-based, voting-based, and intended for settings with identified validators. In the survey literature it is grouped with permissioned blockchain systems and characterized as a concrete, implemented instance of a “classical” Byzantine fault-tolerant blockchain consensus protocol (Cachin et al., 2017). It is therefore distinct from crash-only protocols such as Raft-based deployments, and also from probabilistic or hash-power-based protocols in the Nakamoto family, which do not provide deterministic finality under the same assumptions (Cachin et al., 2017).

A recurring architectural feature is the separation between the network/consensus layer and the application/state-machine layer. In one line of work, Tendermint Core is presented as a general-purpose BFT consensus and networking engine that can be coupled, through ABCI, with arbitrary deterministic state machines, including relational DBMS backends (Schuhknecht et al., 2022). This suggests that Tendermint is not merely a blockchain “protocol” in the narrow sense, but also a reusable replication substrate for deterministic applications that require agreement on an ordered stream of transactions.

The literature also places Tendermint in a broader comparative taxonomy. HotStuff treats it as a blockchain-era BFT protocol with a simple rotating leader and a Two-Chain commit rule, while later protocol proposals use it either as a baseline for comparison or as a component to be embedded under higher-level constructions (Yin et al., 2018, Berrang et al., 2019). In this comparative role, Tendermint is frequently the representative of deterministic-finality, partially synchronous, $n=3f+1$ BFT consensus.

2. Protocol structure and state-transition logic

At a high level, Tendermint runs one consensus instance per block height. Clients gossip transactions to validator nodes, validators locally construct candidate blocks from gossiped transactions, and the protocol orders those blocks through proposer election and quorum voting (Cachin et al., 2017). This differs from PBFT’s original client-to-all-replicas request pattern, and it is coupled to an external validity condition: the protocol is parameterized by a deterministic predicate $V(\cdot)$, and validators vote only for blocks that satisfy locally checkable validity, including transaction receipt and validation (Cachin et al., 2017).

The protocol is commonly described through the round-based sequence propose $\rightarrow$ prevote $\rightarrow$ precommit $\rightarrow$ commit, with one proposer per round and a commit condition requiring at least two-thirds of voting power in both prevote and precommit (Tsang et al., 2024). Another formal presentation decomposes each epoch into PRE-PROPOSE, PROPOSE, and VOTE rounds, with local variables $lockedValue_i$, $lockedEpoch_i$, $validValue_i$, and $validEpoch_i$ carrying safety-critical information across epochs (Amoussou-Guenou et al., 2018). These presentations are closely related: both emphasize that safety depends on locking and that liveness depends on how new proposals interact with previously locked values.

The most distinctive feature relative to PBFT is rotating leadership. Rather than retaining a primary until an explicit view-change protocol is triggered, Tendermint deterministically rotates the leader after every block or round, inspired by the Spinning protocol, and embeds aspects of view change into the common path (Cachin et al., 2017). If a validator does not receive a valid proposal before its timeout expires, it does not switch to a separate protocol instance; instead it continues in the voting pattern and may vote for nil, which allows progress without waiting indefinitely on a faulty proposer (Cachin et al., 2017).

Locking is central. Once a validator observes the relevant quorum support for a block, it locks that block and restricts future votes accordingly. Formal analyses describe the key invariants in terms of lockedValue, lockedRound, validValue, and validRound, or their epoch-indexed analogues (Amoussou-Guenou et al., 2018). This mechanism is what prevents conflicting blocks at the same height from both gathering commit support from correct validators.

3. System model, thresholds, and correctness guarantees

Tendermint is analyzed in the eventually synchronous, or partially synchronous, model of Dwork, Lynch, and Stockmeyer. Before a Global Stabilization Time, message delays may be arbitrary; after that point, delays are bounded by an unknown but fixed constant. Safety must hold in all executions, while liveness is guaranteed only after stabilization (Cachin et al., 2017, Dong et al., 1 Oct 2025).

The standard resilience threshold is the classical BFT bound

$n=3f+1$0

Quorum sizes are correspondingly $n=3f+1$1, and the underlying correctness arguments rely on Byzantine quorum intersection: any two quorums intersect in at least one correct validator (Cachin et al., 2017, Yin et al., 2018).

The survey literature summarizes Tendermint’s resilience as follows (Cachin et al., 2017):

Property	Crash faults	Byzantine faults
Safety	$n=3f+1$2	$n=3f+1$3
Liveness	$n=3f+1$4	$n=3f+1$5

Under these assumptions, the protocol provides agreement, integrity, total order, and deterministic finality. Agreement means that if a correct validator commits a block at height $n=3f+1$6, then every correct validator that commits at height $n=3f+1$7 eventually commits the same block; in blockchain terms, correct validators do not end up on permanent forks (Cachin et al., 2017). Integrity and total order follow from the combination of external validity, reliable broadcast structure, and quorum intersection (Cachin et al., 2017).

A later UC treatment sharpens the liveness statement under strategic message-delay attacks. In that model, Tendermint is shown to UC-realize an ideal functionality with bounded termination latency

$n=3f+1$8

provided that at most $n=3f+1$9 nodes are Byzantine and post-GST network delays remain within the protocol-defined threshold under partial synchrony (Dong et al., 1 Oct 2025). This gives a composable formulation of the standard claim that Tendermint maintains safety and termination even when composed with other blockchain components.

4. Liveness, locking, and the evolution of the formal theory

The protocol’s main technical subtlety lies in liveness rather than safety. A widely cited assessment states that Tendermint as originally described by Buchman suffered from a livelock bug pertaining to locking and unlocking votes, and that the implementation contained additional mechanisms not described in the cited report that appeared to prevent the bug, although a thorough peer-reviewed correctness analysis was still lacking at that time (Cachin et al., 2017). The later “Dissecting Tendermint” analysis made this point more explicit: earlier versions without validValue could fail to terminate, and the corrected protocol required carefully ordered conditions involving lockedEpoch and validEpoch to restore liveness under eventual synchrony and asymmetric Byzantine faults (Amoussou-Guenou et al., 2018).

This line of work identifies several algorithmic principles as necessary. First, the locking principle ensures that once $V(\cdot)$0 correct validators are locked on a value $V(\cdot)$1 in epoch $V(\cdot)$2, no correct validator can later acquire a conflicting lock in an epoch $V(\cdot)$3 (Amoussou-Guenou et al., 2018). Second, validity propagation via validValue and validEpoch ensures that once some value has accumulated the relevant prevote support, future proposers continue to re-propose it until consensus converges (Amoussou-Guenou et al., 2018). Third, timeout growth is essential: if timeoutPrevote and related timers do not increase, eventual synchrony is not enough to guarantee progress (Amoussou-Guenou et al., 2018).

HotStuff recasts these issues in a unifying framework. There Tendermint appears as a Two-Chain protocol that shares PBFT-style safety rules but does not achieve optimistic responsiveness. In that interpretation, Tendermint and Casper require a mandatory $V(\cdot)$4 delay before each leader proposal, because otherwise a simple two-phase protocol can livelock when leaders do not learn about higher locks in time (Yin et al., 2018). The contrast with HotStuff is structural: HotStuff adds an extra phase to preserve simple leader replacement while regaining responsiveness; Tendermint preserves the two-phase structure and pays for it with delay-based liveness (Yin et al., 2018).

Later formal methods work strengthened the picture. Tendermint is cited as one of the few complex consensus protocols whose safety has been formally verified, using IVy and quorum-intersection-based inductive invariants (Praveen et al., 2024). A separate line of work factors view synchronization into an explicit abstraction and shows that the resulting synchronizer is strong enough to guarantee liveness for Tendermint in the partially synchronous model, while also yielding protocol-specific latency bounds (Bravo et al., 2020). Together, these results move Tendermint from an initially promising PBFT variant with an undocumented liveness fix toward a protocol with machine-checked safety and composable termination analysis.

5. Implementations, systems integration, and application domains

Tendermint has been used as a consensus and replication layer under several distinct system architectures. One recurring pattern is the separation of dissemination from execution. In a “relational blockchain” design, Tendermint Core orders transactions and drives a deterministic state machine implemented by PostgreSQL or MySQL through ABCI callbacks such as BeginBlock, DeliverTx, Commit, and Query (Schuhknecht et al., 2022). There the cost of Tendermint becomes measurable relative to the underlying DBMS: synchronous use can impose very large overheads on lightweight workloads, whereas asynchronous operation and batching reduce the overhead to a small constant factor on heavier workloads such as TPC-C (Schuhknecht et al., 2022). This suggests that Tendermint’s practicality depends strongly on how the application drives the consensus engine.

Another architectural role appears in BigchainDB-based systems. In a cyber-physical healthcare stack, Tendermint sits under BigchainDB as the consensus engine, while IPFS stores large encrypted medical files and MongoDB supplies local persistence (Kumar et al., 2023). The paper presents Tendermint as the component responsible for BFT consensus, fast finality, immutable ordering of EHR asset transactions, and block-level replication. The same source also contains an instructive misconception: it claims the architecture “can recover the data if $V(\cdot)$5 of nodes are failed,” a statement that does not align with formal Tendermint BFT theory, which requires at least two-thirds honest voting power and tolerates up to roughly one-third Byzantine validators (Kumar et al., 2023). The discrepancy highlights a common confusion between replicated data availability and consensus fault tolerance.

Tendermint is also used as a modular subprotocol. Albatross invokes Tendermint only for macro blocks at the end of each batch, using it as a periodic deterministic-finality gadget, validator-set update mechanism, and synchronization backbone, while micro blocks are produced by a speculative PoS layer (Berrang et al., 2019). NodeOP builds a dedicated Layer 2 chain whose consensus is Tendermint BFT, with every general node operator also acting as a Tendermint validator and with task allocation and incentives optimized by an agent-based model layered above the chain (Tsang et al., 2024). In wireless settings, ReduceCatch adapts Tendermint to ad hoc LoRa-based networks; the paper distinguishes a Tendermint1 variant using N-to-N vote patterns and a Tendermint2 variant using N-to-1 plus 1-to-N communication, with the latter typically better suited to wireless contention patterns (Liu et al., 2024).

A recent example aimed directly at inclusion and ordering power is AMP, which places a multi-proposer dissemination layer on top of Tendermint. There, validators no longer maintain a mempool; instead, external proposers broadcast payloads to all validators, validators attest to payload identifiers through vote extensions, and Tendermint decides commit certificates from which the payload set for the next block is derived (Cason et al., 22 May 2026). This design is explicitly motivated by bounded inclusion guarantees and by reducing unilateral control of block assembly.

6. Comparative interpretation, fairness, and continuing research significance

Comparative protocol theory has repeatedly used Tendermint as a reference point. HotStuff places it alongside Casper as a Two-Chain protocol with a simple rotating leader and mandatory delay, and presents HotStuff as preserving the attractive leader simplicity while avoiding the non-responsive liveness regime (Yin et al., 2018). Morpheus, by contrast, treats Tendermint as the archetypal “standard” BFT SMR protocol against which a morphing blockchain/DAG protocol should be measured: in that account, Tendermint is competitive in low-throughput settings but “does not perform well during high-throughput” compared with modern DAG-based designs (Lewis-Pye et al., 12 Feb 2025). Both comparisons reinforce the same structural point: Tendermint occupies the classical deterministic-finality corner of the design space, with strong safety, clear quorums, and moderate communication complexity, but without the responsiveness or amortized throughput properties later protocols pursue.

Fairness has emerged as a separate axis on which Tendermint does not automatically provide strong guarantees. The analysis of Tendermint-core blockchains proves that there exists an eventual fair rewarding mechanism if and only if the system is eventual synchronous, and it also shows that the original Tendermint rewarding is not fair, whereas a modified protocol with modulable timeouts can be eventually fair (Amoussou-Guenou et al., 2018). A different simulation-based study places Tendermint as the ordering service inside Hyperledger Fabric and shows that, even while preserving safety and liveness, network delay attacks and Byzantine proposer behavior can violate client-fairness and several order-fairness properties (Mahe et al., 2024). These results make explicit that BFT safety and liveness do not imply fairness of transaction inclusion or ordering.

Tendermint’s continuing importance therefore lies in a combination of roles. It is a practical BFT engine for deterministic state machine replication, a canonical benchmark for later partially synchronous protocols, a target of increasingly strong formal verification techniques, and a substrate on which higher-level systems experiment with validator management, multi-proposer dissemination, application-specific execution, and fairness-aware ordering (Schuhknecht et al., 2022, Dong et al., 1 Oct 2025). The literature consistently presents it as a protocol whose core assumptions are classical—identified validators, $V(\cdot)$6, eventual synchrony, quorum intersection—but whose influence extends well beyond the original blockchain setting.