Multiple Concurrent Proposers (MCP)

• Multiple Concurrent Proposers (MCP) are blockchain consensus protocols where multiple validators simultaneously propose blocks, reducing the monopolistic control of a single proposer.
• MCP employs techniques such as parallel slot consensus, threshold cryptography, and data availability to ensure censorship resistance, fast finality, and proposal hiding.
• Implementations like Cadence, Chorus, and Conductor demonstrate MCP's potential to lower MEV opportunities while introducing new strategic challenges in transaction ordering.

Multiple Concurrent Proposers (MCP) denotes a class of blockchain consensus settings in which several validators propose concurrently within the same slot or tick, rather than a single proposer holding a serial monopoly over transaction inclusion and ordering. The core motivation is the relation between proposer monopoly and maximal extractable value (MEV): traditional single-proposer blockchains suffer from MEV because validators can exploit their serial monopoly on transaction inclusion and ordering to extract rents from users, while efficient on-chain auctions require selective-censorship resistance and hiding (Garimidi et al., 28 Sep 2025). In later formalizations, MCP is developed as Byzantine fault-tolerant multi-proposer consensus in which several validators propose for each block, and the protocol guarantees short-term censorship resistance and hiding together with optimal resilience and fast-path latency under partial synchrony (Elsheimy et al., 2 Jul 2026).

1. Motivation and problem setting

The initial MCP motivation is explicitly tied to MEV. Traditional single-proposer blockchains suffer from miner extractable value because validators exploit their serial monopoly on transaction inclusion and ordering to extract rents from users. Application-layer countermeasures exist, but these approaches largely require auctions as a subcomponent. Running auctions efficiently on chain requires two key properties of the underlying consensus protocol: selective-censorship resistance and hiding. These properties guarantee that an adversary can neither selectively delay transactions nor see their contents before they are confirmed; the MCP proposal is introduced as a protocol offering exactly these properties (Garimidi et al., 28 Sep 2025).

Subsequent MCP work broadens the systems perspective. Cadence describes MCP as removing the single-leader monopoly over transaction inclusion and ordering: under multiple concurrent proposers, several validators propose for each block, and, under synchrony, a transaction a correct proposer includes cannot be censored or deferred, while no proposer can craft its proposal in reaction to the others' (Elsheimy et al., 2 Jul 2026). The same line of work also decouples the block interval from network latency by letting blocks finalize in independent consensus instances rather than directly building on their predecessor.

The MEV literature identifies the other side of the same design choice. In an MCP chain, multiple blocks become data available before their final execution order is determined. As soon as a proposer’s block hits a Data Availability layer it becomes data-available to the world, but consensus will not linearize those blocks until an end-of-tick phase; concurrency therefore arises because multiple blocks and their transactions are public before the protocol picks a unique inter-block order, creating MEV opportunities not present in single-builder chains (Landers et al., 17 Nov 2025). This establishes MCP as a trade-off space rather than a one-dimensional improvement: eliminating the single-leader bottleneck changes both censorship properties and the structure of strategic behavior.

2. Formal model and protocol-level guarantees

A formal MCP definition is given in Cadence. Validators satisfy $n = 3f + 1$, with up to $f$ Byzantine. Time is divided into an infinite sequence of numbered slots $s \in \mathbb{N}_+$. Each slot $s$ has a fixed size-$k$ subset of validators $s.\mathrm{proposers}$ and a deadline $s.\mathrm{deadline}$, spaced $\tau$ apart, with

$$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$

Each proposer $p \in s.\mathrm{proposers}$ holds exactly one proposal

$f$0

Each validator $f$1 maintains an append-only log $f$2 of proposal-vectors $f$3, where a proposal-vector maps $f$4 to either a proposer’s $f$5 or $f$6; a slot may be skipped. The interface is correspondingly simple: slot proposers submit their proposals to $f$7, and validators grow their logs as slots finalize (Elsheimy et al., 2 Jul 2026).

