Quantum Cadence, Part 2: How MonadBFT Paved the Way for Cadence

TL;DR

Quantum Cadence builds on years of work to make blockchain consensus faster, more resilient and less dependent on individual validators. This is Part 2 of a three-part series that explains Quantum Cadence, Category Labs’ post-quantum upgrade to their consensus protocol Cadence. Part 1 covered the core concepts of consensus. This blog covers how consensus has evolved from traditional BFT to MonadBFT and Cadence, and why these advances are important for building faster, more resilient and censorship-resistant blockchains.

A quick recap on how consensus works

Part 1 introduced the basic challenge of consensus: how can a group of validators agree on the same transaction history when some of them may behave dishonestly? We followed the example of a committee sitting at a table to explain the process. Each member represents a validator, and for every item on the agenda (a block), they must agree on one answer.

Alice, Bob and Carol follow the rules, while Eve represents a Byzantine validator who may behave dishonestly. With $n$ members of whom at most $f$ lie, $n = 3f + 1$, and more than two-thirds of the seats, $2f + 1$, is a quorum, “two-thirds” for short.

A chair (the leader), puts a proposal on the table, and members vote on it with a show of hands. An item is voted on when two-thirds raise their hands for it, and is final when two-thirds say they saw that first show of hands. If members act on the first vote, it is considered speculative finality. A member can show its vote in three ways:

1. a raised hand convinces only the room
2. a signed ballot convinces anyone
3. a tally sheet, two-thirds of matching ballots stapled together, convinces anyone that two-thirds agreed.

The Monad blockchain uses BLS signatures to compress all these votes into a single signature. These tally sheets are called certificates.

From classic BFT to MonadBFT

How MonadBFT gets more work done in each round

Start with classic Byzantine fault-tolerant (BFT) consensus. In each round the chair shows an item and the members vote. The same chair, Alice, runs every round, and each item takes two rounds, one to vote and one to vote again on the tally sheet. MonadBFT, the consensus Monad runs today, keeps the room and the ballots and changes four things.

The diagram below shows how Classic BFT and MonadBFT would work in each round.

1. A new chair every round: Alice, Bob, Carol, and Eve (even though Eve is Byzantine) take turns as leaders. Here, Eve follows the rules.
2. Votes go to the next chair: When Alice proposes block N, validators send their votes to Bob.
3. The tally sheet carries over to the next block: Bob collects the votes for block N, staples them into a tally sheet (certificate) and includes it in the proposal for block N+1. This means the process of confirming one block overlaps with proposing the next.
4. Act on the first vote: When Bob’s item N+1 arrives with the tally sheet on N, N is voted and members may act on it (speculative finality). When Carol’s item N+2 arrives with the tally sheet on N+1, N is final.

In the simplified classic BFT example, four rounds produce two blocks. With MonadBFT, four rounds can start four blocks and a new block can be finalized every round.

On Monad, rounds take approximately 300 milliseconds. That means a block can be acted on speculatively after approximately 300 milliseconds and reaches finality after approximately 600 milliseconds under normal operation.

MonadBFT makes consensus faster by overlapping work. However, one important constraint remains: a single leader still controls which transactions are proposed in each round. Cadence addresses that limitation.

Cadence: from one leader to multiple proposers

Why multiple proposers matter

In leader-based consensus, one member (validator) is responsible for proposing the contents of each block. Even when leadership rotates, that member has significant influence over which transactions make it into the block and when.

This creates three challenges.

1. Censorship: The chair can drop a note, and in that round nobody else can put it in. With several proposers, you hand your note to two of them, and any honest one can propose it. No single proposer decides what goes into the block, so none holds a monopoly over it. That is censorship resistance.
2. Latency: Transactions may take longer to reach a member located far away. With several members, one is likely to be close, so your note gets in sooner, lowering latency.
3. Downtime: If a leader stops responding, everyone has to wait for a timeout before moving forward. If there are multiple proposers, proposals will reach another proposer and the room can vote.

Cadence introduces this model through multiple concurrent proposers: several validators can submit proposals for the same block at the same time.

Instead of one validator deciding which transactions are eligible for inclusion, multiple proposers contribute to the process. This reduces the influence any individual proposer has over transaction selection and improves the network's ability to continue making progress when some validators are unresponsive.

Multiple proposers are one of Cadence's two major advances. The other changes how frequently blocks can begin.

