MonadBFT Explained (Part 2): What It Means for Developers and Users

In Part 1, we examined how classical PBFT (Practical Byzantine Fault Tolerance) consensus works and how early versions of HotStuff operate. We also learned how MonadBFT solves HotStuff's tail-forking issue—where valid blocks are sometimes discarded in pipelined systems.

This tail-fork problem causes two main issues: 1) It disrupts rewards for honest block proposers, 2) and may lead to network stagnation.

MonadBFT introduces the re-proposal rule and no-endorsement voting mechanism to eliminate tail-forking, ensuring that any properly approved block from an honest proposer gets included in the chain.

In this second part, we will explore two additional features of MonadBFT: 1) speculative finality and 2) optimistic responsiveness. We will also examine the implications of MonadBFT for developers.

Single-round speculative finality​

Besides resisting tail-forking, another key feature of MonadBFT is single-round speculative finality.

In practice, this means clients and users can receive transaction confirmations immediately after a block receives a supermajority of votes—even before the next round completes.

Recall that in baseline HotStuff protocols, a block typically needs at least two phases (as in Fast-HotStuff and Diem-BFT) to be considered final (irreversible): one phase to obtain a quorum certificate (QC) (locking the block with ≥2f+1 votes), and a second phase where the next leader builds and commits a block based on that quorum certificate (QC).

This two-phase commit is necessary for safety: once enough honest nodes have locked onto a block, conflicting blocks cannot gather a quorum, and the next round’s commitment makes it permanent. Therefore, clients usually need to wait for the next block or round before knowing whether the previous transaction is finalized.

MonadBFT essentially allows transactions to be considered sufficiently final (safe to act upon) after just one round of voting. This is known as speculative finality.

When a leader proposes a block and validators vote to form a QC for that block, the block reaches a voted state (locked by quorum). In MonadBFT, validators execute the block’s transactions immediately upon forming the QC and may even send preliminary confirmation to clients indicating the block has been (speculatively) accepted. It's like saying, “We have a supermajority agreeing on this block. Unless something highly unexpected happens, this block can be treated as confirmed.”

This immediate confirmation is optimistic. The block is not yet committed to the ledger. That happens when the next proposal appears and most confirms it (QC-on-QC), but under normal conditions, nothing will revert it. The only scenario that could revert a speculatively executed block is an equivocation attack by the leader (i.e., proposing two different blocks at the same height to split votes).

You can view speculative finality as a beneficial side effect of tail-fork resistance. Tail-fork resistance ensures that even if the next leader crashes, the current proposal won’t be discarded (thanks to re-proposal and NEC rules). The only case where a speculatively executed block gets dropped is if the original proposer equivocates (a provably malicious double-signing fault), which: 1) can be detected via conflicting QCs; 2) is punishable; 3) is extremely rare.

In prior protocols, there was no guarantee that the next leader would re-propose the last block, making tail-forking possible and thereby breaking the speculative assumption.

Optimistic responsiveness​

In most consensus protocols, there is a built-in wait period after each round, such as a buffer or timeout. This ensures all messages have arrived before proceeding. It's a safeguard designed for worst-case scenarios, like a leader crashing or failing to send any information.

These timeouts are often overly conservative. If the network operates normally and all validators behave correctly, then fixed waits become unnecessary overhead. Blocks could finalize faster, but the protocol delays them just in case.

MonadBFT introduces optimistic responsiveness, meaning the protocol can advance immediately based on network conditions rather than always relying on fixed timers. The design principle can be summarized as “move fast when you can, wait only when you must.”

MonadBFT is designed so that under normal conditions—and even during recovery—it does not pause to wait for scheduled timeouts unless absolutely necessary.

• On the happy path (meaning we have an honest leader): There is no built-in delay in proposing or voting. As soon as it's the leader’s turn, they propose a block. Validators vote immediately upon receiving a valid proposal. When the leader (or more precisely, the next leader, since in pipelined HotStuff, votes are sent to the next proposer) collects 2f+1 votes, the QC forms and can be propagated. Under optimistic responsiveness, this immediately triggers the next phase.

In practice, this means that if network latency between nodes is 100ms, consensus might complete a round in just a few hundred milliseconds (plus computation and aggregation overhead).

It doesn't wait unnecessarily—for example, a full one-second "slot time." This differs from Ethereum mainnet’s slot-and-epoch model. On Ethereum, block production intervals are fixed at 12 seconds. Even if everyone is ready early, the protocol still waits.

