HyperBFT is the HotStuff-inspired delegated proof-of-stake consensus Hyperliquid runs: validators propose and vote in proportion to staked HYPE, and a committed round is final in 1 block. Delegated proof of stake means voting power follows HYPE bonded to an operator. One-block finality means that once a round commits, the actions in it are done. That is what turns a signed rest into HyperCore book state. A rest is a limit the book has accepted and that is waiting to match. HyperCore is Hyperliquid's onchain trading environment, where those books live.
Follow one proposal. A validator you delegated to is the leader for this HyperBFT round, so its software bundles signed HyperCore actions, including a rest that is not yet on the committed book, while other validators vote with their stake. When a quorum above two thirds of stake signs, that round is committed and sent to execution. Height ticks because the round carried a transaction, and the rest is now a HyperCore order with one-block finality. A later leader cannot un-place it by proposing a different sequence for the same round. How Hyperliquid works covers HyperBFT as the engine that writes one list. HyperBFT depth is the round itself.
Anyone may start the software. The set that currently votes is ranked by stake, and that is the set that commits the round.
What HyperBFT consensus is
HyperBFT is Hyperliquid's consensus: the process that agrees on one order of transactions. A validator is software that proposes bundles and votes on other operators' bundles. Stake-weighted means an operator's turn to lead, and the weight of its vote, scale with the HYPE delegated to it in the current staking epoch.
A round is a proposed bundle plus quorum signatures. A quorum on this chain is any validator set with more than two thirds of staked HYPE. When that quorum signs, the round is committed. Execution then applies the bundle. If the bundle included at least one transaction, height increments. Height is the execution index, a separate counter from the round number. The rest, cancel, trade, or liquidation in that bundle is then HyperCore book state at that height.
One-block finality is that inheritance. The protocol treats those actions as done at the committed round. A later round can cancel or match the rest. Those are new HyperCore actions in new rounds. A later leader cannot rewrite the first height by proposing a different sequence for the round that already committed.
What Hyperliquid is separates the chain from the token. The consensus job is narrower: how a round becomes a height, and what that does to a rest.
HotStuff family vs Hyperliquid's variant
HyperBFT sits in the HotStuff family: a leader proposes and validators vote. Hyperliquid wrote its own variant, with its own algorithm and its own networking layer. That pairing is a claim the project makes about itself. The docs describe both the algorithm and the networking layer as built to support this L1 (source: Hyperliquid Docs, About Hyperliquid). Inspired-by is design lineage. It is a different claim from an independent audit of the visor, which is Hyperliquid's validator binary.
HotStuff is the 2018 paper that lineage names. "Once network communication becomes synchronous, HotStuff enables a correct leader to drive the protocol to consensus at the pace of actual (vs. maximum) network delay". The paper calls that property responsiveness, and the same abstract adds linear communication complexity in the number of replicas (source: Yin et al., HotStuff on arXiv). Hyperliquid wrote its own variant on top of that family. A paper property is a design target. This chain publishes its own latency figures separately.
The HyperCore overview is the holder-facing name for that variant, and it is also where live latency methodology lives. "Hyperliquid is secured by HyperBFT, a variant of HotStuff consensus." End-to-end latency is measured as the duration between sending a request and receiving a committed response. For an order placed from a geographically co-located client, that figure has a median of 0.2 seconds and a 99th percentile of 0.9 seconds (source: Hyperliquid Docs, HyperCore overview). Co-located means the client sits next to the validators geographically. Those figures are dated measurements for a co-located client as of the August 20, 2026 fetch. Use them as a co-located snapshot, not a home-laptop service level.
Who proposes and who votes
Anyone may start validating or non-validating software. Running is permissionless. The active set is the top twenty-seven operators by stake (source: Hyperliquid Docs, running a validator). Registration without that rank still lets you run a replica. The replica can stream committed rounds. It does not vote on the current proposal.
Stake is how a validator gets to speak. Blocks are produced in proportion to delegated HYPE, which means a leader's turn is a function of how much HYPE is bonded to that name in this staking epoch. A replica that only downloaded the visor still waits on that stake rank before it proposes. A non-validating replica can follow committed rounds and still never propose. How decentralized Hyperliquid is covers the live set size and what that twenty-seven figure measures. The consensus fact here is smaller: only the stake-ranked set currently votes.
BloFin lists HYPEUSDT at 75x as of December 19, 2024 11:30 UTC, and HYPE/USDT spot is live as of May 30, 2025 13:30 UTC. Those rows are a centralized listing. A HyperCore delegation is HYPE bonded to a validator. A BloFin password stays off the voting set. HYPERUSDT on the same board is Hyperlane, a different listing.
Suppose you start the visor on a machine that is not in the top twenty-seven. You can follow committed rounds. The proposal that parks a rest is still signed by the stake-ranked set.
Rounds, height, and staking epochs
HyperBFT time uses three units. A round is the proposed bundle plus quorum signatures. Height is the execution index that only moves when a round carries a transaction. A staking epoch holds the validator set still for 100k rounds, which is about 90 minutes on mainnet.
| Unit | What it currently counts |
|---|---|
| Round | Proposed bundle plus quorum signatures |
| Height | Execution block with at least one transaction |
| Epoch | 100k rounds, about 90 minutes |
A rest lands because its round committed and then execution processed that bundle. A UI spinner stopping is a client event. The protocol event is the committed round plus a height.
The staking page is the holder-facing constant for those units. Each round may be committed after certain conditions are met, after which it is sent to the execution state for processing. A key property of the consensus algorithm is that all honest nodes agree on the ordered list of committed rounds. Execution blocks are indexed by a separate increasing counter called height. Height only increments on consensus rounds with at least one transaction. The validator set evolves in epochs of 100k rounds, which is approximately 90 minutes on mainnet. The validators and consensus stakes are static for each staking epoch. Validators may vote to jail peers that do not respond with adequate latency or frequency to the consensus messages of the voter. Upon receiving a quorum of jail votes, a validator becomes jailed and no longer participates in consensus. The operating requirement of consensus is that a quorum of stake is honest, meaning non-Byzantine (source: Hyperliquid Docs, staking). Byzantine here means a validator that lies or equivocates, for example by signing two conflicting proposals for the same round.
Empty rounds can exist. They do not bump height. An undelegation that clears the 1-day lockup still waits on the next epoch before consensus weights move, because stakes are static inside the current 100k-round window.
Suppose you rest a bid and the UI shows it working. The rest is HyperCore book state once that round has a height. An empty bundle that committed in between did not create a new book.
Quorum, jail votes, and slashing
A quorum on this chain is any validator set with more than two thirds of staked HYPE. The operating requirement is that this quorum is honest. Two thirds is the commit threshold the staking page already defined. The docs do not publish a Nakamoto coefficient. If two thirds of stake is offline or Byzantine, a rest stays uncommitted, and the docs do not ship a retail service level for how long that stall lasts.
Jailing is the peer-vote path. A quorum of jail votes removes an operator from consensus participation, and rewards for that operator's delegators stop. Slashing would burn delegated HYPE. Automatic slashing is still not implemented on today's staking page and remains reserved for provably malicious behavior such as double-signing at the same round. A jail is a liveness response. Delegators' HYPE is still there. Rewards for that operator pause until it is back in the set.
The operator runbook adds the forwarding rule the staking page leaves implicit. When a validator is jailed, it can still participate in the consensus network by forwarding messages to peers, but it does not vote on or propose blocks. When first registered or after changing your IP, the validator is automatically jailed, so it does not participate in consensus initially (source: hyperliquid-dex/node on GitHub). A newly registered or IP-changed operator is parked until unjailSelf lands after the jailed-until time. Self-jailing does not extend that duration. GitHub also recommends about 200ms two-way latency to at least one third of validators by stake as an operator target. That figure is operator advice for staying out of jail.
The mechanics are three facts in a row. More than two thirds of stake commits the round. Jail votes silence a slow operator without burning delegated coins. A jailed operator can still gossip without voting.
Suppose the operator you delegated to changes IP. That operator is auto-jailed until unjailSelf succeeds after the jailed-until time. Your rest can still land if another operator in the live top twenty-seven includes it, and a quorum above two thirds of stake commits that later round.
How one-block finality applies to a resting order
Once a round commits, the rest in that bundle is HyperCore book state at that height. One-block finality is that inheritance: the protocol treats the order, cancel, trade, or liquidation in a committed round as done. A later round can cancel it or match it. Those are new HyperCore actions in new rounds. A later leader cannot rewrite the first height by proposing a different sequence for the round that already committed.
HyperCore as the onchain book is where that rest sits after execution. The consensus fact is earlier: the rest is on the book in the sense that matters once the round that carried it has a height.
Suppose you already signed a bid that sits in the bundle the current leader proposed. Quorum signs, execution applies the bundle, and the bid now rests on that asset's HyperCore book in price-time among whatever else that height already committed. A later round can cancel it or match it. A later leader cannot rewrite the first height.
Consensus is looking at book-typed actions. One unique aspect of the Hyperliquid L1 is that the mempool and consensus logic are semantically aware of transactions that interact with HyperCore order books (source: Hyperliquid Docs, HyperCore order book). Inside a batch, that awareness is why cancels can sort ahead of new GTC and IOC actions before price-time even runs. GTC means good-till-canceled: the order rests until it is filled or canceled. IOC means immediate-or-cancel: any unfilled remainder is dropped at once. How the Hyperliquid book works walks that sort for a trader. The HyperBFT fact is that the proposer and the commit are looking at book-typed actions, not at an opaque blob that matching will interpret later.
A CEX withdrawal policy is a venue rule. A wallet pending label is often that the app has not seen the height yet. Ethereum uses a different design: if a pair of checkpoints attracts votes representing at least two thirds of the total staked ETH, the checkpoints are upgraded (source: ethereum.org, Proof of stake). How Ethereum proof of stake works is that other design's epoch and checkpoint picture. HyperBFT's holder claim is one committed round, not two checkpoints across an epoch.
Skip memorizing the batch categories. Carry the height: if the rest has one, a later leader is writing a new round, not editing the old one.
How a fill relates to a CEX confirmation
Treat HyperBFT finality as a protocol claim about a committed round. A shop's withdrawal policy is a venue rule. Ethereum's confirmation model uses checkpoints across an epoch. Co-located latency figures move with the software. A BloFin listing does not vote. A rest that has a height is the rest the round actually defined.
The parts line up. HyperBFT is a HotStuff-inspired variant the project wrote for this L1. Stake-ranked validators in the live top twenty-seven vote until a quorum above two thirds of stake commits the round. Execution assigns a height when the round carried a transaction, after which the rest is HyperCore book state, with mempool logic that already knows it is a book action. Jail votes can silence a slow operator without slashing delegators. Empty rounds do not bump height. Epochs freeze weights for 100k rounds.
Weigh three cases before you treat a fill as a hosted matching-engine ack. If you hold BloFin HYPEUSDT, you hold venue custody, not a vote and not a HyperCore height. If you hold a rest on HyperCore, you are waiting on the current leader's round, then on execution. If you are comparing confirmation models with Ethereum, you are looking at checkpoints and epochs, not one-block inheritance. Live 0.2 second and 0.9 second figures stay co-located measurements as of August 20, 2026. Throughput slogans missing from the overview stay off the HyperBFT constant list.
The book can feel like a hosted matching engine. The commit can still be a BFT round with a two-thirds stake quorum. Both of those are true at once. A rest is done when execution has indexed that bundle. A spinner stopping is a client event.
Frequently asked questions
If I withdraw HYPE from BloFin onto HyperCore, does that sit inside an already-committed round?
No. Withdrawal is a later signed HyperCore action, so it waits on some future leader's bundle, a later quorum, and a new execution index. A committed rest only covers what was in the round that proposed it. BloFin listed HYPEUSDT as a USDT-margined perpetual on December 19, 2024 11:30 UTC. That timestamp is a listing event, not a HyperBFT height, and converting that listing to BloFin spot still never becomes the withdrawal. HYPERUSDT remains Hyperlane.
If a validator is auto-jailed after an IP change, can another validator still commit a rest that operator signed as a trader?
Yes. Jail stops that operator from proposing and from voting. It does not freeze HyperCore. Another operator in the live top twenty-seven can still include the signed rest in a later bundle, and a quorum above two thirds of stake can still commit that later round. Until unjailSelf succeeds after the jailed-until time, the jailed operator cannot lead or sign as a voter, though it may still forward messages to peers, which is gossip rather than a vote.
Are staking rewards paid in the same instant a round commits?
No. Consensus commit and reward accounting are different schedules. Rewards accrue every minute and are distributed to stakers every day, then redelegated automatically to the same validator. The amount uses the minimum balance a delegator had staked during the staking epoch, which is those 100k-round windows of about 90 minutes, so a round that just committed can include a rest without being the payout tick that credits delegators.
If a later overview reprint shows a different co-located median, did yesterday's HyperCore height become reversible?
No. A rest that already received an execution index stayed committed when that round closed. A later stopwatch on a machine sitting next to the validators can publish a new median without rewriting an old height. Operator two-way latency advice in the visor README is still about staying out of jail on current rounds, not about reopening yesterday's book, and a home laptop still is not that co-located client.
Do HyperEVM fast and slow blocks replace HyperBFT's one-block finality for a HyperCore rest?
No. Dual-block duration is a HyperEVM throughput split, so a contract call can wait on a small or large EVM block while still sitting inside an L1 round that HyperBFT has to commit. A HyperCore rest does not use that EVM duration knob. It uses the HyperBFT round that carried the book action. Mixing the two schedules is how a 1-second EVM label gets mistaken for a book fill.
If two thirds of stake is offline, does a rest stay uncommitted, or does height still advance?
It stays uncommitted, because height only increments on rounds that committed with at least one transaction, so a stall that never gathers an honest quorum does not create a new book for that rest. The docs require a quorum of honest stake and do not publish a retail timeout for how long users wait through that stall. An empty round that did commit still would not bump height, which is a different case from a round that never committed at all.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on About Hyperliquid, HyperCore overview, staking, order books, and running a validator, plus the HotStuff paper, ethereum.org's proof-of-stake page, the official visor repository, and BloFin's public instrument API. Protocol and listing facts independently verified against cited sources current as of August 2026.
This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, validator concentration, consensus stall if a quorum of stake is unavailable, jailing of operators, custody risk on an exchange listing, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, stake, delegate, or trade HYPE, and nothing here is a safety or decentralization grade. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.