
Category Labs Introduces Cadence, a Multi-Proposer Consensus Design for Monad
Overview
July 7, 2026. Category Labs has introduced Cadence, a Byzantine fault-tolerant consensus design built around multiple concurrent proposers and what the paper calls extreme pipelining.
The headline number is easy to notice: the paper evaluates a 100 ms block interval and reports sub-second finality figures in a Monad validator simulation. But the bigger signal is not just speed. Cadence is trying to change who controls transaction inclusion and how quickly on-chain markets can update.
Context
In most blockchains, each block still has a short-lived proposer or leader monopoly. That single party can decide what gets in, what stays out, and how transactions are ordered. Rotating that role spreads power over time, but it does not remove the moment-by-moment control inside one block.
Cadence goes after that directly.
What Cadence Changes
Operational Impact
Instead of one proposer controlling the block, Cadence uses multiple concurrent proposers. Several validators can contribute proposals for the same slot, and the protocol combines that work through consensus rather than adding a separate proposal-aggregation phase on top.
That distinction matters. Category Labs argues that many recent multi-proposer designs pay for proposer competition with an extra aggregation step, adding communication rounds before consensus can finish. Cadence tries to make the proposers part of consensus itself, so the fast path can still finalize in an optimal three communication rounds.
Operator Actions
The design also gives a slot speculative finality one round earlier. In the paper's framing, that speculative result is revertible only if a proposer provably equivocated. For applications that can distinguish between speculative and full finality, this is a meaningful latency layer.
Extreme Pipelining Is the Core Trick
The most important architectural idea is that Cadence does not make every block wait on the previous block's consensus artifact.
Risk Watch
It divides time into evenly spaced slots. Each slot contributes one block and runs its own independent consensus instance. Those instances can overlap, so the next slot can open before the prior one has fully finalized or even propagated across the network.
That is what the authors call extreme pipelining.
The result is that the block interval becomes a protocol parameter rather than being directly floored by network latency. Category Labs describes an initial target of 100 ms. At that cadence, a transaction waits on average about 50 ms to enter a proposal because the expected wait is half the block interval.

The in-article diagram is intentionally abstract, but the shape is the point: many proposer streams, many overlapping slots, and bounded parallel work rather than one serialized leader lane.
The Numbers From the Paper
The arXiv paper evaluates Cadence using estimated network delays between Monad mainnet's 200 globally distributed validators, with five proposers per slot.
The reported averages are:
- 219 ms to full finality
- 167 ms to speculative finality
- 50 ms average wait to enter a proposal at a 100 ms block interval
- 269 ms average end-to-end latency to full finality
- 217 ms average end-to-end latency to speculative finality
The paper also discusses an early-voting optimization that improves the end-to-end numbers further, to roughly 241 ms full and 187 ms speculative in the same simulation setup.
Those are simulation results, not production guarantees. Still, they show the design target clearly: keep block intervals short while avoiding the usual tradeoff where multi-proposer designs become slower because they need more coordination before consensus.
Why Builders Should Care
The most builder-relevant phrase in the paper is short economic ticks.
A shorter economic tick means applications can update state more frequently. That matters for systems where timing is part of the product:
- oracle price updates
- liquidations
- auctions
- perps and spot markets
- arbitrage-sensitive DeFi flows
- latency-sensitive consumer apps
If inclusion windows compress toward 100 ms, application designers get a different kind of chain surface. They are not only building on a faster EVM. They are building on a system where the time between market updates can shrink materially.
That is why this is more than a consensus-paper curiosity. If it reaches production, Cadence would affect how real applications think about pricing, rebalancing, auctions, and state freshness.
Why The MEV Angle Matters
Cadence also connects naturally to the MEV discussion.
The launch post frames Cadence alongside BTX, Category Labs' encrypted mempool design. The combination matters because multiple proposers and encryption solve different parts of the same problem.
Multiple concurrent proposers reduce dependence on one proposer for inclusion. Hiding means one proposer should not be able to observe the others' proposals early enough to react. Encrypted mempool work can further reduce the amount of transaction content visible before ordering decisions are made.
None of that magically eliminates MEV. But it does move the fight into the protocol layer instead of treating proposer discretion as an unavoidable application-level tax.
Why Validators Should Care
For validators, the practical takeaway is not "upgrade now." Cadence is a research and protocol-design announcement, not a current network release.
The operational signal is different: if Monad moves in this direction, validators should expect the bottleneck to keep shifting toward networking quality and timing discipline.
A Cadence-like system depends on things validators already care about:
- low-latency peer communication
- reliable authenticated UDP paths
- deterministic RaptorCast behavior
- clean clock synchronization
- observability around consensus message timing
- stable performance under many overlapping consensus instances
That last point is important. Extreme pipelining opens multiple slots concurrently, but the paper also introduces Conductor, an orchestrator that can throttle new slots during instability so outstanding work stays bounded. That is the kind of detail that separates a speed idea from something that could plausibly become deployable infrastructure.
The RaptorCast Connection
Cadence also builds on infrastructure that Monad operators have already seen in release notes and protocol work.
The paper discusses proposal dissemination as erasure-coded chunks, with validators voting on proposal digests rather than waiting for full data to arrive. The launch post explicitly points to Deterministic RaptorCast, now rolling out on Monad, as a component that Cadence can build on.
That connection matters because Cadence is not floating in isolation. It sits next to a broader Monad roadmap around authenticated networking, faster vote pacing, RaptorCast, asynchronous execution, and tighter consensus timing.
What To Watch Next
The next phase is implementation evidence.
Useful signals to watch:
- whether Cadence moves from paper and tutorial into a MIP or implementation track
- how RaptorCast rollout continues across testnet and mainnet
- whether validator telemetry starts exposing timing metrics relevant to overlapping slots
- how speculative finality is surfaced to applications
- whether BTX and encrypted mempool work moves closer to production integration
The research direction is strong, but production consensus is unforgiving. The interesting part now is how much of the paper's design can survive real validator behavior, real network jitter, and real application load.
Bottom Line
Cadence is not just another faster-blocks claim.
It is a serious attempt to combine three things that usually pull against each other: multiple proposers, low latency, and tighter control over proposer discretion.
For builders, the promise is a chain surface where markets can update more often and inclusion can happen faster.
For validators, the message is quieter but just as important: the future performance frontier is increasingly about networking, timing, and consensus discipline.
That is the real signal from Cadence.
- Cadence is Category Labs' multi-concurrent-proposer BFT consensus design.
- The paper reports 219 ms full finality and 167 ms speculative finality in Monad validator simulation.
- The main product shift is shorter economic ticks with less single-proposer control over ordering.
- Validators should watch RaptorCast, networking, clocks, and observability before any production path.