MonadBFT’s approach eliminates unnecessary delays. It retains the pipelined HotStuff structure but removes the hard requirement to “wait Δ seconds” under normal operation. This means it can outperform time-bound systems in responsiveness without sacrificing security.

• On the unhappy path (leader failure): In many consensus protocols, when a leader fails to propose a block, other nodes only realize this after a timeout Δ. For instance, if Δ is 1 second, that time is essentially wasted. MonadBFT handles this differently. When validators detect a missing proposal, they immediately broadcast timeout messages (TC or timeout certificates). 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 builds upon the family of HotStuff consensus protocols but stands out by achieving a unique combination of desirable properties. Earlier protocols often optimized for certain dimensions—like pipelined throughput or linear communication—but had to sacrifice others. MonadBFT uniquely combines linear message complexity, pipelined commitment, strong tail-fork resistance, instant responsiveness without fixed delays, and efficient recovery mechanisms—all while preserving fast finality and high availability guarantees. The table below summarizes how MonadBFT compares with other rotating-leader BFT protocols across these key dimensions:

What does this mean for developers and users?​

For developers, MonadBFT implies several things:

• Simpler finality model: With MonadBFT, you can treat blocks with a QC (supermajority votes) as effectively finalized, since the protocol will either finalize them or punish deviations. Developers can safely operate with high confidence on 1-block confirmation.
• Improved application UX: If you're building a high-throughput application (exchange, game, etc.), MonadBFT’s low latency and fork-resistance translate into a smoother user experience. Users see their actions confirmed almost instantly, without frequent confusing reorganizations or rollbacks. This enables designing applications with finality and rapid updates.
• Deterministic behavior: MonadBFT’s stricter rules (like re-proposal requirements) reduce uncertainty in block inclusion. Edge cases where blocks are included or skipped due to subtle timing factors—such as whether votes or timeouts reach the leader first—are minimized. MonadBFT replaces 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 (e.g., if someone fails to re-propose or proposes a conflicting block, you know they violated the protocol).
• Scalability headroom: If you're a developer focused on scalability, MonadBFT gives you more room before hitting bottlenecks. Compared to quadratic protocols, you can scale block size or validator count more easily. Features like erasure-coded block propagation mean you can push large amounts of data through the network without overloading individual nodes. This makes higher throughput feasible and opens up design space for more ambitious on-chain applications.

For end users: Ordinary users won’t understand any of what we’ve discussed here, but they’ll feel its impact. With MonadBFT as the foundation of the Monad chain, users can expect all the following benefits without sacrificing decentralization or censorship resistance.

• Faster confirmations: Transactions (like sending tokens, swapping assets, minting NFTs, executing trades) will be confirmed quickly.
• Fewer surprises: Chain state is more consistent because tail-forks—essentially reorgs—are eliminated.
• Fairness and transparency: Improved consensus indirectly means the chain operates more fairly. No single validator can easily censor transactions or manipulate ordering between blocks.

Conclusion​

To summarize, MonadBFT introduces four core innovations on top of pipelined HotStuff-style consensus:

Tail-fork resistance: MonadBFT is the first pipelined BFT protocol to eliminate tail-fork attacks. It achieves this by requiring the next leader to either re-propose the last voted-upon block if the previous leader fails, or provide a no-endorsement certificate (NEC) proving lack of support. This ensures any block with majority support won’t be discarded, protecting honest leaders’ rewards and preventing malicious reorgs and cross-block MEV extraction.

Single-round speculative finality: Validators can confirm blocks after a single round of communication (one leader proposal and voting), giving clients immediate inclusion guarantees. Such speculative confirmation only reverts in the event of a leader equivocation (a provable and punishable act), making it a safe assumption in practice.

Optimistic responsiveness: The protocol runs at network speed with no inherent delay. Leaders advance consensus immediately upon receiving necessary votes, and view changes happen immediately upon observing a quorum of timeouts—rather than waiting for fixed timeout intervals. This optimistic responsiveness minimizes waiting and maximizes throughput, while remaining robust during asynchrony and failures.

Linear communication: On the happy path (i.e., when the leader is honest), message and verification complexity scales linearly with the number of validators. MonadBFT retains HotStuff’s efficient communication pattern using aggregate signatures and simple leader-to-validator broadcasts, enabling the protocol to scale to hundreds of validators without performance bottlenecks.