Threshold Encrypted Mempools with mev-commit Preconfirmations

Cryptography
,
1

Threshold Encrypted Mempools with mev-commit Preconfirmations

by Murat Akdeniz (Primev), Bernardo Magri (Primev), Christian Matt (Primev), Punit Jain (Shutter Network), Anthony Caravello (Shutter Network), Luis Bezzenberger (Shutter Network)

Motivation

Ethereum users lose value daily to frontrunning, sandwich attacks, and censorship. A DEX swap gets sandwiched, an NFT mint gets frontrun. These attacks succeed because transactions sit visible in the public mempool before inclusion.

The user-side solution is encryption: hide transaction contents until execution order is fixed. But encryption alone isn’t enough. How do you ensure builders actually include encrypted transactions after committing to them?

This post presents the first threshold encrypted mempool for Ethereum’s out-of-protocol transaction supply chain. We combine Shutter’s threshold encryption with mev-commit’s preconfirmation infrastructure to create practical frontrunning protection deployable today without consensus changes.

Key properties:

  • Users submit encrypted transactions hiding their intentions
  • Builders commit blind before seeing contents
  • Shutter Keypers release decryption keys only after sufficient commitments
  • Oracle verifies inclusion and slashes builders who break commitments
  • Validators can opt in seamlessly via mev-boost, Commit-Boost, or any other relay-supporting sidecar without additional operational overhead

We’re deploying a working proof of concept on Hoodi testnet. In the current PoC, the sequencer / RPC still sees transactions in plaintext briefly before encrypting them, so the main visibility improvement is between users and the public mempool / builders. In parallel, we are exploring integration with Kohaku-style approaches to move toward end-to-end pre-execution privacy where even the RPC cannot inspect transaction contents.

Builder Integration: Builders integrate with the encrypted mempool by extending their existing mev-commit provider workflow to accept and commit to blind encrypted bids. No changes to block construction logic are required beyond supporting the Shutterised Bid and placing decrypted transactions at the top of the block.

mev-commit exposes encrypted bids through its standard provider interface, allowing builders to receive them exactly like ordinary preconfirmation bids but without transaction contents. Builders evaluate these blind bids, issue commitments tied to transaction hashes, and rely on keypers to release decryption keys once the global commitment threshold is reached. After key release, builders fetch the decrypted transaction via the provider endpoint and include it in block construction.

Validator Integration: mev-commit integrates with commit-boost, mev-boost or any other sidecar that supports relays, allowing validators to opt into preconfirmations by simply selecting mev-commit-enabled relays in their Commit-Boost configuration.

Background: Threshold Encryption and Preconfirmations

Threshold encryption distributes trust across multiple parties called keypers. A transaction encrypted under this scheme can only be decrypted when a threshold number of keypers (t out of n) cooperate to release their key shares. This prevents any single party from decrypting without a common decryption trigger.

The critical challenge for encrypted mempools is enforcement: how do we ensure builders actually include encrypted transactions they’ve committed to? Three approaches exist:

  1. Trusted: Builders promise to include transactions (no enforcement)
  2. Economic: Builders stake collateral that gets slashed for misbehavior (retroactive enforcement)
  3. Cryptographic: Smart contracts or consensus rules prevent execution unless conditions met (proactive enforcement)

Our design uses economic enforcement through mev-commit’s preconfirmation infrastructure. Builders cryptographically commit to including specific transactions and back these commitments with slashable stake. We extend this mechanism to encrypted transactions, creating a system where builders commit blind to transaction contents.

The key insight is that commitment infrastructure already exists. Rather than waiting for consensus changes or smart account adoption, we can deploy encrypted mempools today by leveraging mev-commit’s existing slashing conditions and extending them to handle threshold-encrypted transactions.

Design Overview

Our system integrates three components:

  1. Sequencer: Receives transactions, encrypts them using Shutter’s threshold scheme, generates identity preimages (random 32 bytes used for indexing encrypted transaction)
  2. Keypers: Monitor builder commitments, release decryption keys when threshold met (≥3 commitments)
  3. mev-commit: Provides commitment and slashing infrastructure through bidder/provider nodes and oracle

Architecture

