MCL + JitoBAM: Are We Solving MEV or Just Moving It Into Black Boxes?

General
1

TL;DR: Solana is deploying two complementary MEV solutions—Multiple Concurrent Leaders (MCL) for distributed block production and JitoBAM using Trusted Execution Environments to hide transactions. But between TEE black boxes and 16-way consensus coordination, are we actually eliminating MEV or just making it harder to detect?

Two Paths to “Fixing” MEV

Solana’s 2026 MEV strategy has two prongs:

1. JitoBAM (Already Live - 24% Stake)

  • Uses Trusted Execution Environments (Intel SGX / AWS Nitro) to encrypt mempool
  • Transactions stay hidden until execution—no sandwich attacks
  • Validators can’t see pending transactions to front-run
  • Current adoption: 24% of stake vs 41% on regular Agave Jito

2. Multiple Concurrent Leaders (MCL - Testnet)

  • 16 validators propose blocks simultaneously via parallel lanes
  • Erasure coding + attestation thresholds merge proposals into canonical block
  • Goal: No single leader controls all ordering → distributed MEV extraction
  • Part of Alpenglow upgrade (150ms finality)

Both sound promising. But the more I dig into the technical details, the more I wonder: are we solving MEV, or just making it invisible?

The JitoBAM Black Box Problem

How It Works

JitoBAM operates through Trusted Execution Environments—secure hardware enclaves that encrypt data even from the host system. Transactions go into a TEE, get sequenced inside, and emerge only at execution time.

The pitch: Validators can’t see your transaction, so they can’t front-run it. Sandwich attacks become impossible because attackers can’t observe mempool state.

The Trust Assumption

Here’s what bothers me: TEE operators can still see everything inside the enclave.

We’re replacing “trust validators not to front-run” with “trust Intel SGX attestations and TEE operators.” And the history here is… not great:

  • Spectre/Meltdown (2018): Side-channel attacks leaked TEE data
  • Foreshadow (2018): SGX-specific vulnerability
  • Plundervault (2019): Another Intel SGX leak
  • Load Value Injection (2020): Yet another side-channel

Every few years, researchers find new ways to break these “secure” enclaves. And even if the hardware is perfect, who watches the TEE operators? Can they collude to front-run inside the enclave where nobody can see?

JitoBAM’s 24% stake adoption suggests the market trusts this—but I’m not convinced we’ve eliminated MEV, we’ve just moved it from transparent (visible mempool) to opaque (encrypted enclave).

The MCL Coordination Nightmare

Now add Multiple Concurrent Leaders to the mix. The Constellation proposal has:

  • 16 concurrent proposers producing blocks in parallel
  • 200 attesters validating and voting with thresholds:
    • 60% must attest for inclusion
    • 40% threshold to include transactions
    • 20% needed to reconstruct via erasure coding
  • Final leader compiles attested proposals into canonical block

The Questions Nobody’s Answering

1. State Conflicts
What happens when Lane A processes a DEX trade and Lane B liquidates the same account simultaneously? When proposers merge, one transaction becomes invalid. Who decides? How do we avoid cascading invalidations?

2. Attester Cartels
With 200 attesters voting on inclusion, can’t 60%+ collude to:

  • Prioritize certain proposers’ blocks (extracting MEV via proposal ordering)
  • Censor specific transactions across all lanes
  • Front-run by delaying attestation until they see profitable opportunities

We’ve distributed the attack surface—but 16 proposers × 200 attesters = 3,200 coordination points. That’s not simpler, it’s exponentially more complex.

3. The Final Leader Still Has Power
Even with parallel proposals, someone has to compile the final block. That validator chooses the final ordering when conflicts arise. Isn’t this just the single-leader problem with extra steps?

When MCL Meets JitoBAM: Double Black Box

Here’s where it gets really interesting: What happens when MCL lanes use JitoBAM?

Scenario:

  • 16 proposers are running JitoBAM (TEE-encrypted mempools)
  • Each proposer can’t see their own mempool (it’s in a TEE)
  • Attesters vote on encrypted proposals they can’t fully validate
  • Final leader compiles blocks from TEE outputs

At this point, we have:

  • Layer 1: Encrypted transactions (TEE black box)
  • Layer 2: Distributed consensus (MCL coordination)
  • Layer 3: Attestation thresholds (60% voting)

Question: How do we even measure MEV in this system? If mempools are encrypted and ordering is distributed across 16 lanes, what metrics prove it’s working?

From a data observability perspective, this is a nightmare. We can’t audit what we can’t see.

The Philosophical Question

Ethereum chose Proposer-Builder Separation (PBS):

  • Transparent MEV (anyone can see builder bids)
  • Centralized building (few specialized builders)
  • Simple mental model

Solana is choosing Distributed Opacity:

  • Hidden MEV (TEE-encrypted)
  • Decentralized building (16 parallel proposers)
  • Complex coordination

Which is better?

  • Ethereum’s approach: Accept that MEV exists, make it transparent, let specialists handle it
  • Solana’s approach: Try to eliminate MEV via complexity (distribution + encryption)

I honestly don’t know. Ethereum’s PBS is centralizing (only 5-6 major builders). Solana’s MCL+TEE is complex (can we even audit it?). There’s no free lunch.

What I Want to See Before Mainnet

  1. TEE Operator Transparency

    • Public logs of TEE operations (privacy-preserving, obviously)
    • Multiple TEE implementations (not just Intel SGX)
    • Regular third-party security audits

  2. MCL Formal Verification

    • Proof of liveness (does attestation always complete?)
    • Proof of safety (can attesters cause invalid states?)
    • Economic analysis of attester collusion incentives

  3. Observability Metrics

    • How do we measure MEV reduction if mempools are hidden?
    • Can we track cross-lane state conflicts?
    • What’s the actual latency overhead of erasure coding?

  4. Developer Documentation

    • How do dApps choose which lane to submit to?
    • Can flash loans work across lanes?
    • What happens to transaction replay protection?

I Want to Be Wrong

Solana’s willingness to experiment with radical consensus changes is exactly why it’s competitive. Alpenglow shipped on time with 150ms finality—that’s impressive. JitoBAM is already reducing sandwich attacks for real users.

But consensus is the hardest part of blockchain to get right. And when we add layers of encryption (TEE) + distribution (MCL) + coordination (attestation), the complexity compounds exponentially.

My concern: We’re replacing visible MEV (which we can measure and mitigate) with invisible MEV (which might still exist but we can’t detect).

What does everyone think?

  • Am I being overly paranoid about TEE trust assumptions?
  • Are the MCL complexity concerns overblown?
  • Should we prioritize transparency (Ethereum PBS) or distribution (Solana MCL)?

Would love to hear from security researchers, data engineers, and anyone building DeFi on Solana. What am I missing?

Sources: