Following the previous blog, where we explored how general pipelined two-phase BFT protocols work, we’re now ready to dive into MonadBFT. We’ll begin by introducing the tail-forking problem, a critical flaw commonly found in traditional two-phase BFT protocols. After that, we’ll explore a straightforward idea that helps prevent it but ends up introducing a new problem. Finally, we’ll study how MonadBFT solves tail-forking without running into that new problem.

Tail forking occurs when the current leader goes offline, causing the previous leader's block to be ignored. This allows the next leader to propose a new block without reusing or reproposing the one that was skipped.

Let’s walk through an example. Figure 1 shows how traditional two-phase pipelined BFT protocols behave under normal operation when all validators are honest and no failures occur (as discussed in the previous article).

Figures 2 and 3 illustrate how tail-forking can arise in traditional two-phase pipelined BFT protocols. In Figure 2, the previous leader, V2, proposes block B11. However, the current leader, V3, goes offline during round 11, so no PrevoteQC for B11 is formed. As a result, no validators lock on B11, and B10 remains uncommitted.

Figure 3 shows what happens next. The protocol times out round 11 and elects a new leader, V4, for round 12. Since no validator is locked on any block at height 11, V4 is free to propose a new block B11b at the same height.

From there, the network resumes normal operation, but B11b replaces B11—even though B11 was honestly proposed by V2 and received votes from a majority of validators. It was ignored simply because the next leader, V3, was offline and couldn’t move the protocol forward.

This is problematic: imagine you are a validator who proposed a valid block, executed MEV logic, and expected to receive rewards, only to lose it all because the subsequent leader went offline. You did everything correctly, yet the protocol allowed your block to be skipped.

Things can become even more serious when MEV is involved. Suppose V3’s behavior isn’t accidental but intentionally coordinated with V4 as part of an MEV strategy. After V2 proposes block B11, V3 inspects it and sees potential opportunities. For example:

• If B11 is committed, V2 would capture a large MEV opportunity. V3 may prefer to intercept and snatch it, redirecting the opportunity to V4.

• Or, by preventing B11 from being committed and letting V4 build on it instead, they could extract even more MEV by manipulating the transaction order across B11 and the new block that V4 is about to propose.

To exploit this, V3 deliberately goes offline, giving up its own chance to propose a block in order to prevent the network from locking on B11 and committing it. In the next round, V4 steps in and builds a new block, B11b, based on B11. Once B11b is committed, V4 shares the MEV profit with V3, compensating for the missed rewards and incentivizing the attack.

This becomes even more dangerous when multiple validators coordinate. Earlier validators may intentionally skip their proposals, allowing the last validator in the group to aggregate transactions in the mempool and construct a larger-scale MEV extraction. The damage goes beyond honest validators losing their rewards; it also slows down the protocol and users lose money, especially those interacting with DeFi protocols.

In short, tail-forking enables coordinated MEV attacks that undermine both fairness and liveness of the protocol.

Shockingly, the method used to prevent tail-forking is quite simple. Instead of letting validators lock on a proposal whenever they receive PrevoteQC of the proposal or when they vote precommit for the proposal, validators will lock on a proposal as soon as they prevote the proposal. Thus, in our example, V1, V2 (vote for itself), and V4 will lock on B11 as soon as they receive the proposal from V2. With this approach, after V4 proposes the new block B11b, V1 and V2 will not vote for this as they are locking on B11.

So you might wonder: if it's that simple, why haven’t previous protocols implemented this? You have a great intuition! The problem is that it can lead to a dead lock if a leader is malicious. Consider the situation where V1 is a malicious leader of height H and send block B1 to itself and V2 and then send block B2 to V3 and V4, after they receive blocks they prevote for it. What happened next is that validators are divided into two groups:

1. V1 and V2 locks on B1.

2. V3 and V4 locks on B2.

Each group won’t vote for a block they’re not locked on. So B1 and B2 will at most able to gather up to 2 votes but since 3 votes ($2f+1=3$ in our case) are required for a block to be able to commit, either of B1 or B2 won’t be able to gather enough votes and the system won’t be able to commit leading to dead lock.

So we solve the tail-forking problem, but face a new problem: the deadlock problem. Fortunately, MonadBFT introduces a new special type of message called No-Endorsement (NE) message which helps eliminate the deadlock problem while allowing validators to early lock proposals and still be able to solve the tail-forking problem. Let’s explore this in detail.

The core idea of MonadBFT for avoiding tail forking is to use early locking, as discussed previously, together with timeout messages containing the most recent header of the proposal each validator voted on, and the NEC mechanism to prevent the deadlock problem.