image
image2230Ă—1416 115 KB

Transaction Flow

1. User submits transaction to sequencer
2. Sequencer encrypts with threshold cryptography
3. Sequencer submits encrypted bid to mev-commit bidder node
4. Bidder relays encrypted bid to builders (providers)
5. Builders evaluate and commit blind 
6. Keypers validate commitment threshold, release keys
7. Builders decrypt and include transactions at top-of-block
8. Oracle verifies inclusion on L1
9. Oracle attests to mev-commit for rewards/slashing

The critical property is conditional decryption: keys are released only after sufficient builder commitments are secured. This prevents the “decryption then censorship” attack where builders see plaintext and selectively exclude transactions.

Enforcement Mechanisms

Commitment Threshold

Keypers implement threshold validation logic:

func ShouldReleaseKey(identity Identity) bool {
  commitments := GetCommitments(identity)
  
  if len(commitments) < THRESHOLD {
    return false  // Not enough commitments
  }
  
  for _, c := range commitments {
    bidderAddr := RecoverSigner(c.Signature)
    expectedIdentity := Keccak256(c.RandomPrefix + bidderAddr)
    
    if expectedIdentity != identity {
      return false  // Invalid identity
    }
  }
  
  return true
}

The PoC uses threshold = 3, but production systems could make this dynamic based on bid amounts or use validator-backed keyper sets.

Inclusion Verification

The mev-commit oracle enforces inclusion through retroactive slashing:

func ValidateInclusion(tx, commitment, block) Outcome {
  decrypted := Decrypt(tx.Encrypted, tx.Key)
  
  if !IsInBlock(decrypted, block) {
    if IsValidTransaction(decrypted) {
      return SLASH_BUILDER  // Malicious exclusion
    } else {
      return NO_SLASH  // Justified exclusion
    }
  }
  
  if block.Transactions[0].Hash != decrypted.Hash {
    return PARTIAL_REWARD  // Wrong placement
  }
  
  return FULL_REWARD
}

Slashing outcomes:

  • FULL_REWARD: Perfect fulfillment (included at top-of-block)
  • PARTIAL_REWARD: Included but wrong placement
  • NO_SLASH: Justified non-inclusion (invalid transaction)
  • SLASH_BUILDER: Committed but failed to include valid transaction

This creates strong incentives for builders to honor commitments. In the PoC, slashing is set at the full bid amount (30 Gwei). Production systems could implement proportional slashing based on reputation.

Top-of-Block Enforcement

Requiring transactions at top-of-block prevents a subtle attack: builders could include encrypted transactions but frontrun them with their own transactions after decryption. The oracle verifies block position:

if block.Transactions[0].Hash != decrypted.Hash {
  return PARTIAL_REWARD
}

This could be extended using the TXINDEX precompile (EIP-7793) for on-chain verification in future variants that combine economic and cryptographic enforcement.

Security Analysis

Frontrunning Protection

Attack: Builder commits, receives decryption keys, then reorders to frontrun.

Defense: Oracle detects wrong placement and slashes. Since slashing equals the bid amount, frontrunning is only profitable if MEV extraction exceeds the slashing penalty. In practice, this makes frontrunning economically irrational for most transactions.

Tradeoff: Economic enforcement allows frontrunning if MEV exceeds stake. Cryptographic enforcement (smart contracts validating placement on-chain) would prevent this unconditionally, but requires consensus changes and higher gas costs. Our approach is deployable today.

Censorship Resistance

Attack: Builder commits then deliberately excludes transaction.

Defense: Oracle slashes full bid amount. Since builders miss out on rewards and lose stake, censorship is economically irrational unless externally motivated (e.g., OFAC compliance).

Limitation: Cannot prevent censorship before commitment. If no builders commit, keypers don’t release keys and transaction isn’t included. This is mitigated by:

  1. Multiple builders competing for order flow
  2. Reputation systems for builders
  3. Integration with FOCIL (fork-choice enforced inclusion lists)

Offline Proposer Attack

Attack: Proposer is offline, decrypted transactions leak, next proposer frontruns.

Defense: In the current PoC, we don’t prevent transaction reuse across slots. However, this could be addressed by adding slot-specific validation:

