| Sybil resistance mechanism | Proof-of-Stake (PoS) |
| Min block time | 400 ms |
| Finality | 2 slots (800 ms) |
| Speculative finality *(can only revert in [rare circumstances](#speculative-finality) requiring equivocation by the original leader*) | 1 slot (400 ms) |
| Delegation allowed | Yes |
Illustrating the pipelined (staggered) nature of MonadBFT. Same diagram as the previous, but zoomed out to include one more round.
## Unhappy Path (Fault Handling) The unhappy path describes the abnormal case where either the leader fails to send out a valid proposal or the QC builder (next leader) fails to build a QC. Understanding the unhappy path is crucial to understanding how the happy path works as well! The thing that ultimately allows a validator to speculatively finalize a proposal after receiving the child proposal, or finalize a proposal after receiving the grandchild proposal, is knowing that the fallback mechanism will still preserve the original proposal. Here, we will focus on the standard recovery, which is actually the fallback of the fallback mechanism. In most cases in practice, we can use [fast recovery](#fast-recovery), which substantially speeds up the time for the protocol to go back to the happy path after a failure occurs. However, for the protocol as a whole to achieve the tail forking resistance, even in the worst case of Byzantine failures, we rely on the standard recovery, which we now present. ### Scenario As before, to describe the flow of the unhappy path, we'll follow a scenario shown in a diagram. Again, suppose that it is currently round `K` and Alice is the scheduled leader. Bob and Charlie are the next two leaders in the schedule. Alice has last seen block `N-1`, so she is going to propose block `N`. In our example, Alice sends block `N` at round `K`, but Bob fails to send a block at round `K+1`. This could be because he was offline, or it could be that Alice either sent an invalid block, or not enough people voted for it.
### Round `K`: Alice's proposal
1. **Proposal:** Alice, the designated leader for round `K`, chooses a payload and
builds block `N`, consisting of the payload and a [QC](#quorum-certificate-qc) from the
previous proposal (again, don't worry about this part).
Alice sends the proposal directly to all other validators.
2. **Voting:** Each validator checks the proposal for validity and, if valid, sends signed
votes directly to Bob, the designated leader for round `K+1`. Each validator marks Alice's
proposal locally as [`Proposed`](/monad-arch/consensus/block-states#proposed).
### When round `K+1` was expected: Bob's missed slot
3. **Bob fails to propose block `N+1`**, so all votes are blackholed and no QC for Alice's
block is produced.
4. **Everyone sends timeout messages:** After a timeout window, each validator "realizes" that
round `K` has failed since no QC is formed for Alice's block. Therefore, everyone sends a
[timeout message](#timeout-message) about block `K` to every other validator. (Note that this
communication is all-to-all.)
5. **TC assembly**: Upon getting a supermajority of timeout messages, every validator including
Bob assembles a [TC](#timeout-certificate-tc), proving that round `K` (Alice proposer, Bob
QC builder) failed. Upon building a TC for `K`, validators advance their round to `K+1`.
### Round `K+1`, as progressed by TC
The TC contains a computed value called [`high_tip`](#high-tip), which (roughly speaking)
is the block header of the latest valid block that any of the validators contributing to
the timeout message have seen. You can think of `high_tip` as the max block observed over
the 2/3 of the stake weight required to sign the TC.
In this specific example, `high_tip` will be the block header of Alice's block.
Under the rules of MonadBFT, the next leader is obligated to either re-propose the block
referenced in `high_tip` of the TC (i.e. Alice's block), or to prove that that block is
unsupported. (We'll discuss this in more detail below.)
Since we are now in Round `K+1`, the next leader is **Bob**. (You might find this ironic, but it
is a necessary consequence of the fact that the protocol cannot distinguish between the
possibility that Bob was offline, and the possibility that either Alice sent an invalid block
or not enough people voted on Alice's block. In either of the latter cases, it would be
unfair to skip Bob.)
6. **(Optional) Requesting Alice's block from other validators**: Bob needs to re-propose Alice's
block. However, the `high_tip` is only a block header - not the full block body - so if Bob
doesn't have Alice's block, he can request the full version from the other validators (via
[blocksync](/monad-arch/consensus/blocksync)).
#### Reproposal case (Bob re-proposes Alice's block)
7. **Reproposal**: If Bob has Alice's block (either due to already receiving it when he
originally proposed it, or via blocksync) then he proposes it along with the TC justifying
the re-proposal.
8. **Voting:** Each validator votes on the validity of Bob's reproposal. If the reproposal
is valid, validators send their votes to the next leader, Charlie.
9. **QC Formation:** Charlie assembles a QC from the votes.
10. **Charlie's proposal:** Charlie builds a block at round `K+2`, consisting of a new payload and
the QC on reproposal from round `K+1`, and sends the block to everyone. At this point Alice's
block becomes [`Voted`](/monad-arch/consensus/block-states#voted) to anyone who receives Charlie's block.
Everyone advances their rounds to `K+2` and the protocol returns to the happy path.
#### Fresh proposal case (Bob proves Alice's block is unsupported)
7. **No-Endorsement of Bob's block**: Recall that in step 6, Bob was allowed to poll
the other validators for Alice's block. When a validator is polled, if they also don't
have it, they can send Bob a signed
[No-Endorsement Message](#no-endorsement-message-and-no-endorsement-certificate) attesting
to *not* having seen Alice's block. If a supermajority of the validators sign
No-Endorsement Messages, then Bob may assemble a
[No-Endorsement Certificate (NEC)](#no-endorsement-message-and-no-endorsement-certificate).
8. **Bob's fresh proposal**: Under the rules of MonadBFT, Bob may skip re-proposing
Alice's block, and instead make a [fresh proposal](#fresh-proposal) of a new block (at the
same block height `N`) if he can also supply a NEC.
It's important to emphasize that Bob is only allowed to skip reproposing Alice's
block if a supermajority of validators sign the NEC. Otherwise, he is obligated to re-propose.
This rule helps ensure that Alice's block finalizes even though Bob failed to build a QC for
Alice's block.
From this point, consensus proceeds normally, returning to the happy path.
#### No proposal case
There is a third possibility, which is that Bob fails to propose anything at all in round `K+1`.
(This is fairly likely, because he failed to send a block the first time that round `K+1` was
expected.) In this case, a timeout occurs again, this time of round `K+1`, allowing consensus
to move to round `K+2`, Charlie's turn. Charlie then inherits the situation Bob was in in round
`K+1`, i.e. he must either re-propose Alice's block, or prove that Alice's block is unsupported.
More generally, if Charlie (and maybe a few subsequent leaders) also fail to propose anything,
the situation will persist until someone either re-proposes Alice's proposal or proves that it is
unsupported. That's the MonadBFT rule about the `high_tip`, and it ensures that Alice's block
will eventually finalize unless it never should have been supported.
## Discussion
### No-Tail-Forking
In prior implementations of pipelined HotStuff-family consensus protocols, the case where Bob misses his slot results
in Alice's proposal also being rolled back (tail forked). The intuition behind this is: Bob is
the only person responsible for receiving everyone's votes on Alice's proposal, so when he goes
offline, all of those votes are blackholed, making it hard to distinguish between the case
where most validators voted YES for Alice's proposal and the case where most validators
rejected her proposal.
For instance, in [Fast-HotStuff](https://arxiv.org/abs/2010.11454), TCs carry enough information to prove that Bob missed his slot, allowing
Bob to justifiably propose a block that skips Alice's block, making Alice's
block a casualty. Bob simply re-proposes the same block height as Alice did,
replacing Alice's block in the final blockchain. This is the reason why pipelined HotStuff
consensus mechanisms prior to MonadBFT frequently see pairs of missed slots.
**Tail forking is a serious weakness.** When Alice’s block is proposed, if Bob sees valuable MEV opportunities in it, Bob—as QC builder (next leader)—may refuse to build the QC for Alice’s block and to propose his own block carrying Alice’s QC. In this case, validators cannot detect whether Alice failed to propagate her proposal or Bob refused to build a QC; therefore Bob is given an opportunity in round K+1 to propose a block. Bob can then extract high-value MEV by selecting only preferred transactions, and by reordering or replacing them at will. In other blockchains, unintentionally allowing blocks to be re-mined has resulted in [massive impact](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338).
The key to MonadBFT's No-Tail-Forking property lies in the handling of the missed slot
situation. Intuitively speaking, in MonadBFT, [TCs](#timeout-certificate-tc) carry enough
information to propagate the knowledge of the existence of Alice's block forward even when Bob
blackholes all of the votes about it.
When it becomes Bob's turn to propose, he is obliged to re-propose Alice's block (based on the TC,
which includes high\_tip, aka a valid block header for Alice's block) unless he can get a
supermajority (`2f+1`) to attest to *not* seeing Alice's block. The fact that a supermajority
sign the [NEC](#no-endorsement-message-and-no-endorsement-certificate)
is key: even if `f` nodes are Byzantine, that still leaves `f+1` non-Byzantine nodes attesting
to *not* seeing Alice's block, which guarantees that Alice's block should *not* have achieved
quorum since quorum requires `2f+1` votes and there were at least `f+1` non-Byzantine NO votes.
The [MonadBFT paper](https://arxiv.org/abs/2502.20692) provides a far more robust definition
of the protocol, and a formal proof that tail-forking cannot occur.
### Speculative Finality
The other extremely nice property of MonadBFT is one-slot speculative finality.
To explain this, it is first helpful to issue a reminder that a block's state is always from
the perspective of a particular observer. For example, if you receive a QC for a block, then
you can move that block to the [`Voted`](/monad-arch/consensus/block-states#voted) state, but if your friend didn't
receive that QC yet, then she would still consider that block to be in the
[`Proposed`](/monad-arch/consensus/block-states#proposed) state.
The challenge of building a distributed consensus mechanism lies in defining rules that allow
nodes to individually update their state machines in response to messages even while assuming
the worst, i.e. even while assuming that they might be the only one that received that message.
#### After receiving Alice's Proposal
Say that you are Valerie, one of the validators in the network. You receive Alice's proposal;
you run the validity checks on it and they pass, so you mark Alice's proposal as
[`Proposed`](/monad-arch/consensus/block-states#proposed).
Note that you don't know if anyone else has received this proposal, Alice could be being tricky
and have only sent the proposal to you (or to a very small number of nodes) in an attempt to
get you to diverge from everyone else.
#### After receiving Bob's Proposal
Now say you receive Bob's proposal, which carries a QC for Alice's proposal. You run validity
checks on Bob's proposal and they pass, so you mark Alice's proposal as
[`Voted`](/monad-arch/consensus/block-states#voted).
Again, although you now possess proof that a supermajority voted for Alice's proposal, you
should be worried that Bob might be trying to trick you by only sending this to you. You
should be worried that Bob's proposal doesn't reach quorum.
The superpower of MonadBFT is that, due to the complicated set of rules for handling a timeout
described earlier, when you are in Valerie's position of having received Bob's proposal, you
can mostly overpower that fear, at least as it pertains to the status of Alice's proposal. You
may **speculatively finalize** Alice's proposal upon moving it to the `Voted` stage. That is,
you can be confident that Alice's proposal will almost certainly end up being finalized, unless
a very specific set of rare circumstances arises.
Intuitively, this makes sense given what we said above. You, Valerie, possess a QC for Alice's
block, assembled by Bob. That actually means that, from your point of view, Bob was not offline.
And **even if** Bob were *effectively offline* to most people (e.g. he only sent the next
proposal and QC-on-Alice's-block to you), you know that the procedure will be to assemble a
TC; that the `high_tip` in that TC will probably point to Alice's block. Why? Because:
1. the QC in your hands proves that a supermajority (`2f+1`) has seen Alice's block,
2. the TC will also require a supermajority (`2f+1`)
3. So at least `f+1` voters will be common to both the QC and TC, and at most `f` are
Byzantine, so at least 1 will reference Alice's block.
And if Alice's block makes it into `high_tip`, then Charlie will be forced to re-propose it
(unless he could get a NEC on it, which he can't because that would require
No-Endorsement Messages from a supermajority, when a supermajority already signed a QC on
Alice's block).
So at first glance it seems like we, Valerie, might be able to finalize Alice's block as soon
as we receive a QC on it.
#### The only loophole
It turns out that there is one loophole which prevents us from being so confident. The loophole
arises if *Alice* **equivocated** -- signed a second block `b'` at the same height as the first
block `b` (which we have a QC for), and sent `b'` to a few nodes.
Under those circumstances, in the event where Bob sent his proposal only to us before going
offline, then it is possible that `high_tip` in the resultant TC will resolve to `b'` instead
of `b`. If that were to happen, then Charlie could end up either re-proposing `b'`, or
collecting an NEC on `b'` and using that to justify proposing a new block at Alice's block
height.
In practice, this loophole is extremely rare for several reasons:
1. Equivocation is an easily provable fault - all you need as evidence is both blocks at the
same height both signed by Alice. Equivocation is a huge deal in blockchains, and can be
severely punished.
2. When Alice equivocates, she is only potentially disrupting herself (while also exposing
herself to punishment for equivocation).
The [MonadBFT paper](https://arxiv.org/abs/2502.20692) provides a much more rigorous version
of this argument. But in summary, locally observing a QC (moving a proposal to `Voted`) is a
very strong indicator that the proposal will finalize, since the only way it won't is if Alice
equivocated, Bob missed his slot, almost 1/3 of the network was Byzantine, and we still got
quite unlucky with respect to which nodes ended up populating the TC.
## Fast Recovery
Since releasing the original [MonadBFT paper](https://arxiv.org/abs/2502.20692) in early 2025,
Category Labs has analyzed the protocol’s behavior and designed, evaluated, and implemented
several improvements.
The protocol changes allow for fast recovery in the most common failure scenarios.
This [blog post](https://www.category.xyz/blogs/monadbft-update-fast-recovery-leader-fault-isolation) gives a great introduction to how fast recovery
works. In summary:
* Validators now send their votes not only to the leader of the next view, but also to the leader of
the current view. This gives each leader a chance to collect votes for its own proposal to
form a QC, rather than relying solely on the next leader (who may be Byzantine). The leader
broadcasts this QC.
* Validators can include the highest QC that they have observed in their timeout message, instead
of the tip. They do so if the QC is fresher (more recent) than the locally highest tip or produced in the same
round as the tip.
* If a validator sends a tip (instead of a high QC) in a timeout message, the validator also
includes a tip vote, i.e., a vote for that tip with the current view number. `2f+1` votes
for the same proposal in the same view, obtained via regular votes or timeout messages can be
combined to form a new QC that can directly be extended by the next leader.
* The timeout certificate includes the highest QC of the received timeout messages if it is at least
as high as the highest tip. It also contains proof that the correct high tip or high QC was chosen.
If the TC contains the high QC, then the leader can directly propose a fresh block extending that high QC.
These mechanisms enable faster recovery in the most common failure scenarios. For example, consider a
situation where the leader in view `v` is offline. In the original MonadBFT protocol, this would cause
views `v-1` and `v` to time out (since the votes cast in `v-1` are lost, and no block is proposed in
view `v`). Additionally, the block proposed in view `v-1` would have to be reproposed in view `v+1`,
resulting in two consecutive views without a fresh block proposal.
With the updated protocol, several mechanisms enable faster recovery. For instance, in the timeout
message of view `v`, each validator includes a tip vote for the block proposed in view `v-1`. This
allows the leader of view `v+1` to construct a QC in view `v`. Since no two conflicting QCs can be
formed in the same view, the leader of `v+1` can directly propose a fresh block extending this QC.
As a result, a single crashed leader only causes the leader's view to time out; all other views
succeed, and in each of them, a fresh block is proposed.
The other mechanisms similarly provide fast recovery options. We still retain the reproposal and
[NEC](#no-endorsement-message-and-no-endorsement-certificate)
mechanisms from the original MonadBFT paper to address more complex Byzantine failures. However,
with these improvements, we believe most failures can now be handled smoothly via the new fast
recovery paths.
***
## References
* Mohammad Mussadiq Jalalzai, Kushal Babel.
[MonadBFT: Fast, Responsive, Fork-Resistant Streamlined Consensus](https://arxiv.org/pdf/2502.20692), 2025.
* Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham.
[HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069), 2018.
* Mohammad M. Jalalzai, Jianyu Niu, Chen Feng, Fangyu Gai.
[Fast-HotStuff: A Fast and Resilient HotStuff Protocol](https://arxiv.org/abs/2010.11454), 2020.
* Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang.
[Jolteon and ditto: Network-adaptive efficient consensus with asynchronous fallback](https://arxiv.org/pdf/2106.10362.pdf).
arXiv preprint arXiv:2106.10362, 2021.
* The Diem Team.
[DiemBFT v4: State Machine Replication in the Diem Blockchain](https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2021-08-17.pdf), 2021.