How Finality Works on Solidus (HotStuff BFT)
Open the Solidus explorer's block list and click the block at the top; on its detail page the Status field reads Finalized. That's not a designed-in property claimed in a whitepaper, it's a field that renders on a real block-detail page, for a stranger, right now. This page explains what that word is actually certifying, because "finalized" means something specific and checkable, not just "old enough that it's probably fine."
Say that plainly before anything else, because the rest of this page is a claim you can verify, and a claim you can verify is worth more from a project that states its own stage up front.
Deterministic finality, not accumulated confidence
Proof-of-work chains like Bitcoin don't finalize a block the moment it's mined, they offer probabilistic finality. A block gets safer the longer other blocks pile up on top of it, but in principle a long enough competing chain could still displace it; "six confirmations" is a convention for how much waiting counts as safe enough, not a hard guarantee. Solidus's consensus works differently: once a supermajority of the validator committee has certified a block through enough rounds, that block is final, full stop, no further confirmations needed, no "probably" attached to it.
The mechanism behind that guarantee is a chain of quorum certificates (QCs), compact, aggregated proofs that a supermajority of the committee voted for a given block. The block at the top of the list carries its own QC data: a block hash, a consensus round, and the aggregated signature that certifies it. Finality isn't a separate vote after the fact. It's what you call the state a block reaches once enough further QCs have formed on top of it. That's the whole distinction from proof-of-work in one sentence: instead of waiting for blocks to accumulate, the chain waits for certificates to chain.
HotStuff and HotStuff-2, correctly attributed
The consensus family behind this is HotStuff, introduced in 2019 by Maofan Yin, Dahlia Malkhi, Michael Reiter, Guy Golan Gueta, and Ittai Abraham in "HotStuff: BFT Consensus in the Lens of Blockchain." Its leader-based, pipelined design keeps validator-to-validator communication linear in committee size, rather than the quadratic overhead of older BFT protocols like PBFT, which is why it's the consensus family behind production systems including Meta's LibraBFT/DiemBFT and, later, Aptos. HotStuff-2, a simplified two-phase variant of the same idea, was described by Dahlia Malkhi and Kartik Nayak in 2023.
Solidus did not design either protocol. solidus-consensus is a from-scratch Rust implementation of the HotStuff family, not a fork of Diem's, Aptos's, or any other client's codebase.
Precision matters on which version is actually running. A separate HotStuff-2 (2-chain) core has been built and bounded-model-checked with TLA+, 963,033 states explored, zero safety violations found, but that work has been benchmarked only on a single Apple M4 machine over local loopback, not deployed to the public network, and no geo-distributed measurement of it exists. The live chain runs 3-chain HotStuff today; HotStuff-2 is tested engineering work, not yet what's running.
The committee that votes
This is the part worth stating with the least room for misreading. Not twenty-one. Not a hundred. Four, run in-house, which is what makes it possible to observe HotStuff finality live at all today, and also exactly why it isn't yet evidence of the protocol at adversarial, independently-run scale.
The protocol's target design is a 21-of-100 committee, elected by verifiable random function from a pool of up to 100 registered validators. That number describes a specification the code is built toward: it is not deployed, and no VRF-elected committee of that size has ever run. A quorum certificate aggregating four team-operated signatures and one aggregating twenty-one independently-operated signatures prove the same thing mathematically, but only the first has actually happened. Rounding four up to twenty-one, or describing the spec as if it were live, would misstate what's running today, this page states the smaller, real number instead.
What finality buys a relying party
The reason any of this matters outside a consensus textbook: once a block is finalized, anything anchored in it (a DID registration, a credential-status update) is guaranteed not to revert. That's what makes checking an on-chain claim once meaningful instead of something you'd need to re-confirm on a timer. A relying party looking up a DID or a revocation status isn't trusting that the answer probably won't change; deterministic finality is the specific property that makes "checked once" and "true" the same statement.
Where to go next
One honesty note: the explorer UI's block list currently renders seeded demo data whose heights disagree with the live RPC (a known product gap, flagged for engineering), so don't anchor on any specific height. Open /blocks, pick whatever block sits at the top, and open its detail page: the Status field will read Finalized, and its Round and hash fields are the same QC-chain machinery described above, on a block that exists right now rather than one composed for this page. For the four fields this page assumed you already knew, height, proposer, transaction count, gas, see how to read a Solidus block, the page this one picked up from.