arXiv: 2607.02275 · PDF: pdf · Published: 2026-07-02

TL;DR

Cadence is a Byzantine fault-tolerant consensus protocol that finalizes blocks at arbitrarily low block intervals by running each slot as an independent consensus instance — no slot waits for its predecessor to finish or propagate. It also drops the single-leader model in favor of multiple concurrent proposers (MCP) per slot, giving short-term censorship resistance and “hiding” (a proposer can’t craft its proposal in reaction to others’). In simulation over Monad’s 200 validators with five proposers per slot, finalization averages 219 ms (167 ms speculative), and at a 100 ms block interval a transaction waits ~50 ms on average to enter a proposal.

Why it matters

Nearly every production BFT protocol today (HotStuff, Tendermint, Jolteon, and their descendants) is bottlenecked by a chain of block dependencies: block n+1 can’t be proposed until n has been seen, so the practical block interval collapses toward network diameter. Cadence’s “extreme pipelining” — slot consensus instances that don’t build on each other — is the same trick that made instruction pipelining a superscalar win: independent stages, no data hazard.

The MCP angle is arguably more interesting for the MEV/censorship debate: single-leader protocols give one validator per slot unilateral ordering power, and rotating leaders doesn’t fix the per-slot monopoly. Cadence guarantees that under synchrony, a transaction that any correct proposer includes cannot be censored or deferred in that slot.

Contribution stack

  • A framework that lifts any one-shot consensus meeting a “slot-consensus” spec into a pipelined multi-shot protocol.
  • Chorus — the slot-consensus instantiation: 3-round fast path with 1 round of speculative finality.
  • Conductor — the orchestrator that opens slots at a steady cadence and throttles under asynchrony to keep the number of open slots bounded.
  • Safety, liveness, censorship-resistance, and hiding proofs under partial synchrony with optimal resilience (n = 3f+1) and optimal fast-path latency.

Authors

See the arXiv listing for the full author roster.