On 22 September 2026 the Cosmos Hub, a chain that runs on Tendermint consensus, stopped. Block 33,086,741 is stamped 11:18:23 UTC; the next block, 33,086,742, carries 12:06:23 UTC on the following day. That gap of 24 hours and 48 minutes can be read by anyone from the chain itself. No server had crashed and no bug had fired. Hub validators halted block production on purpose after an attacker, who had taken over applications on Neutron through a governance vote, moved stolen value onto the Hub as ATOM, Protos reported. When the chain came back, its first block ran a patched release that moved 1,227,121.37 ATOM out of the attacker-linked address.
That stop was the BFT vote working as designed. A block on the Hub is final once validators holding more than two thirds of the voting power have signed it, and when enough of them refuse to sign, nothing moves at all. This lesson takes that vote apart: the rounds and locks of Tendermint, what the HotStuff protocol changed after 2018, the chains that run its descendants, the DAG designs that dropped the single leader, and why every one of them keeps its validator set small.
The theory behind it sits in our lesson on the Byzantine generals problem. In short: a group of n machines can agree despite f liars only if n is at least 3f + 1, signed messages change the maths, PBFT made the idea practical in 1999, and the FLP result says no protocol can be both always safe and always live on a network with no reliable clock. Tendermint and HotStuff both accept that bargain. They keep safety under any network delay and only promise progress once the network behaves.
The consequence for users is covered in our lesson on finality and reorgs: a committed block on a CometBFT chain is final in one block, with no reorg to wait out, and when too many validators are missing the chain halts instead of splitting. Bitcoin offers finality by depth and Ethereum by checkpoint votes every two epochs. Here both lessons are taken as read, and we look inside the machine that produces that one-block finality.
The previous lesson of this path, on delegated proof of stake, showed how validators get elected and how few operators can hold a third of the stake. This one is about what those elected validators do, message by message, every few seconds.
From Tendermint to CometBFT: one engine, ten years
Tendermint began with Jae Kwon’s white paper “Tendermint: Consensus without Mining”, which the CometBFT repository still links. Ethan Buchman developed the algorithm in his master’s thesis at the University of Guelph, “Tendermint: Byzantine Fault Tolerance in the Age of Blockchains”, which the university library records as issued on 23 June 2016. The formal version came on 13 July 2018, when Buchman, Kwon and Zarko Milosevic posted “The latest gossip on BFT consensus” to arXiv, revised for the last time in November 2019.
The paper starts from a contrast. Classic state machine replication ran in data centres with “three to seven” replicas run by one organisation. A public blockchain needs hundreds of validators spread across companies and countries, linked only by the open internet. Tendermint’s answer was to keep the PBFT-style vote and to deliver every message through peer-to-peer gossip, so that a validator only needs to talk to its neighbours.
The second idea was separation. Tendermint orders transactions and leaves their meaning to an application connected through an interface, ABCI. The Cosmos SDK is one such application framework, which is why “Cosmos” and “Tendermint” are often confused: the SDK decides what a transaction does, the consensus engine decides in what order transactions are final.
The split came at the turn of 2023. On 5 January Jae Kwon froze the feature set of Tendermint Core at its 0.34 line, the version the Cosmos Hub then ran, and noted in the repository that the Informal Systems team had created a fork called CometBFT. Informal Systems announced that fork on 1 February 2023 as “a fork of, and a successor to” Tendermint Core, and its first release, v0.34.27, followed on 27 February. The project’s README today says it plainly: “CometBFT is a fork of Tendermint Core and implements the Tendermint consensus algorithm.” The name changed, the algorithm did not.
The engine is still maintained. Release v0.40.0, published on 27 July 2026, added a post-quantum validator key type, mldsa65, based on the ML-DSA signature standard, and v0.38.26 backported its verification on 13 August 2026. Public Cosmos Hub nodes queried on 8 November 2026 reported CometBFT v0.38.25. Several chains of the family, Celestia and dYdX among them, run their own forks of the engine, so the version number differs from one network, and sometimes one node, to the next.
How Tendermint consensus works, one round at a time
Tendermint decides one block per height. Each height runs one or more rounds, and every round has three steps: propose, prevote, precommit. If a round fails, the next one starts with a new proposer and the same height. The rules below follow the CometBFT consensus specification as published on 8 November 2026.
Propose, prevote, precommit
The proposer of each round is picked by a deterministic round robin that the specification describes as weighted by voting power: a validator with twice the stake proposes twice as often. Every node can compute who the proposer is, so there is no election message. The proposer builds a block and gossips it.
In the prevote step, each validator signs a prevote for that block if it received it in time and finds it valid. Otherwise it prevotes nil, an explicit vote for nothing. Votes are counted by voting power, not by heads. The specification writes “+2/3” for more than two thirds of the voting power and “1/3+” for one third or more.
When a validator sees more than two thirds of prevotes for the same block, it moves to precommit and signs a precommit for that block. When it then sees more than two thirds of precommits for it, the block is committed and the height is done. On the Cosmos Hub, where 180 validators sat in the active set on 8 November 2026, that means signatures carrying more than two thirds of the bonded ATOM, whatever the number of validators behind them.
Two votes are needed because one is not enough to be sure that others saw the same thing. A prevote quorum tells a validator that the network has, for this round, agreed on one candidate. A precommit quorum tells it that more than two thirds of the power knows that too, and has promised to stick to it.
Why a validator locks on a block
That promise is the lock. A set of more than two thirds of prevotes for one block in one round is called a proof-of-lock-change, or PoLC. A validator that sees a PoLC for block B and precommits B is now locked on B. In later rounds of the same height it prevotes B again, whatever the new proposer offers, and it only releases the lock if it sees a PoLC for something else at a later round.
The safety argument, as the specification gives it, fits in a few lines. Assume less than a third of the voting power is Byzantine. If any validator committed B at round R, it saw more than two thirds of precommits for B at R. Remove the dishonest third from that group and more than one third of the power is honest and locked on B. Those validators will not prevote anything else, so no other block can ever gather the more than two thirds it needs. Two conflicting commits at one height would need more than a third of validators to sign both, which is evidence that the chain can prove and punish, as our lesson on slashing and validator rewards explains.
Locks could freeze a chain if different honest validators held different locks. The 2018 paper handles this with two variables per validator, the staking or liquidity, measured at current market prices. It is the main size metric in DeFi.">locked value and the valid value: a later proposer re-proposes the block that most recently gathered a PoLC, and validators locked on an older round may accept it. Progress resumes as soon as one round goes well.
Timeouts, extra rounds and the cost of waiting
The specification lists four reasons a round can fail: the proposer is offline, its block is invalid, the block did not spread in time, or the prevotes and precommits did not arrive in time. Each step therefore has a timer. In the 2018 paper each timeout grows with the round number, as an initial value plus the round times a fixed increment, and resets at each new height. A slow network makes rounds longer until messages fit inside them.
After a commit, nodes also wait a fixed timeoutCommit to collect late signatures before starting the next height. Those waits are part of block time. Measured over 1,000 blocks on 8 November 2026, between 08:11:35 and 09:46:45 UTC, the Cosmos Hub produced one block every 5.71 seconds on average. Osmosis, also on CometBFT, averaged 0.84 seconds over the same kind of sample: the vote is the same, the parameters are not.
The waiting is also where critics aimed. The HotStuff authors argue that “responsiveness is precluded with designs such as Tendermint/Casper”. Their point: a new proposer in Tendermint must wait for the known maximum network delay to be sure it has heard of the highest lock held by an honest validator. A chain cannot go faster than that timer even when the network is fast.
Gossip instead of a central collector
In Tendermint every validator broadcasts its prevote and precommit, and every other validator must receive and check them. With n validators that is about n squared signature checks per step across the network. The paper’s abstract says the design simplifies classic BFT by relying on a peer-to-peer gossip protocol among nodes. Gossip keeps messages flowing when some links fail, at the price of traffic that grows quickly with n.
Three halts on Cosmos chains, three different causes
Because Tendermint chooses safety over liveness, its failures look the same from outside: blocks stop. The causes behind three stops on Cosmos chains are quite different. (Terra’s halts of May 2022, during the LUNA collapse, are told in the Byzantine generals lesson.)
| Chain | Dates | Length | Cause | Aftermath |
|---|---|---|---|---|
| Neutron (secured by Cosmos Hub validators) | 1 August 2023 | Not given in the sources used | Halt after a software upgrade; two validators double-signed while upgrading in a hurry | Hub proposal 818 to slash them rejected on 24 August 2023 |
| Cosmos Hub | 5-6 June 2024 | About 4 h 40 min (19:21 to 00:02 UTC) | Panic in GetLastValidators: more than 180 bonded validators after an unjail | Gaia v17.2.0, Cosmos SDK patch |
| Cosmos Hub | 22-23 September 2026 | 24 h 48 min between blocks 33,086,741 and 33,086,742 | Validators stopped signing after the Neutron governance attack | Patched Gaia moved 1,227,121.37 ATOM to a recovery address; proposal 1056 vetoed |
Sources: Informal Systems (August 2023), Cosmos Hub proposals 818 and 1056 read on chain, Cosmos Hub v17.1 post-mortem on the Cosmos forum, block times read from the Cosmos Hub on 8 November 2026, Protos and CryptoSlate (September 2026).
August 2023: Neutron stalls and two validators double-sign
Neutron, a chain then secured by Cosmos Hub validators under the Hub’s replicated security, halted on 1 August 2023 after a software upgrade went wrong. In the rush to upgrade, two validators deleted the file that stops a CometBFT node from signing twice at the same height, and both signed conflicting blocks, according to a post-mortem by Informal Systems published on 17 August 2023. Hub proposal 818, titled “Punish Equivocation on Neutron by Pupmos and Citizen Cosmos”, asked ATOM holders to slash them. It was rejected on 24 August 2023: about 100.3 million ATOM voted no, 23.8 million yes, 16.2 million abstained and 2.0 million vetoed, according to the proposal’s tally on chain.
The episode shows a side of BFT safety that the proofs leave out. The engine recorded evidence of the double signing, which anyone could query from a Neutron node. Whether to punish it was a political question, and the stakers answered that an accident during an emergency did not deserve a cut.
June 2024: a panic at 180 validators
On 5 June 2024 the Cosmos Hub upgraded to v17 between 16:58 and 17:15 UTC. At 19:21 UTC it halted at block 20,740,970 and did not produce block 20,740,972 until 00:02 UTC on 6 June, about 4 hours 40 minutes later, according to the post-mortem on the Cosmos forum.
The cause was a panic in a function called GetLastValidators, run at the end of every block. An unjail transaction briefly put one validator too many into the bonded set, and the code found more than the maximum of 180 bonded validators. Every honest node hit the same panic at the same height, so the chain stopped rather than diverged. The fix shipped as Gaia v17.2.0 with a patched Cosmos SDK. The number 180 is a governance choice, and it is also wired into the state machine.
September 2026: halting on purpose
The September 2026 stop began on Neutron. A governance proposal called “AI Agent Takeover” passed there and gave its author control of two applications, Astroport and Drop, according to Protos, which reported that the attacker spent about 20,199 dollars on NTRN tokens to pass the vote. Estimates of the loss differ: Protos gave initial losses of 9.5 million dollars, while a Neutron contributor quoted by CryptoSlate put the first impact near 4.4 million. Part of the value reached the Cosmos Hub as ATOM.
Hub validators then stopped signing, after block 33,086,741. For a Tendermint chain to stop, validators with more than a third of the voting power only need to stay silent; the press did not publish who stopped first or in what order. The chain restarted on 23 September 2026 around 12:06 UTC on a patched Gaia release, and its first new block moved 1,227,121.37 ATOM, about 2.2 million dollars at the time according to CryptoSlate, to a recovery address controlled by a group of validators. The patch could not catch everything: 168,990.9 ATOM refunded by THORChain reached the attacker-linked address seven blocks after the restart, then moved to Osmosis and was sold for about 266,841 USDC, according to an on-chain analyst quoted by CryptoSlate.
A proposal on the Hub, number 1056, then asked the community smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool to pay 1,221,120 ATOM to the attacker-linked address, describing the sweep as theft, plus a 500,000 ATOM “justice bounty” for those voting yes. Voting closed on 30 September 2026 at 23:20 UTC and it was rejected: about 91.5 million ATOM voted no with veto, 6.0 million no, 3.9 million abstain and 0.6 million yes, close to 90 percent veto on our reading of the tally on chain.
What a halt does and does not show
None of these stops broke safety. No two conflicting blocks were ever final at the same height. What they show is where the power sits. The rule that lets more than two thirds finalise a block also lets one third freeze a chain, and lets a supermajority restart it with a state change that no transaction signed. Some call September 2026 an emergency rescue, others a precedent for censorship. The protocol has no opinion; it only counts signatures.
HotStuff: one leader collects the votes
Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta and Ittai Abraham posted HotStuff to arXiv on 13 March 2018; a short version was presented at the PODC conference in 2019. It kept the partially synchronous model of PBFT and Tendermint and attacked two costs: the price of replacing a leader, and the waiting that makes Tendermint slower than the network.
The problem: expensive leader changes
In PBFT, changing leader (a view change) means every replica sends its evidence to the new leader, who must forward proof of all of it: by the paper’s count, O(n^3) authenticators. With four replicas that is nothing. With a hundred or more validators across the world, a single faulty leader becomes expensive, and a chain rotates leaders every block. Tendermint avoided the heavy view change by waiting a fixed delay, which is the responsiveness problem above.
Quorum certificates and three phases
HotStuff sends every vote to the leader instead of to everyone. The leader collects votes from n minus f replicas and combines them, with a threshold signature, into one quorum certificate (QC): a compact proof that a quorum agreed. The leader then broadcasts the QC. Traffic per decision becomes linear in n.
A decision goes through phases called prepare, pre-commit and commit, each ending with a QC. A replica locks when it sees the pre-commit QC, and a block is decided once its commit QC exists. A new leader starts from the highest QC it has received from n minus f replicas and does not need to wait for the slowest one, which is what the authors call optimistic responsiveness: the protocol moves at the speed of the actual network.
Chained HotStuff: one vote, three jobs
The paper’s practical version pipelines the phases. Each new block carries the QC of its parent, and that single vote counts as the prepare phase for the newest block, the pre-commit phase for its parent and the commit phase for its grandparent. When a block gets a child with a QC, it forms a one-chain; with a grandchild, a two-chain, at which point replicas lock on it; with a great-grandchild in consecutive views, a three-chain, and the oldest of the three is committed.
In steady state a new block is proposed every view and an older one becomes final at the same pace. One message pattern, repeated, does all the work. That regularity is a large part of why HotStuff became the template for chains built after 2019.
What HotStuff pays: one extra phase
The third phase is not decoration. The paper explains that a two-phase protocol with a linear view change can stall: a new leader may not know about a lock held by some honest replica, propose something else, and get no quorum, again and again. Tendermint fixes that by waiting; HotStuff fixes it by adding a phase so that a leader holding the highest QC is enough. The authors call it “a small price to latency”.
| Protocol | Correct leader | Leader replaced | f leaders fail in a row | Responsive |
|---|---|---|---|---|
| PBFT | O(n2) | O(n3) | O(f n3) | Yes |
| SBFT | O(n) | O(n2) | O(f n2) | Yes |
| Tendermint / Casper | O(n2) | O(n2) | O(f n2) | No |
| Tendermint* / Casper* (with threshold signatures) | O(n) | O(n) | O(f n) | No |
| HotStuff | O(n) | O(n) | O(f n) | Yes |
Authenticators (signatures or MACs) sent per decision after the network stabilises, n validators, f faulty. Source: Table 1 of the HotStuff paper, arXiv 1803.05069, version of 23 July 2019. The starred rows are the authors’ estimate for a variant that the original works did not describe.
The table is the HotStuff authors’ own comparison, not a neutral benchmark. Their footnoted Tendermint* row matters: with threshold signatures, which the original works did not describe, Tendermint’s message count would also be linear. The real difference is responsiveness, not raw message counts.
After HotStuff: heirs and rivals
LibraBFT and DiemBFT
The first large user was Facebook’s Libra project, whose 2019 technical report says plainly that its consensus core “is based on HotStuff”, with its own additions such as a round synchronisation mechanism; the protocol was later renamed DiemBFT. The project ended when the Diem Group sold its technology assets to Silvergate, a deal announced on 31 January 2022 and valued at about 182 million dollars in cash and shares. Engineers who had worked on Diem and Meta’s Novi wallet then founded Aptos Labs and Mysten Labs, the company behind Sui, The Block reported in December 2021 and March 2022.
Jolteon: back to two phases
In June 2021 a team including Rati Gelashvili, Lefteris Kokoris-Kogias and Alberto Sonnino published Jolteon, a two-chain variant of HotStuff. It commits after two QCs instead of three and pays for it with a quadratic view change, the cost HotStuff had removed. The bet is that leaders rarely fail, so a faster common case is worth a heavier recovery. The paper reports commit latency 200 to 300 milliseconds lower than HotStuff in its tests.
Aptos: AptosBFT, Baby Raptr and single-hop blocks
Aptos documents its consensus only as AptosBFT, a protocol that tolerates up to one third of malicious validators. Its improvement proposals show the direction. AIP-106, “Baby Raptr”, marked Final, lets consensus propose transaction batches before their proof of storage is collected, cutting about 180 milliseconds, two network hops, from the path (as measured on Aptos mainnet on 30 October 2024). AIP-131, also Final, lets leaders propose a block without waiting for the QC of its parent, so block time falls from two network hops to one.
The chain is fast whichever mix of these changes is live today. Between ledger heights 1,169,571,873 and 1,169,581,873, read around 09:47 UTC on 8 November 2026, Aptos produced 10,000 blocks in 375 seconds, one every 37.5 milliseconds on average, with 83 active validators. That is block spacing, empty blocks included, not a finality time or a transaction rate.
MonadBFT: a rival design with speculative finality
Monad sits beside the family rather than inside it. Its documentation does not present MonadBFT as a version of HotStuff; it measures it against “pipelined HotStuff-family consensus protocols” and their weak spots. The docs give MonadBFT a minimum block time of 300 milliseconds, speculative finality after one slot (300 ms) and full finality after two (600 ms). It claims linear message and authenticator complexity on the happy path and protection against tail-forking, where a malicious leader drops its predecessor’s block to capture its value. According to the docs, those earlier pipelined designs often lose pairs of slots when one leader misses its turn, which MonadBFT is built to avoid.
HyperBFT behind an exchange
Hyperliquid, the on-chain derivatives exchange, describes its consensus as “a variant of HotStuff consensus” in its documentation. The figures it publishes are for trading, not for blocks: a median end-to-end latency of 0.2 seconds and 0.9 seconds at the 99th percentile, and about 200,000 orders per second on mainnet. Our HYPE coin page covers the token.
DAG consensus: many proposers, no single leader per block
Leader-based protocols share a bottleneck: one validator per round must receive, bundle and send the whole block. A second line of research, built by several of the same people, spreads that work across everyone.
Narwhal: spreading data apart from ordering it
Narwhal and Tusk, posted on 25 May 2021 by George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino and Alexander Spiegelman, splits the job in two. In Narwhal every validator publishes batches of transactions in rounds, each batch referring to batches of the previous round, which builds a directed acyclic graph (DAG) of certified data. Ordering is then a separate, light step. In the paper’s wide-area tests Narwhal combined with HotStuff passed 130,000 transactions per second, and Tusk, an asynchronous ordering layer, reached about 160,000 at about 3 seconds of latency.
Bullshark, then Mysticeti on Sui
Bullshark, posted on 14 January 2022, orders the same DAG with a partially synchronous rule and reported 125,000 transactions per second at about 2 seconds of latency with 50 parties. Mysticeti, posted on 23 October 2023, goes further: blocks in its DAG are not certified one by one, which removes message rounds, and blocks can be committed directly from the pattern of references above them.
Sui adopted Mysticeti on mainnet in the summer of 2024. Its documentation describes Mysticeti as a consensus protocol based on a directed acyclic graph, and does not mention HotStuff. It is not a HotStuff descendant: there is no single leader collecting votes into a chain of QCs, even though both families share authors and the same two-thirds quorum. In epoch 1305, which started on 8 November 2026, the Sui network had 125 active validators.
The published numbers need care. Sui’s own documentation cites benchmark results of about half a second to commit and very high throughput, and states that these are not production metrics. Papers test on controlled networks; a live chain with uneven validators and real load behaves differently.
Why validator sets stay small
Every protocol in this lesson needs signatures from more than two thirds of the voting power for each decision. That is the price that sets the size of the validator set.
Counting signatures
Take the gossip design. With 180 validators, each sending a prevote and a precommit that every other validator checks, one round means about 180 × 180 × 2, or 64,800 signature checks across the network. With 1,000 validators it is two million. Aggregated signatures and a leader that collects votes reduce the traffic, but each vote still has to be produced, sent and verified within a block time measured in seconds or less.
The cap is written into the chains. On 8 November 2026 the staking parameters read Cosmos Hub 180, Celestia 100, Injective 45, Sei 40, Osmosis 30 and dYdX 21. As the June 2024 panic showed, the Hub’s limit is also a hard rule in its code.
A small set means a short list of names
The smaller the set, the fewer operators it takes to stop or to finalise. On our own computation from chain data on 8 November 2026, without merging validators run by the same entity, the 4 largest Cosmos Hub validators held more than one third of bonded stake, as the delegated proof of stake lesson also found. On Aptos the 14 largest of 83 validators exceeded a third of voting power; on Sui, the 18 largest of 125. Those are the coalitions that could halt each chain by staying silent.
Ethereum’s version of the problem
Ethereum shows the opposite choice. It has about a million validator entries and finalises by checkpoints every two epochs instead of every block. In his note on paths toward single-slot finality, written when there were 445,064 active validators, Vitalik Buterin says “We cannot quite take Tendermint or another existing BFT algorithm as-is”. Tendermint stops when more than a third of validators go offline, while Ethereum is built to keep producing blocks, so it needs a fork-choice rule and an inactivity leak on top of any vote. He adds that processing hundreds of thousands of signatures per slot is possible, which is why the proposals pair faster finality with fewer, larger validators. Our lesson on proof of stake in depth covers how Ethereum’s validators vote today.
Research keeps moving. Minimmit, posted on 14 August 2025 by Chou, Lewis-Pye and O’Grady, belongs to a group of protocols that finalise after a single round of votes, two rounds counting the proposal, by accepting a stricter assumption: n at least 5f + 1, so fewer than a fifth of validators may be faulty instead of a third. In a simulation of 50 processors spread over ten virtual regions, the authors measured 23.1 percent lower view latency and 10.7 percent lower transaction latency than the protocols they compared it with.
BFT chains side by side, 8 November 2026
| Chain | Consensus | Family | Active validators (cap) | Block time or finality |
|---|---|---|---|---|
| Cosmos Hub | CometBFT v0.38 | Tendermint | 180 (cap 180) | 5.71 s per block, final in one block (measured) |
| Celestia | CometBFT-based | Tendermint | 100 (cap 100) | 2.85 s per block (measured) |
| Injective | CometBFT-based | Tendermint | 45 (cap 45) | 0.60 s per block (measured) |
| dYdX Chain | CometBFT-based | Tendermint | 21 (cap 21) | 0.64 s per block (measured) |
| Osmosis | CometBFT | Tendermint | 30 (cap 30) | 0.84 s per block (measured) |
| Sei | Sei’s own Tendermint fork (nodes report v0.35) | Tendermint | 40 (cap 40) | 0.47 s per block (measured) |
| Aptos | AptosBFT | HotStuff line (Diem heritage; Baby Raptr and optimistic proposals per its AIPs) | 83 | 37.5 ms block spacing (measured, empty blocks included) |
| Monad | MonadBFT | Pipelined, compared by its docs with HotStuff-family protocols | Not published in the sources used | 300 ms speculative, 600 ms full finality (docs) |
| Hyperliquid | HyperBFT | “A variant of HotStuff” (docs) | Not read | 0.2 s median order latency (docs, not finality) |
| Sui | Mysticeti | DAG (Narwhal and Bullshark line) | 125 (epoch 1305) | Not measured; docs give benchmark figures only |
Measured figures: average over the last 1,000 blocks (10,000 on Aptos), read between about 09:45 and 09:55 UTC on 8 November 2026 from each chain’s public API; caps from staking parameters; the Cosmos Hub engine version from node information. “CometBFT-based” covers chains that run CometBFT or their own fork of it. Monad and Hyperliquid: their documentation, read on 8 November 2026.
Read the table with its limits. Block spacing on a CometBFT chain equals its finality time, since a committed block is final. On Aptos the spacing includes empty blocks and says nothing about how long a transaction waits. Monad’s and Hyperliquid’s figures come from their own documentation, not from our measurement.
Five questions to ask about any BFT chain
When a new chain advertises fast finality, five questions place it on the map drawn in this lesson. What share of voting power can stop it, and has that happened? Is a block final at once, or after two or more slots? How many validators are in the set, is there a cap, and how many of them hold a third of the stake? Does one leader per round collect the votes, or is it a DAG with many proposers? And what did the last halt look like: a bug, a mismatch, or a decision?
None of these answers ranks a chain as good or bad. They show where a design spent its budget: Tendermint waits so that its rules stay simple, while Jolteon accepted a heavier recovery to shave a few hundred milliseconds off the common case. More context on families of consensus sits in our overview of what consensus is, and the Cosmos chains of the table have their own pages, such as Osmosis and Celestia.
The next lesson of this path turns to Solana: proof of history, the clock its block leaders keep, and Alpenglow, the voting system the network switched on in October 2026.
