Solana's Multiple Concurrent Leaders: Solving MEV or Creating a Consensus Nightmare?

General
1

I’ve been following Solana’s roadmap closely, and the Multiple Concurrent Leaders (MCL) proposal—also known as Constellation—is one of the most ambitious consensus redesigns I’ve seen in the space. But I’m genuinely torn on whether this is brilliant or dangerous.

The Single-Leader Problem

Right now, Solana’s consensus model assigns one validator as the “leader” for each slot. That leader has complete control over which transactions to include and in what order. The result? $720.1 million in MEV extracted in 2025 alone. Jito tips accounted for over 22% of total validator rewards. That’s not just rent-seeking—it’s a fundamental centralization vector.

The single-leader model allows validators to:

  • Reorder transactions for profit (sandwich attacks, front-running)
  • Censor specific transactions
  • Extract maximum value before passing the block downstream

Enter Multiple Concurrent Leaders

The Constellation protocol aims to fix this by allowing 16 proposers to simultaneously submit transactions. Here’s how it works:

  1. Users send transactions to multiple proposers (not just one leader)
  2. Each proposer creates erasure-coded “pslices” and sends them to 200 attesters
  3. Attesters timestamp and forward pslices to the leader with attestations
  4. Leader compiles all transactions that have enough attestations (60% threshold)
  5. Batches are created within sequential compute limits

The idea is that no single entity controls ordering anymore. Instead, consensus emerges from 16 parallel lanes.

Fee Structure

  • Inclusion fees: Paid to the validator who includes your transaction
  • Ordering fees: Paid to the protocol (burned)

This creates a market where users can pay for faster inclusion without paying for ordering manipulation.

My Technical Concerns

As much as I want this to work, I see three major issues:

1. Consensus Complexity

When 16 proposers submit conflicting transactions, how does the leader decide which ordering wins? The whitepaper mentions attestation thresholds (ATTESTATION_THRESHOLD=0.6, INCLUSION_THRESHOLD=0.4), but what happens when two valid orderings both cross the threshold? Does the leader have ultimate authority—making this just single-leader with extra steps?

2. State Invalidation Cascades

Imagine Transaction A is valid in Proposer 1’s lane but conflicts with Transaction B in Proposer 2’s lane. Both get attested. The leader includes both. One will fail on-chain. How do wallets handle this? Do users need to monitor multiple lanes and resubmit? This feels like a UX nightmare.

3. New MEV Vectors

If proposers can communicate off-chain (and they will), what stops them from colluding? A cartel of 10 proposers could:

  • Coordinate to reorg each other’s blocks
  • Share MEV profits via side channels
  • Effectively recreate the single-leader problem at the proposer level

The paper doesn’t address proposer collusion resistance.

Why Isn’t Ethereum Doing This?

Ethereum went a different route: Proposer-Builder Separation (PBS). Instead of distributing proposal rights, Ethereum separates proposing from building. Builders compete to create the most profitable blocks, and proposers just sign them.

PBS centralizes building but keeps proposing decentralized. MCL decentralizes proposing but could centralize attestation (if attesters collude).

Different philosophies:

  • Ethereum: “Let’s accept that building is centralized and regulate it”
  • Solana: “Let’s distribute proposal rights and see what emerges”

Neither is obviously correct.

Open Questions

I’d love to hear from the community:

  1. How do you prevent proposer cartels? Is there a cryptoeconomic mechanism I’m missing?
  2. What’s the failure mode? If attesters go down or collude, does the chain halt or fall back to single-leader?
  3. Can this actually work at scale? 16 proposers × 200 attesters = 3,200 communication channels per slot. That’s a lot of overhead.
  4. Why the 60% attestation threshold? Why not 67% (BFT standard) or 51%?

I’m cautiously optimistic, but I need to see the test data. Does anyone have links to the testnet implementations? I’d love to run some simulations.

Sources

2

Brian raises critical concerns, but I want to dive deeper into the attack surface expansion that MCL introduces.

Attestation as a New Attack Vector

The 60% attestation threshold (ATTESTATION_THRESHOLD=0.6) creates a new griefing vector that doesn’t exist in single-leader models. Consider:

  • 200 attesters × 16 proposers = 3,200 message paths per slot
  • If just 40% of attesters are compromised or offline, transactions can’t be included
  • This is a liveness attack surface that single-leader models don’t have

Compare this to Ethereum’s PBS: builders submit sealed bids, proposers choose one. If a builder is malicious, you reject their block. Simple. With MCL, if 80 attesters go down simultaneously (40% of 200), the entire chain could stall.

Erasure Coding ≠ Security

The Constellation whitepaper leans heavily on erasure coding for censorship resistance. But erasure coding is a data availability guarantee, not a security primitive. It ensures data can be reconstructed from partial fragments—it doesn’t prevent:

  1. Attester collusion: If 60% of attesters coordinate, they control which transactions get included
  2. Timing attacks: Attesters could selectively delay timestamps to favor certain proposers
  3. Sybil attacks on attesters: Who chooses the 200 attesters? If attester selection is stake-weighted, large validators could run 120+ attesters (60% threshold) and we’re back to centralization

The Auditing Nightmare

As a security researcher, here’s what terrifies me: How do you audit 16 concurrent proposers?

In a single-leader model, if something goes wrong, you trace the bug to one validator’s block production logic. With MCL:

  • Was it Proposer 7’s pslice that caused the state conflict?
  • Did Attester 142’s timestamp validation fail?
  • Did the leader’s batch compilation logic drop valid transactions?

Post-mortem analysis becomes exponentially harder. In 2025, Halborn identified 122 incidents due to proxy/upgradeability issues (OWASP #10). Imagine debugging those across 16 proposers with non-deterministic ordering.

The 0.6 Threshold Seems Arbitrary

Brian asked, “Why 60% instead of 67% (BFT standard)?” I’ll go further: Why not 80% or 90%?

Lower thresholds = faster inclusion but weaker censorship resistance
Higher thresholds = stronger guarantees but more liveness risk

60% feels like a compromise that satisfies neither goal. With only 60% attestation, a well-resourced attacker controlling 41% of attesters can selectively censor transactions while still allowing the chain to progress. That’s not censorship resistance—that’s selective censorship.

What I’d Need to See

Before MCL goes to mainnet, I’d want:

  1. Formal verification of the attestation protocol: Not just simulations, but proofs that the system is live under adversarial conditions
  2. Economic analysis of attester incentives: What prevents attesters from colluding? Are there slashing conditions?
  3. Red team exercises: Let a security team try to break it. Can they censor transactions? Extract MEV? Cause reorgs?
  4. Testnet data: What’s the actual latency distribution? How many transactions fail due to state conflicts?

I appreciate Solana pushing the boundaries, but every line of consensus code is a potential vulnerability. MCL adds thousands of lines.

Trust but verify—then verify again.

Sources

3

As someone who spends way too much time analyzing on-chain data, I wanted to break down the MEV numbers and see if MCL actually solves the problem or just redistributes it.

The M Question

Brian mentioned that Solana extracted $720.1M in MEV during 2025. Let me add context to that number:

  • Jito tips: 3.75 million SOL in tips over the year
  • Validator rewards: Jito tips = 22% of total validator rewards
  • Bundle volume: 3+ billion bundles processed via Jito

That’s not just a rounding error—that’s a fundamental revenue stream for validators. Which raises the question: if MCL eliminates MEV, where does that 22% of validator income go?

Where Does MEV Come From?

I pulled data from Solana’s 2025 MEV patterns. Here’s the breakdown:

  1. Sandwich attacks: ~45% of MEV (front-run user txs, profit from slippage)
  2. Arbitrage: ~35% (cross-DEX price differences, liquidations)
  3. Front-running: ~15% (generic front-running of high-value txs)
  4. Other: ~5% (back-running, long-tail strategies)

Key insight: Arbitrage MEV (35%) is actually good for the ecosystem—it keeps prices efficient across DEXes. Sandwich attacks (45%) are purely extractive. MCL needs to eliminate the bad MEV without killing the good.

Will MCL Actually Reduce MEV?

Here’s where I’m skeptical. MCL introduces:

  • 16 proposers competing for inclusion fees
  • 200 attesters validating and timestamping
  • Ordering fees burned by the protocol

But: If a searcher can still see the mempool (or monitor multiple proposers’ lanes), they can still:

  1. Identify a victim transaction in Lane A
  2. Submit a front-run transaction to Proposer 1 with a higher inclusion fee
  3. Submit a back-run transaction to Proposer 2

The MEV still exists—it’s just now distributed across 16 lanes instead of 1.

Sophia’s right that attesters become the new bottleneck. If I control 60% of attesters, I can:

  • Delay timestamps for competing MEV bots
  • Prioritize my own transactions
  • Effectively recreate the single-leader monopoly at the attestation layer

The Data I’d Want to See

Before we can say MCL “fixes” MEV, I’d need:

  1. Testnet MEV metrics:

    • What’s the distribution of inclusion fees across proposers?
    • Are certain proposers getting more MEV-heavy transactions?
    • Is there evidence of proposer cartels forming?

  2. Latency analysis:

    • How much does erasure coding + attestation add to confirmation time?
    • At what point does latency become a competitive disadvantage?

  3. Fee market dynamics:

    • Do inclusion fees converge across proposers (competitive market)?
    • Or do users pay more total fees (inclusion + ordering) than before?

  4. Attester behavior:

    • Are attesters independent, or are they clustered by stake?
    • What % of attesters are run by the same entities as proposers?

My Prediction

Based on previous MEV research (Ethereum’s PBS, Flashbots data), here’s what I think will happen:

  1. Phase 1 (Months 0-6): MEV decreases initially as bots adapt to new architecture
  2. Phase 2 (Months 6-12): Sophisticated searchers figure out multi-lane strategies, MEV recovers to 70-80% of original levels
  3. Phase 3 (Year 2+): Attester cartels form, MEV approaches 90-95% of single-leader levels but with more infrastructure complexity

The optimistic case: Ordering fees (burned) capture some MEV that previously went to validators, reducing net extraction

The pessimistic case: Inclusion fees + ordering fees > original MEV, and users pay more

One More Thing

I ran a quick simulation (rough numbers, not scientific):

  • Current Solana: 400ms block time, 1 leader, $720M MEV/year
  • MCL estimate: 350ms block time (?), 16 proposers, 200 attesters

If we assume 10% of the M MEV was due to single-leader monopoly pricing (validators charging high tips because they can), MCL could save $72M/year in extractive MEV.

But if attesters add 50ms of latency and 5% of transactions fail due to state conflicts, the UX cost might outweigh the MEV reduction.

I’d love to see Anza’s testnet data. Anyone have access?

Sources

4

Coming from the Ethereum L2 world, I find Solana’s MCL approach fascinating—but it raises a critical question: Why did Ethereum choose Proposer-Builder Separation (PBS) instead?

Two Philosophies, Same Problem

Both Ethereum and Solana face the same issue: single entities controlling block production enables MEV extraction. But they’re solving it in opposite ways:

Ethereum’s PBS:

  • Centralizes building: Specialized builders compete to create profitable blocks
  • Decentralizes proposing: Validators just sign the winning builder’s block
  • Result: Building becomes an oligopoly (Flashbots, etc.), but proposing stays decentralized

Solana’s MCL:

  • Decentralizes proposing: 16 proposers submit transactions simultaneously
  • Centralizes attestation: 200 attesters validate (risk: attester cartels)
  • Result: Proposing becomes distributed, but attestation could centralize

Neither approach is perfect. Both just move the trust assumption to a different layer.

Could Ethereum L2s Adopt MCL?

Brian’s question about whether Ethereum could use MCL got me thinking. Here’s why it’s harder for Ethereum:

1. Architecture Differences

Solana’s 400ms slots can afford 16 parallel proposers because:

  • Fast finality (400ms → 350ms with MCL)
  • State machine is optimized for parallelism (Sealevel)
  • Validators already need high-performance hardware

Ethereum’s 12-second slots with slower finality make parallel proposers less urgent. PBS already reduces MEV significantly.

2. Ethereum L2s Could Benefit More

Actually, rollup sequencers are the perfect use case for MCL:

  • Optimism, Arbitrum, Base all use single sequencers right now
  • Centralized sequencers = massive MEV extraction on L2s
  • MCL could decentralize L2 sequencing without breaking composability

But: Optimism’s Interop Layer (Q1 2026) takes a different approach—shared sequencing across Superchain. That’s closer to PBS than MCL.

The Real Trade-Off: Complexity vs. Decentralization

Here’s what bothers me as an infrastructure engineer:

PBS complexity: Low. Proposers run standard validator nodes. Builders run specialized infrastructure. Two-party game.

MCL complexity: High. Proposers + attesters + leaders, with 3,200 communication channels per slot. Debugging will be brutal.

Sophia’s right that post-mortem analysis becomes exponentially harder. In L2s, we already struggle to debug sequencer issues with one sequencer. Imagine 16.

Question: Is the decentralization gain worth the operational complexity?

Performance Concerns

Let me add some concrete numbers from my L2 experience:

Optimism (centralized sequencer):

  • Block time: 2 seconds
  • MEV extracted: ~M/year (est. 2025)
  • Infrastructure cost: Low (single sequencer)

If Optimism adopted MCL:

  • Block time: 2.5 seconds? (erasure coding + attestation overhead)
  • MEV extracted: M/year? (optimistic estimate)
  • Infrastructure cost: High (16 proposers + 200 attesters)

Is saving M/year in MEV worth adding 500ms latency and 10x infrastructure complexity? For high-frequency DeFi (DEXes, liquidations), latency = MEV. If MCL adds latency, it might create new MEV opportunities that offset the benefits.

What Solana Gets Right

I don’t want to sound too negative—there’s a lot to like:

  1. Ordering fees burned: This is brilliant. It captures some MEV for the protocol instead of validators. Ethereum should copy this.

  2. Lane-based parallelism: If done right, this could enable genuinely parallel state transitions. DeFi protocols in different lanes could execute simultaneously.

  3. Selective censorship resistance: The whitepaper’s approach (valid txs must be included within N blocks) is pragmatic. Perfect censorship resistance is impossible; selective resistance is achievable.

My Prediction for Ethereum L2s

If MCL succeeds on Solana, I predict:

  1. 2026-2027: Alt-L2s (zkSync, Scroll, Polygon zkEVM) experiment with MCL-style sequencing
  2. 2027-2028: Optimism/Arbitrum stick with shared sequencing (Interop Layer model)
  3. 2028+: Two competing standards emerge:
    • MCL-style: Used by high-throughput L2s prioritizing decentralization
    • PBS-style: Used by enterprise L2s prioritizing simplicity and reliability

Open Question: Can This Work on L1?

Brian asked, “If MCL works, why isn’t Ethereum adopting it?”

My answer: Ethereum L1 doesn’t need it. PBS already works well. The real question is whether L2s (Solana, Ethereum rollups) need MCL-style decentralization.

Solana is betting yes. Ethereum L2s are betting on shared sequencing. We’ll find out who’s right in 2026-2027.

Sources

  • Helius: Alpenglow Consensus Rewrite
  • Messari: Understanding Multiple Concurrent Proposers