require(block.number == intendedBlock, "Wrong block");

This would invalidate the transaction body in future blocks even if decrypted, similar to how smart account approaches handle this scenario. This limitation can also be handled on dapp using specific checks like deadline for swapping tokens via AMM.

Keyper Collusion

Attack: Keypers collude to decrypt early (< threshold).

Defense: Threshold assumption (< t of n malicious). For PoC we use t = 3, n = 5. Production improvements:

  1. Validator-backed keypers: Select from Ethereum validator set with economic security
  2. ShutterTEE: Store key shares in TEEs that release only when protocol conditions met
  3. Snitching protocols: Detect and punish colluding keypers
  4. Rotation: Regularly rotate keyper set

The Shutter roadmap explores these improvements in depth.

RPC Visibility Today and End-to-End Privacy

Today, the sequencer / RPC still sees transactions in plaintext before encrypting and forwarding them into the encrypted mempool. This means:

  • The public mempool and builders are blinded
  • But the RPC operator remains a visibility bottleneck

Our longer-term goal is to close this gap and achieve end-to-end pre-execution privacy. We are exploring:

  • Kohaku-like approaches for moving encryption closer to the user
  • Collaborative work with PSE on designs where even the RPC cannot see transaction contents before execution ordering is fixed

This PoC should be seen as a step toward that end-to-end model.

Economic Considerations

Builders decide: commit blind or skip?

Commit if: E[TransactionValue] + Reputation > SlashingRisk

The design preserves backrunning MEV while preventing frontrunning. After decryption, builders can include backrun transactions without harming users. All parties (users, builders, keypers, oracle) are economically incentivized to participate honestly.

Validator Participation via PBS Sidecars (mev-boost / Commit-Boost)

Validator participation strengthens commitment credibility and enables the highest economic value extraction from encrypted mempools. However, maintaining validator simplicity is critical. mev-commit achieves this through integration with PBS sidecars such as commit-boost and mev-boost.

Architecture:

  • mev-commit Network Layer: Operates as a combination of peer-to-peer network services and blockchain for execution bids and commitments
  • PBS Sidecar Layer: Provides standardized interface between validators and commitment protocols (e.g., Commit-Boost, mev-boost)
  • Relay Delegation: Validators delegate computational work to relays, maintaining lightweight operations

How It Works:

Validators can run a single PBS sidecar that supports multiple commitment protocols including mev-commit. Integration requires only:

  1. Install a PBS sidecar (Commit-Boost today; mev-boost or others in the same pattern)
  2. Configure mev-commit-enabled relays in the sidecar configuration
  3. Opt into mev-commit through validator registry (EigenLayer, Symbiotic, or vanilla staking)
  4. Start receiving preconfirmation rewards automatically

Benefits for Validators:

  • Low Operational Overhead: No additional infrastructure beyond the usual PBS sidecar
  • Potential Revenue: Capture value from preconfirmation bids and encrypted transaction mev
  • Reduced Risk: Single standardized interface for multiple commitment protocols
  • Future-Proof: Ready for new mev-commit services without infrastructure changes

Comparison to Alternatives:

Approach Validator Complexity Commitment Strength Deployment Timeline
mev-commit + PBS sidecar Minimal (sidecar only) Strong (economic + validator backing) Available today
In-protocol preconfs Minimal (consensus) Strongest (consensus enforced) 2+ years (requires hard fork)
Direct validator integration High (custom infra) Strong (direct participation) Available but operationally risky

By leveraging existing PBS sidecars, our encrypted mempool design maintains compatibility with evolving validator infrastructure while providing immediate access to preconfirmation markets. As mev-commit expands to support additional services beyond preconfirmations, validators using these sidecars automatically benefit without changing their setup.

Proof of Concept Implementation

We’re deploying a PoC on Hoodi testnet, which we’ll make available shortly.

The encrypted mempool flow will be exposed via a dedicated FastRPC endpoint, supporting but separate from the main RPC interface, which can be used by privacy preserving wallets.

Components:

  • Sequencer: FastRPC JSON-RPC endpoint dedicated to encrypted flow, Shutter encryption, mev-commit bidder client, P2P keyper network
  • Keypers: Modified rolling-shutter, threshold validation (3-of-5), DKG protocol
  • mev-commit: Extended bidder/provider gRPC APIs, oracle inclusion verification

