The What, Why and How of MonadBFT (pt. 1)

Have thoughts on this topic? Join the conversation on X

Blockchain enforces strict global consensus, which means everyone running the network, anywhere in the world, agrees on the same set of objective outcomes.

But how does a distributed system reach agreement even when some participants are lying, offline, or actively trying to subvert the process?

This is where consensus protocol comes in. It is a set of rules that allow a network of independent and potentially dishonest participants to agree on the order and contents of transactions.

Once you have this ‘strict global consensus’, blockchain unlocks wonderful properties like digital property rights, monetary hardness, and social scalability. But all of that rests on a protocol’s ability to maintain safety (no two conflicting blocks are finalized) and liveness (the network keeps making progress).

MonadBFT represents the latest leap forward in the evolution of consensus protocols.

A brief recap on past consensus mechanisms

The field of consensus mechanisms has evolved over decades. Early protocols like PBFT (Practical Byzantine Fault Tolerance) showed that agreement was possible even when up to f nodes (out of 3f+1) were malicious. These classical designs work by electing a leader who coordinates multiple rounds of voting among validators.

In each phase (e.g. pre-prepare, prepare, commit, reply), every validator must communicate with every other validator. This leads to quadratic message complexity (a full mesh of communication): if there are n validators, you need roughly n² messages per round. That’s manageable in small networks but becomes unworkable as the validator set grows.

Quadratic messaging is inefficient. In a network with 100 validators, you have to process tens of thousands of messages per round. For global, permissionless systems, that’s too heavy. As a result, early BFT protocols like PBFT and Tendermint were often deployed in permissioned systems or small validator sets where performance constraints were tolerable.

To scale BFT for permissionless environments, we need linear communication: every validator talks only to the leader, reducing message complexity from n² to n.

Hotstuff, first introduced in 2018, pushed BFT consensus forward by introducing a streamlined, leader-centric communication pattern with linear messaging complexity.

Instead of the quadratic explosion of messages in PBFT, in HotStuff all validators just send their vote to the next leader. That leader combines the votes into a single, compact proof called a Quorum Certificate (QC), which it sends to all of the validators in the next round. The QC is proof to each validator (and to any observers) that most other validators agreed with the previous proposal.

In the above diagram, you can see that HotStuff features multiple rounds of communication before the original block is finalized. However, HotStuff may also be pipelined for additional efficiency. In Pipelined HotStuff, multiple block proposals are pipelined (staggered); each round of communication has a new leader, who is responsible both for receiving/assembling/propagating the Quorum Certificate from the previous round’s votes and also for proposing a new block.

In Pipelined HotStuff, Leader 1 proposes a block, then Leader 2 assembles and shares a QC for Leader 1’s block while also proposing a new block, and so on. This setup forms a chain, where each new leader helps confirm the block that came before. Pipelining really just means overlapping these steps. While one block is being finalized, the next is already being proposed.

In short, HotStuff-based protocols achieved much better decentralization and performance: they can include more validators and finalize blocks with fewer messages and rounds. These properties have made HotStuff the template for many modern PoS consensus implementations. However, the pipelined design also introduces a subtle vulnerability.

The Problem of Tail-Forking

Tail forking can be understood as a chain reorganization at the ‘tail’ of the chain. It occurs when a block that is valid and correctly propagated to other validators should become a part of the chain (it received the required votes) but ends up getting abandoned due to the behavior of the next leader.

Essentially, a block is proposed and validated by a supermajority but still fails to commit and is replaced by a different block at the same block height (very unfair right?!).

Why would this happen? In Pipelined HotStuff, each leader has two jobs: A. propose a new block, and B. gather votes (form a QC) for the previous leader’s block.

For example, suppose validator Alice proposes block B_n and a supermajority of validators voted for it (enough to eventually form a QC). Normally, the next leader Bob (working on block B_n+1) should include that QC in his proposal.

But if Bob is offline or intentionally misses his slot, the QC for B_n won’t be propagated, and B_n will be abandoned.

Why does tail forking matter?

Tail-forking is 1) economically unfair and 2) potentially dangerous for liveness.

First is the issue of lost rewards: When a block is abandoned, the leader who produced that block loses any block rewards or transaction fees they would have earned. In the example, Alice gets nothing because Bob’s misbehaviour prevented finalization. This is unfair and creates bad incentive: a malicious actor like Bob can hurt competitors by nullifying their rewards. Honest validators, even if they do everything right, might not get paid if the next leader is faulty. Over time, this could discourage participation or encourage malicious behavior like collusion (more on that below).

Second is the issue of MEV exploitation. Tail forking provides an opportunity to exploit MEV. Let’s say the block Alice has built contained lucrative arbitrage transactions. If Bob is malicious, they can collude with the next leader Carol; Bob will intentionally abandon Alice’s block and Carol will rebuild the block at that height with some of the same transactions to capture the MEV themselves. Bob and Carol can basically collude to steal the MEV from Alice. Such 'reordering' attacks encourage collusion among leaders at the expense of overall network integrity.

Third is the issue of UX and finality guarantees. One of the key advantages of BFT consensus (compared to Nakamoto longest-chain protocols) is deterministic finality: once a block is committed, it is final and cannot be re-orged. However, tail-forking undermines this guarantee at the tip of the chain, where blocks are still in the “voted but not yet committed” state. Some high throughput dapps would ideally be able to act on a block’s info as soon as it's ‘voted’ before finality to reduce latency. Tail forking might lead to a sudden reversal of state for the average users (i.e. your balance might be wrong, the trade you just executed with 10x leverage is gone missing, a game state reverses).

Fourth is cascading failure. In most cases, tail forking might only cause a one-block delay. Using our previous examples, even if Alice’s block is dropped due to liveness issue from Bob, Carol picks it back up and continues the chains (like the screenshot below from gmonads.com). However in edge cases, this may lead to cascading failures. If several leaders in a row decide to tail fork the previous ones, the chain will stall until someone finally produces a block that persists.

Tail forking is a practical issue instead of just theoretical conjecture. In fact, all previous pipelined BFT implementations (pre-MonadBFT) are susceptible to some degree to it, because the design inherently relies on the next leader with finalizing the current leader’s block. There are some attempts to solve this but they usually come with significant trade-offs. For example, the

BeeGees protocol proposed ways to eliminate tail-forks but at the cost of returning to quadratic communication.

What is MonadBFT?

MonadBFT was created to directly address tail-forking vulnerability while preserving the performance gains. It builds on the HotStuff framework, which means 1) having rotating leaders, 2) pipelined commits, and 3) linear messaging, but introduces mechanisms to improve safety and liveness without sacrificing throughput.

The first priority for MonadBFT is to guarantee that any block proposed by an honest leader (that gathered a supermajority vote) will not get abandoned. The desired outcome here is that if a block gets a supermajority support, the protocol ensures that block will eventually be finalized and included in the chain (cannot be orphaned or skipped). The mechanism to enforce this is twofold: 1) mandatory reproposal and 2) the No-Endorsement Certificate (NEC).

1. Re-proposals

In a BFT protocol, time is divided into rounds called "views." Each view has a designated leader responsible for proposing a new block. If that leader fails, which means they 1) did not send a proposal on time or 2) sent an invalid one, the protocol moves to the next view with a new leader. MonadBFT includes a mechanism that ensures no honest block gets abandoned during this transition.

When the current leader fails, validators trigger a view change by broadcasting a signed message indicating that the round has timed out. Importantly, these messages also include some other information beyond just ‘hey there’s a failure’.

Each one must also include a reference to the most recent block that the validator saw and voted for. Think of it as saying: “I attest to not receiving a proper proposal this round, and here’s the latest block I have seen.”

The new leader then collects these timeout messages from a supermajority of validators (2f+1) of them and combines them into what’s called a Timeout Certificate (TC). The TC provides a snapshot of the best-known blocks across the network when the last round failed. Among these, the leader identifies the most advanced block (based on block height or view number, which is labelled “high_tip”).

