MonadBFT: two rounds to finality, and a block the next leader cannot throw away

A Byzantine fault tolerant protocol is a way for a set of machines, some of which may be lying, to agree on one history. MonadBFT is Monad’s version. It descends from the HotStuff family: a leader proposes a block, validators vote, and the next leader carries those votes forward so the network does not stop to hold a meeting. The Monad implementation pipelines that work. Voting on a new block overlaps with finishing the last one.

After MIP-12 the slot is 300 milliseconds. One round gives speculative finality. Two rounds give full finality, so a transaction included in block N is final when N+2 is proposed, about 600 milliseconds later. Speculative here is a precise word. The Foundation’s description says that early confirmation reverts only in uncommon cases that require the original leader to have equivocated, signing two conflicting things. It is not “probably fine”. It is “final unless a leader has already misbehaved in a way the protocol can prove”.

The tail fork

Pipelined leader protocols have a known sore. The leader of block N+1 can sometimes fork away block N, the “tail”, and with it the transactions a builder or a searcher had already paid to include. That is a form of miner-extractable value that does not look like a sandwich. It looks like a missing receipt. Monad’s documentation lists tail-fork resistance as a design property, not a hope. A leader is not supposed to be able to throw out the previous block to reorder someone else’s flow.

The other property that decides whether this stays a small club is message complexity. On the happy path, when no one is failing, MonadBFT is described as linear in the number of validators: each additional validator adds a constant amount of talk, not a square of it. That is what lets the set sit near 200 operators in more than 30 countries, the figure repeated in 2026 explainers, rather than a dozen machines in one data centre. Delegation is allowed. Proof of stake is the sybil resistance. A larger set is not the same thing as a fair set, but a protocol that cannot grow the set has already chosen the smaller one.

A tail fork is a deleted receipt. Resistance to it is a property of the protocol, or it is a press release.

What you should ask a block explorer

For a given transaction hash, three timestamps matter. When it was first seen in the mempool, if the explorer shows that. When it was included. When the block two ahead was proposed, which is when the inclusion stopped being speculative. If a product tells you a Monad trade is “instant”, ask which of those three it means. They are 300 milliseconds apart, and for a market-maker that gap is the whole trade.

One certificate, then a second

The clean path is a leader, a proposal, and a quorum of votes packed into a certificate. The next leader extends that certificate instead of opening a new argument about the same block. One certificate is the speculative stage. The Foundation’s account is specific about what can still undo it: the original leader would have had to equivocate, signing two conflicting things, which is a fault the protocol can show. A second certificate, on the block that builds on the first, is full finality. Two slots is not a slogan. It is those two certificates.

The path that is not linear

Message cost grows in a straight line only while leaders appear and nobody cheats. A missed slot is a timeout, and a timeout is a different conversation: the set has to agree the round failed before another round can start. That conversation is slower than 300 milliseconds. CertiK’s August reading put successful proposals at 99.903 percent. The interesting residue is the other 0.097 percent. Anything that must land inside a particular slot, a cancel included, has to have a plan for the hole and not only for the average.