Under partial synchrony, the guarantees are stated with $f$8 for global stabilization time, $f$9 for the post-$s \in \mathbb{N}_+$0 network bound, $s \in \mathbb{N}_+$1 for actual delay, and grace periods $s \in \mathbb{N}_+$2 and $s \in \mathbb{N}_+$3. Safety requires that for any correct $s \in \mathbb{N}_+$4 and any times $s \in \mathbb{N}_+$5, $s \in \mathbb{N}_+$6 and $s \in \mathbb{N}_+$7 are consistent, meaning one is a prefix of the other. $s \in \mathbb{N}_+$8-liveness requires that every sufficiently late slot is eventually appended by every correct validator. $s \in \mathbb{N}_+$9-censorship resistance requires that for every sufficiently late slot, every honest proposer’s proposal appears in the finalized vector. Hiding is simulation-based: there exists a simulator $s$0 such that the real-world execution of slot consensus is indistinguishable from an ideal functionality $s$1 that hides honest proposals until the deadline, lets Byzantine proposers submit multiple proposals before the deadline, and after the deadline learns honest proposals and returns to the adversary the set of included proposals.

The literature also uses MCP in broader formulations. In Sedna’s dissemination model, multiple-concurrent-proposers consensus proceeds in slots $s$2, and in each slot every validator $s$3 proposes a block $s$4; consensus finalizes the entire vector $s$5 (Ranchal-Pedrosa et al., 18 Dec 2025). In the MEV model, an MCP chain may have $s$6 proposers who each may publish one or more blocks every tick (Landers et al., 17 Nov 2025). These formulations are not identical, but they share the defining feature that several proposers are concurrently active before execution order is fixed.

3. Cadence, Chorus, and Conductor

Cadence organizes MCP as an extreme-pipelining framework that composes two black boxes: a one-shot Slot Consensus for each slot and an Orchestrator that decides which slots to open or skip (Elsheimy et al., 2 Jul 2026). Slot Consensus exposes $s$7, $s$8, $s$9, and $k$0, with guarantees of agreement, termination, slot safety, proposal inclusion, and hiding. The Orchestrator exports $k$1 as input and $k$2 as output, and satisfies totality, integrity, monotonicity, $k$3-boundedness, and $k$4-recovery. Cadence then runs one Orchestrator $k$5 and one SlotConsensus instance $k$6 per slot. When $k$7 fires, validators participate in $k$8, and proposers submit their proposals; when $k$9 finalizes, the instance is abandoned, the result is buffered, and vectors are appended in slot order. The framework theorem states that if $s.\mathrm{proposers}$0 satisfies boundedness and recovery and each $s.\mathrm{proposers}$1 satisfies its five guarantees, then Cadence solves MCP with $s.\mathrm{proposers}$2, $s.\mathrm{proposers}$3, and hiding.

The concrete slot-consensus protocol is Chorus. It assumes $s.\mathrm{proposers}$4 and uses threshold IB-KEM, erasure coding, Merkle commitments, signatures, and random oracles. In Phase I, proposer dissemination begins at time $s.\mathrm{proposers}$5: a proposer forms $s.\mathrm{proposers}$6, encapsulates under a slot-specific identity, pads and encrypts the payload, splits the encrypted payload into $s.\mathrm{proposers}$7 erasure-coded fragments, computes a Merkle root over fragment hashes, signs it, and sends one chunk to each validator. In Phase II, validators collect chunks until the deadline; for each proposer they record either a valid entry or a $s.\mathrm{proposers}$8-entry, and at the deadline they broadcast signed entries together with their own decryption share. In Phase III, the fast path builds $s.\mathrm{proposers}$9 when at least $s.\mathrm{deadline}$0 identical votes exist for proposer $s.\mathrm{deadline}$1; once this exists for all $s.\mathrm{deadline}$2, validators form a fast meta-block, send $s.\mathrm{deadline}$3, broadcast $s.\mathrm{deadline}$4, and speculatively finalize. If at least $s.\mathrm{deadline}$5 commit votes for the same entries are collected, a $s.\mathrm{deadline}$6 is broadcast and the vector is finalized. Chorus also includes a fallback path using fallback votes, per-proposer evidence, a fallback certificate, and an $s.\mathrm{deadline}$7 decision procedure.