From network-paced blocks to clock-driven blocks

MonadBFT uses pipelining to overlap consecutive blocks, but the next proposal still depends on votes from the previous one. This means communication between validators helps determine how quickly new blocks can start.

Cadence takes a different approach. Rather than waiting for the previous block's voting process, Cadence starts a new consensus instance every 100ms.

Cadence opens a new room (known as a slot) every 100 ms, whether or not the earlier one has finished. That is extreme pipelining. Each slot is a separate meeting on its own item, with a few proposers named by a schedule. The same committee votes in every slot. A slot decides on its own, about 200 ms after it opens. Slots can also finish out of order. If one encounters delays or requires additional rounds of agreement (see item N+2 in the figure above), later slots continue progressing independently. The record of what each slot decides (the minutes) are filed in order, so the chain is still one ordered list.

This creates an important distinction between block time and finality time. Block time determines how frequently new slots begin. Finality time determines how long the network takes to reach agreement on the result of a slot. By separating the two, Cadence can start a new slot every 100 milliseconds even when messages between validators take longer than 100 milliseconds to arrive.

Cadence as a whole

Put together, Cadence has two key components.

1. Conductor: It keeps the schedule. Every 100 ms it opens a new slot. The Conductor is not a member and it does not rotate: every member runs the same schedule rule on synchronized clocks, so all members open the same slot at the same time.
2. Chorus: It is what happens inside each slot, and it runs like a round of MonadBFT. A few proposers hand out their proposals, and the whole committee votes on all of them at once, with the same two shows of hands as before: one to vote, and one to say “I saw two-thirds vote”. Members may act after the first, and the item is final after the second. If the vote is split, or messages come too slowly, members wait for a time limit and a second meeting takes over, slower, but sure to end once messages flow on time.

Together, the Conductor opens slots and Chorus runs each slot.

At the first vote every member signs a ballot per proposer, and two-thirds of matching ballots are stapled into a tally sheet: the slot's item is voted, and members may act on it. At the second vote, members sign ballots confirming the result, and two-thirds of them, make it final. In Chorus, the second meeting is a multi-valued validated Byzantine agreement (MVBA): it agrees on one version of the room’s result and lets in only versions backed by tally sheets.

Members stay in step by mail: every member mails its tally sheets to every other member, with no chair collecting them, so every member ends up with the same result. Nobody is in charge of the minutes: every member files its own copy, in slot order and by the same fixed rules, so all copies match. Members also sign the state the minutes lead to, the balances after running the transactions, for anyone who needs to check it.

Opening a slot every 100 ms has one risk: if slots finish late, unfinished ones pile up. So the Conductor schedules slots in batches. Once a sufficient number of slots in a batch finish, validators agree on when the next batch starts: on time if those slots kept up, later if they fell behind.

Together, these mechanisms allow Cadence to combine frequent block production, concurrent proposals and consistent ordering across the validator network.

From Cadence to Quantum Cadence

Cadence represents a significant evolution from traditional leader-based consensus. Multiple concurrent proposers reduce dependence on individual validators, while extreme pipelining allows the network to start new blocks every 100 milliseconds without waiting for earlier slots to finish.

The protocol still relies heavily on digital signatures and quorum certificates. These cryptographic tools are essential for proving that validators have voted, establishing agreement and allowing participants to verify the results. They also introduce a challenge as quantum computing advances.

Large-scale quantum computers could break some of the signature schemes used in today's blockchain consensus protocols. Replacing those schemes is not straightforward, particularly when consensus depends on exchanging and aggregating signatures efficiently.

That is the problem Quantum Cadence is designed to address. We'll explore that in Part 3.

References

• M. M. Jalalzai, T. Klenze, J. Komatovic. Quantum Cadence: Post-Quantum Consensus with Multiple Concurrent Proposers. arXiv:2610.32803, 2026.
• K. Babel, F. Elsheimy, L. Heimbach, M. M. Jalalzai, T. Klenze, J. Komatovic, J. Milionis, M. Setrin, V. Shoup. Cadence: Extreme Pipelining with Multiple Concurrent Proposers. arXiv:2607.02275, 2026.
• M. M. Jalalzai, K. Babel. MonadBFT: Fast, Responsive, Fork-Resistant Streamlined Consensus. arXiv:2502.20692, 2025.