MonadBFT requires the new leader’s proposal to include a TC formed from 2f+1 validators’ timeout messages, and to re-propose the highest-known pending block referenced in the TC , giving that block another chance to gather enough votes and be finalized. Why? Recall our intention earlier. This will ensure that blocks which were nearly finalized before the failure don’t simply vanish.

To illustrate: imagine validator Alice was the leader in view 5 (think of view as rounds) and proposed a valid block that many validators voted for. But the next leader, Bob, in view 6 goes offline. When Carol becomes leader in view 7, under the rules of MonadBFT, in order for Carol’s proposal to be valid she must include the TC, and she must re-propose Alice’s block. This way, Alice’s honest work doesn’t go to waste.

If Carol doesn’t have Alice’s block, she requests it from the other nodes. Those nodes can either provide her with the block, or respond with a signed No-Endorsement (NE) message indicating that they don’t have the block (more on that later). (At most f nodes might choose to not respond at all - a Byzantine behavior.)

After re-proposing Alice’s block, Carol gets a second slot so that she isn’t penalized for Bob’s failure either..

This re-proposal rule makes sure that the chain progresses fairly and that no valid work gets silently discarded due to bad luck or bad actors.

2. No-Endorsement Certificate (NEC)

As mentioned above, when a timeout occurs at Bob’s slot, Carol asks everyone for the high_tip block (Alice’s block), and at least 2f+1 validators will respond with either Alice’s block or with a signed No-Endorsement message.

If anyone responds with Alice’s block, Carol has the information and justification needed to re-propose it. Furthermore, Carol is expected to re-propose Alice’s block – the only way she is not allowed to is if at least f+1 people sign NE messages (allowing Carol to construct a No-Endorsement Certificate).

Why f+1? In any BFT system with 3f+1 validators, at most f can be malicious. If Alice’s block should persist, then at least 2f+1 honest nodes have received it. In order to skip Alice’s block and propose a new one at the same height, Carol needs f+1 validators to sign off on not receiving Alice’s block, but by assumption only f validators are Byzantine.

The NEC is the leader’s proof that skipping the reproposal is safe and justified. It is a receipt that says: “Here’s verifiable evidence that the previous block wasn’t ready to be finalized, so I’m not just ignoring it maliciously.”

Re-proposal + NEC = Tail Forking Resistance

To recap, combining re-proposal and NEC mechanism give MonadBFT a clear rulebook: either finalize what almost made it, or prove it wasn’t ready and move on. Nothing falls through the cracks.

This design guarantees tail-forking resistance: an honest leader’s block that garnered a supermajority of votes will eventually be committed, no matter what. A leader cannot selfishly fork away their predecessor’s block without leaving a cryptographic trail because the absence of an NEC would expose them.

Economically, this protects validators as your block (and the reward) won’t be abandoned by someone else’s misbehavior. Even in the example of a collusion: if Bob intentionally skips his slot to try to let Carol steal Alice’s block, MonadBFT would force Carol to repropose Alice’s block (because it had a quorum of votes) rather than create a new one. Carol would finalize Alice’s block and only then propose her own, meaning the attempted attack has no MEV benefit.

The breakthrough here is that MonadBFT achieves this without heavy communication. Previous approaches to solve tail-forkings (like BeeGees) imposed quadratic communication or very strict conditions in every round. MonadBFT relaxes those conditions by only invoking the broader communication (collecting lots of messages) when a failure happens, not every round. Thus, in the normal case of steady honest leaders, it still operates efficiently (more on happy vs unhappy path in Pt.2).

Conclusion

In this article, we explored the mechanism of traditional PBFT consensus, previous generations of hotstuff and how MonadBFT uniquely addresses the tail-forking problem endogenous to pipelined hotstuff.

Tail-forking distorts economic incentives for block builders and causes potential danger to network liveliness. MonadBFT introduces rules regarding reproposal and No-endorsement Certificate (NEC) to ensure that a block proposed by an honest leaser that reached quorum vote will not be orphaned or abandoned.

In part 2 we will explore the other two characteristics of MonadBFT which are 1) speculative finality and 2) optimistic responsiveness. We will also explore the implications of MonadBFT for validators and developers.