Its data-availability procedure rebroadcasts valid chunks, stores fragments, decodes when at least $s.\mathrm{deadline}$8 fragments are available, verifies the Merkle root, and decapsulates when at least $s.\mathrm{deadline}$9 valid shares have been collected; $\tau$0 waits until each entry is either a plain proposal or invalid and then returns the proposal-vector. The stated properties are agreement, termination, slot safety, proposal inclusion, and hiding. Termination is bounded by $\tau$1 if all validators start by $\tau$2. The fast-path latency is two communication rounds, with time $\tau$3, where $\tau$4, and speculative finality occurs at $\tau$5. An early-voting optimization allows voting as soon as all Merkle roots arrive and can save up to $\tau$6.

The orchestrator is Conductor. It uses windows of size $\tau$7, a readiness threshold $\tau$8, ACS-latency $\tau$9, Chorus open-to-complete delay $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$0, slot spacing $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$1, and the post-$$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$2 bound $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$3. Under four stated inequalities, it opens slots $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$4 at startup, records completed slots, proposes the next estimated slot when the first $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$5 slots in the current window are done, and uses ACS decisions to schedule the next window. The correctness theorem gives integrity, monotonicity, $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$6-boundedness, and $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$7-recovery. In simulation over Monad’s 200 validators with five proposers per slot, Cadence reports average speculative finality of $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$8 ms, average full finality of $$\forall s>1,\qquad s.\mathrm{deadline} = (s-1)\tau + \Delta.$$9 ms, average wait to enter a proposal of $p \in s.\mathrm{proposers}$0 ms at $p \in s.\mathrm{proposers}$1 ms, end-to-end latency of $p \in s.\mathrm{proposers}$2 ms speculative and $p \in s.\mathrm{proposers}$3 ms full, and an early-voting saving of approximately $p \in s.\mathrm{proposers}$4 ms.

4. Transaction dissemination and the user-facing trilemma

MCP consensus does not by itself determine how users should disseminate transactions to proposers. Sedna isolates this submission-layer problem and argues that MCP alone does not resolve how users should disseminate transactions: users either naively replicate full transactions to many proposers, sacrificing goodput and exposing payloads to MEV, or target few proposers and accept weak censorship and latency guarantees (Ranchal-Pedrosa et al., 18 Dec 2025). The resulting trilemma is explicitly stated as censorship resistance, low latency, and reasonable cost. Under naive replication, sending a full transaction to $p \in s.\mathrm{proposers}$5 distinct proposers gives bandwidth overhead $p \in s.\mathrm{proposers}$6, and to tolerate censorship by up to $p \in s.\mathrm{proposers}$7 malicious proposers one chooses $p \in s.\mathrm{proposers}$8. Under minimal targeting, bandwidth is $p \in s.\mathrm{proposers}$9, but if the chosen proposer censors, the sender must retry sequentially.

Sedna replaces naive transaction replication with verifiable, rateless coding. For a transaction, the sender forms

$f$00

computes a commitment $f$01, a header, a transaction identifier $f$02, and a signature $f$03. A verifiable rateless encoder $f$04 then produces an unbounded sequence of symbols $f$05, and the decode threshold is

$f$06

To send symbols to lane $f$07, the sender forms either individual shares or a bundle

$f$08

where $f$09 signs the lane identifier, symbol indices, and symbols. Validators verify the header-derived $f$10, the header signature, the bundle signature, and a local fee or accounting predicate before admitting the bundle to the mempool.

The correctness and liveness statements are phrased in terms of finalized bundles. Deterministic execution order is obtained by sorting included transactions by $f$11, where $f$12 is the height at which decoding succeeds. Under adversarial censorship, if $f$13 is the effective number of lanes the adversary can censor, $f$14 lanes are addressed, and $f$15 symbols are sent per lane, then the number of honest addressed lanes is

$f$16

and the single-slot success probability satisfies

$f$17

If the sender resamples a fresh subset of $f$18 lanes each slot, the time to inclusion is stochastically dominated by $f$19.

Sedna’s privacy notion is until-decode privacy. If the adversary has seen at most $f$20 symbols, then

$f$21