In MonadBFT, a validator can unlock a proposal whenever it sees:

1. PrevoteQC: When a validator observes a PrevoteQC for a new proposal, it can unlock the previous proposal and switch to the new one. This follows the same rule as in traditional two-phase BFT protocols.

2. No-Endorsement Certificate (NEC): If a proposal fails to gather a PrevoteQC (e.g., V3 goes offline before B11’s PrevoteQC is formed), MonadBFT requires the next leader to repropose the same proposal. If the leader does not have the block, it requests it from other validators. Validators who did not vote for the previous proposal respond with No-Endorsement (NE) messages. Once the leader collects at least $f + 1$ NE messages, it forms a NEC. The NEC gives the leader permission to propose a new block, and validators are allowed to unlock the old proposal upon seeing the NEC. The NEC serves as evidence that the prior proposal was not seen or supported by enough validators to ever be committed. (Remember: committing requires $2f + 1$ votes out of $3f + 1$ validators. If $f + 1$ did not vote for the proposal, only $2f$ or fewer did, which is insufficient.)

To make this clear, we will walk through the same unhappy path we saw earlier, this time with MonadBFT, and see how it prevents the malicious leader V4 from successfully executing a tail forking attack:

1. V2 proposes B11 in round 11, and V1, V2, V3, and V4 vote and lock on B11.

2. V3, who should lead round 11, goes offline before forming PrevoteQC(B11).

3. The protocol times out round 11. Each validator broadcasts a Timeout Message (TM) containing the most recent block they voted for (B11 in this case).

4. V4 becomes the leader in round 12 and aggregates TMs into a Timeout Certificate (TC). It then selects the most recent proposal among those TMs—B11 in this case, since it was the last block everyone voted on.

From here, four possible scenarios may occur:

1. V4 is honest and has B11: V4 reproposes B11, attaching the TC as evidence. Validators proceed normally, allowing the protocol to recover: first precommitting B10, then prevoting B11, and so on.

2. V4 is honest, doesn’t have B11, and recovers it: V4 requests B11 from the network and successfully recovers it. It reproposes B11 with the TC. The protocol proceeds as usual.

3. V4 is honest, doesn’t have B11, and cannot recover it: Validators who also lack B11 send NE messages. If V4 collects at least $f + 1$, it forms a No-Endorsement Certificate (NEC) and safely proposes a new block, attaching the NEC as evidence.

4. V4 is malicious and tries to skip B11 without an NEC: This fails. Without $f + 1$ NE messages, the malicious leader cannot construct a valid NEC. Any block proposed without one will be rejected by honest validators.

These four scenarios show how MonadBFT handles the unhappy path, where failures or malicious behavior could lead to tail-forking. When a round times out, the next leader, V4, aggregates timeout messages from at least two-thirds of the validators into a TC. These timeout messages contain each validator’s most recent vote, allowing the leader to identify the most recent block that should be committed.

In case (a), the leader already has the candidate block and can repropose it immediately. This is the ideal case. In cases (b) and (c), the leader does not have the appropriate block and must request it from the network. Validators respond with NE messages if they did not vote for the previous proposal. If the leader receives enough NE messages (at least $f + 1$), it can form a NEC and safely propose a new block. If not, it must reuse the previous block.

Finally, in case (d), a malicious leader attempts to skip the prior proposal and introduce a new block without collecting enough NE messages. This attempt fails, because without a valid NEC and in the presence of early locking, honest validators will reject any unauthorized proposal.

This mechanism ensures that leaders can only move on from a missing proposal if they provide clear evidence that the block was not seen by enough validators to be committed. It protects honest proposals from being skipped, even in the presence of failures or adversarial behavior, and ensures that validators do not lose rewards due to network issues or MEV manipulation.

In this post, we explored the tail-forking problem and why it's dangerous. Then, we looked at how MonadBFT works and how it solves that problem using early locking mechanisms and NEC.

Beyond solving tail-forking, Monad also brings another important improvement to boost consensus efficiency: RaptorCast. RaptorCast helps reduce the bandwidth needed to broadcast proposals by using erasure coding to split a proposal into chunks, and then distributing those chunks using a tree-like structure.

We’ll dive into how RaptorCast works in the next blog post.

[1] https://arxiv.org/pdf/2502.20692

[2] https://www.category.xyz/blogs/monadbft-fast-responsive-fork-resistant-streamlined-consensus

[3] https://mirror.xyz/contributiondaoblog.eth/5nbATpfI0G-ryvhCAexc0_bCdVAk1AQbqC0HZ8hTNgc

[4] https://decentralizedthoughts.github.io/2023-04-01-hotstuff-2/