Performance:

  • Transaction encryption: ~50ms
  • Commitment threshold: 3 builders
  • Decryption latency: 2-5s after threshold
  • Transactions will be pre-confirmed (once commitment happened)
  • Full flow: ~12–15s (one L1 block)

Comparison with Other Approaches

Economic vs. Cryptographic Enforcement

Our mev-commit approach uses economic enforcement through slashing:

  • :white_check_mark: Works with EOAs today
  • :white_check_mark: Lower gas costs (off-chain verification)
  • :white_check_mark: Leverages existing mev-commit infrastructure
  • :white_check_mark: Compatible with current PBS architecture
  • :cross_mark: Retroactive enforcement (frontrunning possible if MEV > stake)
  • :cross_mark: Requires builder participation in mev-commit

Cryptographic enforcement through smart contracts would provide:

  • :white_check_mark: Unconditional frontrunning protection
  • :white_check_mark: No slashing of offline proposers
  • :cross_mark: Requires ERC-4337 adoption or similar account abstraction
  • :cross_mark: Needs new precompiles (TXINDEX, SLOT)
  • :cross_mark: Higher gas costs (on-chain validation)
  • :cross_mark: Limited to smart accounts without EIP-7702

These approaches are complementary. Future work could combine mev-commit commitments with smart contract validation for layered security.

Out-of-Protocol vs. In-Protocol

Our out-of-protocol mev-commit approach:

  • :white_check_mark: Deployable today
  • :white_check_mark: Iterative improvement path
  • :white_check_mark: Lower coordination cost
  • :cross_mark: Weaker guarantees than consensus enforcement
  • :cross_mark: Relies on economic security

In-protocol integration (Shutter roadmap) would provide:

  • :white_check_mark: Strongest guarantees (consensus-enforced)
  • :white_check_mark: No external slashing infrastructure
  • :white_check_mark: Can integrate with FOCIL
  • :cross_mark: Requires hard fork
  • :cross_mark: Longer deployment timeline

Open Questions

Mechanism Design:

  1. Should commitment threshold vary by bid amount or validator participation?
  2. Proportional vs. binary slashing? How to handle repeat offenders?
  3. How should encrypted transactions be priced relative to normal transactions?

Integration:

  1. In-wallet vs. dapp-side encryption?
  2. What incentives drive builder participation?

Security:

  1. Keyper selection for production: random validator sampling vs. dedicated set?
  2. What if no builders commit? FOCIL integration?
  3. Cross-domain MEV handling?

Economics:

  1. Should backrunning profits be shared with users or keypers?
  2. How do encrypted transactions compete for block space?
  3. Can fees support keyper infrastructure long-term?

Future Directions

Short Term (3–6 months): Builder onboarding, performance optimization, wallet integration, monitoring infrastructure

Medium Term (6–12 months): Dynamic thresholds, validator-backed keypers with slashing, relay integration

Long Term (12+ months): Smart contract integration for layered security, ePBS native support, FOCIL integration, in-protocol transition path, and deeper Kohaku / PSE-style integration for RPC-blind, end-to-end pre-execution privacy

The modular design allows incremental deployment without breaking existing functionality.

Conclusion

We’ve presented a practical threshold encrypted mempool that leverages mev-commit’s preconfirmation infrastructure for economic enforcement. While retroactive slashing is weaker than proactive cryptographic enforcement, it offers a deployable path forward within Ethereum’s existing architecture.

The PoC on Hoodi testnet is the first step. Next steps involve expanding builder participation, optimizing performance, tightening RPC visibility with end-to-end approaches, and gathering data to inform production deployment and future in-protocol designs.

Encrypted mempools are critical for Ethereum’s fairness and decentralization. This work shows they can be deployed today. We invite builders, validators, and protocol developers to experiment with the PoC and provide feedback.

Code & Documentation:

Acknowledgments: This work builds on Shutter Network’s threshold encryption research and mev-commit’s preconfirmation infrastructure. Thanks to the broader encrypted mempool research community for valuable insights.

2 Likes