This bounds pre-decode leakage by at most $f$22 bits and is presented as a way to reduce MEV exposure relative to naive replication, where any adversarial lane immediately sees the entire payload. Analytically, Sedna approaches the information-theoretic lower bound for bandwidth overhead, with asymptotic overhead

$f$23

and reports a $f$24-$f$25 efficiency improvement over naive replication. It requires no consensus modifications, enabling incremental deployment.

5. MEV channels specific to MCP

The concurrency of MCP creates MEV channels that do not arise in the single-builder model. The MCP MEV analysis introduces a hazard-normalized model in which a proposer decides for each transaction $f$26 whether to include immediately or delay inclusion by time $f$27 to harvest MEV (Landers et al., 17 Nov 2025). With hazard $f$28, gross MEV accrual

$f$29

and realized MEV component

$f$30

the proposer’s per-transaction payoff is

$f$31

The delay envelope is

$f$32

and, writing $f$33, the closed form is

$f$34

The immediate-inclusion threshold is

$f$35

Three MCP-specific channels are then identified. First, same-tick duplicate steals occur when one proposer observes a transaction in another proposer’s block and republishes a duplicate quickly enough to win ordering priority in the same tick. If $f$36 is the probability of a successful duplicate steal and $f$37 is the probability that the original proposer misses the tick while the thief still makes it, then theft is profitable iff

$f$38

or equivalently

$f$39

With multiple identical potential thieves, the game becomes an all-pay contest.

Second, proposer-to-proposer auctions arise because there is no global mempool and a proposer who privately sees $f$40 may auction the right to include it. If the proposer internalizes the opportunity, the payoff is $f$41. If instead the proposer runs an auction at delay $f$42, bidder $f$43’s value is

$f$44

Under i.i.d. regular assumptions, the seller compares $f$45 with $f$46, the Myerson-optimal one-shot auction revenue.

Third, timing races are driven by proof-of-availability latency. If a user reveals early in a tick, a competitor can either send immediately or wait until observing the reveal on the DA layer and then snipe. The best-response condition is

$f$47

Under stated conditions, there is a unique last send-time $f$48 in the normalized tick, producing within-tick deadline pressure. Collectively, these channels show that MCP does not eliminate MEV; it redistributes it into same-tick competition, auctioning, and latency races.

6. Mitigation strategies and broader implications

Mitigation proposals in the literature operate at different layers. For execution ordering, the MEV analysis proposes Deterministic Priority-DAG Scheduling (PDM): after consensus selects the set $f$49 of proof-of-availability-certified blocks in a tick, a dependency DAG $f$50 is formed and each transaction $f$51 is assigned the lexicographic priority key

$f$52

A max-heap over DAG sources then yields a unique deterministic linear extension that respects dependencies and is monotone in $f$53 (Landers et al., 17 Nov 2025). The same work also proposes duplicate-aware payouts: if $f$54 in-tick duplicates are revealed, only one logical transaction is executed, but the posted tip is split equally so each proposer receives $f$55. Together with a modest base fee, these measures are presented as driving duplicate steals, proposer auctions, and timing races arbitrarily close to zero without centralizing block-building.

At the submission layer, Sedna keeps consensus unchanged and moves redundancy control to users. It is entirely at the submission and mempool layer, speaks the same block-proposal API, supports lazy execution because MCP protocols execute only after finality, and permits incremental rollout in which some users continue naive replication while others adopt coded bundles (Ranchal-Pedrosa et al., 18 Dec 2025). This makes dissemination policy orthogonal to consensus choice.

At the consensus layer, Cadence proves safety, liveness, censorship resistance, and hiding under partial synchrony with optimal resilience $f$56, and its simulations place speculative and full finality in the hundreds of milliseconds with five proposers per slot (Elsheimy et al., 2 Jul 2026). A plausible implication is that MCP research now spans three coupled problems rather than one: consensus construction, user-facing dissemination, and execution-order design. Across the cited work, MCP is therefore best understood not merely as “more proposers,” but as a family of protocols whose central question is how to preserve censorship resistance and hiding while controlling the new strategic surface created by concurrent proposal visibility.