In the first part, we studied the working principles of classic PBFT (Practical Byzantine Fault Tolerance) consensus and the operation of early versions of HotStuff. We also learned how MonadBFT solves the HotStuff tail fork problem, where valid blocks are sometimes discarded in the pipeline system.
This tail fork issue causes two main problems: 1) It disrupts the rewards of honest block builders, 2) It may lead to network stagnation.
MonadBFT introduces a re-proposal rule and unendorsed voting mechanism to eliminate the tail fork problem, ensuring that any block from an honest proposer that has been properly approved enters the chain.
In the second part, we will explore two more features of MonadBFT: 1) Speculative finality and 2) Optimistic responsiveness. We will also discuss the impact of MonadBFT on developers.
Single-Round Speculative Finality
In addition to resisting tail forks, another key feature of MonadBFT is single-round speculative finality.
In practical application, this means clients and users can receive transaction confirmations immediately after a block receives an overwhelming majority of votes, even before the next round is completed.
Recall that in the baseline HotStuff protocol, a block usually goes through at least two stages (as in Fast-Hotstuff and Diem-BFT) before being considered finalized (irreversible): one stage obtains a quorum certificate (QC) (locking the block with ≥2f+1 votes), and the second stage is when the next leader builds and submits a block based on that quorum certificate (QC).
This two-stage commit is necessary to ensure safety: once enough honest nodes have locked a block, conflicting blocks cannot obtain a quorum, and the submission in the next round will make it permanent. Therefore, clients may typically need to wait for the next block or round to know if the previous transaction is finalized.
MonadBFT essentially allows transactions to be considered final enough (safe to operate) after just one round of voting. This is called speculative finality.
When a leader proposes a block and validators vote to form a QC for that block, the block is in an voted state (locked by a quorum). In MonadBFT, once validators form a QC, they immediately execute the block's transactions and even send preliminary confirmations to clients, indicating the block is (speculatively) accepted. It's like saying "We have an overwhelming majority agreeing on this block. Unless something very unexpected happens, this block can be considered confirmed."
This immediate confirmation is optimistic. The block has not yet been committed to the ledger. This will happen when the next proposal appears and confirms it (QC-on QC), but under normal circumstances, nothing will revoke it. The only situation that could revoke the speculative block execution is if the leader launches an equivocation attack (proposing two different blocks at the same height to scatter votes).
You can view speculative finality as a great byproduct of tail fork resistance. Tail fork resistance ensures that even if the next leader crashes, the current proposal will not be discarded (thanks to re-proposal and NEC rules). The only scenario where a speculatively executed block is discarded is if the original proposer launches an equivocation attack (a provably malicious double-signing error), which: 1) can be detected through conflicting QCs; 2) can be punished; 3) is extremely rare.
In previous protocols, they did not guarantee that the next leader would re-propose the previous block, making tail forks possible and breaking the speculative assumption.
Optimistic Responsiveness
In most consensus protocols, there is a built-in wait after each round, such as a buffer period or timeout. This is to ensure all messages arrive before proceeding. It's a protective mechanism designed to handle worst-case scenarios, such as leader crashes or no messages being sent at all.
These timeouts are usually overly conservative. If the network is running normally and all validators are behaving correctly, a fixed wait becomes an unnecessary overhead. Blocks could have been completed faster, but the protocol delays them just in case.
MonadBFT introduces optimistic responsiveness, meaning the protocol can immediately advance based on network information, rather than always relying on fixed timers. The design principle can be summarized as "go fast when possible, be patient only when necessary".
MonadBFT's design ensures that in normal circumstances, even during failure recovery, it will not pause and wait for a predetermined timeout unless necessary.
- On the happy path (meaning we have an honest leader): There are no built-in delays in proposing or voting. Once it's the leader's turn, it proposes a block. Validators immediately vote upon receiving a valid proposal. When the leader (or more precisely, the next leader, as in pipeline HotStuff, votes are sent to the next proposer) collects 2f+1 votes, the QC is formed and can be propagated. In the optimistic responsiveness design, this immediately triggers the next stage.
In practice, this means if network latency between nodes is 100 milliseconds, consensus might complete a round in just a few hundred milliseconds (plus computational and aggregation overhead).
It won't wait if unnecessary, for example, for a full second of "slot time". This differs from the slot-and-epoch model used on the ETH mainnet. On Ethereum, block production intervals are fixed at 12 seconds. Even if everyone is ready, the protocol will wait.
MonadBFT's approach eliminates unnecessary delays. It retains the pipeline HotStuff structure but removes the hard requirement of "must wait Δ seconds" under normal conditions. This means it can be more responsive than time-constrained systems without compromising safety.
- On the unhappy path (leader failure): In many consensus protocols, nodes only realize a leader failed to propose a block after a timeout Δ. For example, if Δ is 1 second, that time is essentially wasted. MonadBFT handles this differently. When validators detect a missing proposal, they immediately broadcast a timeout message (TC or timeout certificate). Once 2f+1 timeouts occur, the next leader takes over. The transition to a new view is triggered by quorum-based evidence, not by a clock.
Comparison with HotStuff-Family Consensus
MonadBFT is built on the HotStuff series of consensus protocols but stands out by implementing a combination of ideal features. Early protocols typically optimized for certain dimensions like pipeline throughput or linear communication, but had to sacrifice other aspects. MonadBFT uniquely combines linear message complexity, pipeline commit, strong tail fork resistance, instant responsiveness without fixed delays, and efficient recovery mechanisms, while maintaining fast finality and high availability guarantees.
What Does This Mean for Developers and Users?
For Developers, MonadBFT Means Several Things:
- Simpler Finality Model: With MonadBFT, you can view blocks with QC (supermajority vote) as effectively finalized, because the protocol will either finalize it or impose a penalty. Developers can confidently operate with 1 block confirmation.
- Improved Application User Experience: If you are building a high-throughput application (exchanges, games, etc.), MonadBFT's low latency and fork resistance will translate into a smoother user experience. Users can almost instantly see their actions confirmed, without frequently encountering confusing reorganizations or rollbacks. This allows you to design applications with finality and rapid updates.
- Deterministic Behavior: MonadBFT's stricter rules (such as re-proposal requirements) reduce the uncertainty of block inclusion. There are fewer "edge cases" where blocks are included or skipped due to subtle timing factors like whether votes or timeouts reach the leader first. MonadBFT replaces this time-sensitive ambiguity with clear rules and verifiable evidence. This makes reasoning about protocol correctness and testing easier. It also provides clear grounds for identifying faulty nodes (for example, if someone fails to re-propose or proposes conflicting blocks, you know they have violated the protocol).
- Scalability Space: If you are a developer focused on scalability, MonadBFT provides more room before hitting bottlenecks. Compared to quadratic protocols, you can more easily increase block size or validator count. And features like erasure-coded block propagation mean you can push large amounts of data through the network without overly taxing individual nodes. This makes targeting higher throughput possible and opens design space for more ambitious on-chain applications.
For End Users: Ordinary users won't understand any of what we're discussing here, but they will feel its impact. With MonadBFT as the foundation of the Monad chain, users can expect all these good features without sacrificing decentralization and censorship resistance.
- Faster Confirmations: Transactions (such as sending tokens, swapping assets, minting Non-Fungible Tokens, executing trades) will be quickly confirmed.
- Fewer Surprises: Chain state consistency is higher, as things inherently involving reorganizations like tail forks have been eliminated.
- Fairness and Transparency: Consensus improvements indirectly mean the chain operates more fairly. No single validator can easily censor transactions or manipulate ordering between blocks.
Conclusion
In summary, MonadBFT introduces four core innovations on top of a pipelined HotStuff-style consensus:
Tail Fork Resistance: MonadBFT is the first pipelined BFT protocol to eliminate tail fork attacks. It achieves this by having the next leader re-propose the block from the previous leader in case of failure, or present a No-Endorsement Certificate (NEC) proving the block lacks support. This ensures that any block with supermajority support will not be discarded, protecting honest leaders' rewards and preventing malicious reorganizations and cross-block MEV extraction.
Single-Round Speculative Finality: Validators can confirm blocks after a single round of communication (one leader proposal and vote), providing instant inclusion guarantees for clients. This speculative confirmation only reverts in the case of leader equivocation attacks (which can be proven and penalized), making it a safe assumption in practice.
Optimistic Responsiveness: The protocol runs at network speed with no inherent delay. Leaders immediately advance consensus upon receiving necessary votes, and view changes occur immediately after observing a quorum timeout, rather than waiting for a fixed timeout interval. This optimistically responsive design minimizes wait times and maximizes throughput while remaining robust in handling asynchrony and failures.
Linear Communication: On the happy path (i.e., when the leader is honest), message and validation complexity scales linearly with the number of validators. MonadBFT preserves HotStuff's efficient communication pattern using aggregated signatures and simple leader-to-validator broadcasting, enabling the protocol to scale to hundreds of validators without performance bottlenecks.
