Pre-FRP: Accountability and Liveness in Batched-Threshold Encrypted Mempools

FRPs - Flashbots Research Proposals
, ,
1

Hi everyone, I’m Aditya Kumar, and I’m building Peal Network.

I started Peal with a simple question: can a transaction remain unreadable until its ordering is committed, then reveal automatically without requiring the user to return and submit a second transaction?

Batched threshold encryption looks promising for this. It can keep pending transactions private while allowing a committee to decrypt an entire batch with one small contribution from each operator.

But after building a working prototype, I think the harder question is no longer just whether the cryptography is fast enough. It is whether the network around it can reveal transactions fairly, reliably and at the correct time.

I’m sharing this as a pre-FRP to turn that question into a more rigorous research project and get feedback from the Flashbots community.

What exists today

Peal is a programmable disclosure network prototype built using Commonware’s simple-bte implementation.

Peal does not introduce a new cryptographic construction. The underlying BTE work comes from Commonware and Guru-Vamsi Policharla. Peal builds the surrounding system: the coordinator, operator nodes, SDK, explorer, settlement contracts and an application-level encrypted mempool.

The current prototype includes a controlled DEX experiment on Tempo Moderato testnet. The same swap can be submitted through two different lanes:

  1. A public lane where a searcher sees the pending order and can construct a sandwich around it.
  2. An encrypted lane where only a commitment to the sealed order is visible until the batch opens.

The prototype currently uses a 3-of-5 committee with batches of 64 ciphertexts. Each operator sends one 48-byte decryption share for the entire batch. In local single-process benchmarks, finalization takes approximately 37 ms after the threshold of valid shares is available.

The demo shows that hiding order contents can prevent the specific searcher from constructing the same pre-trade sandwich. It does not prove that Peal eliminates MEV, works under production conditions or has a complete trust model.

The question I want to study

The main research question is:

Under what trust, ordering and network conditions does batched threshold encryption reduce harmful MEV without creating new information, censorship or liveness advantages?

A transaction may be cryptographically hidden, but the system can still fail around the edges.

The current Peal prototype uses a trusted setup dealer. Operators do not yet verify the reveal condition independently. A malicious coordinator could request shares before the intended cue, and early disclosure could occur if a threshold of operators responded. Operators can also withhold their shares and stall a batch.

Even if decryption works correctly, a sequencer may still delay, censor or reorder transactions after they are revealed.

These are not minor implementation details. They determine whether an encrypted mempool actually improves the outcome for users.

Proposed research

I want to study the complete path from encrypted submission to execution, rather than measuring the encryption scheme in isolation.

The work would begin by defining a threat model for every actor involved:

  • Setup dealer
  • Coordinator
  • Decryption operators
  • Relayer
  • Sequencer or builder
  • Settlement contract
  • Searchers
  • Users

The next step would be to implement independent cue verification. Instead of trusting the coordinator to announce that a block-based condition has occurred, every operator would verify the condition against finalized chain state before producing a share.

This introduces its own questions. Operators may observe different chain heads, rely on different RPC providers or disagree during a reorganization. The research should measure how much confirmation is needed, what happens when observations conflict and how those choices affect reveal latency.

Experimental design

I plan to compare four transaction-submission models:

  1. Public mempool submission.
  2. A conventional commit-reveal flow where the user must return to reveal.
  3. Coordinator-triggered batched threshold encryption, representing the current Peal model.
  4. Batched threshold encryption with independent, chain-derived cue verification by every operator.

Each model would receive equivalent transaction workloads, liquidity conditions, slippage limits and searcher strategies.

The experiments would vary:

  • Batch sizes such as 16, 64, 256 and 512.
  • Committee configurations such as 3-of-5, 5-of-8 and 11-of-16.
  • Network delay and packet loss.
  • Operator availability.
  • Trade size and market liquidity.
  • Time between ordering commitment, decryption and settlement.

The adversarial tests would include:

  • A coordinator requesting shares too early.
  • Operators observing conflicting chain states.
  • Chain reorganizations around the reveal block.
  • Invalid or malformed shares.
  • Operators delaying or withholding shares.
  • Coordinator equivocation.
  • Operator and coordinator outages.
  • Corrupted ciphertexts.
  • Transaction censorship.
  • Post-reveal transaction reordering.
  • Searchers changing their strategies after disclosure.

What would be measured

The study would measure both system performance and user outcomes:

  • End-to-end transaction latency.
  • p50, p95 and p99 reveal latency.
  • Operator computation and bandwidth.
  • Batch completion and stall rates.
  • Recovery after operator or coordinator failure.
  • Time between the first possible decryption and public availability.
  • Transaction inclusion and censorship rates.
  • User execution shortfall compared with the pre-trade quote.
  • MEV extracted under each submission model.
  • Whether invalid, delayed or premature operator behavior can be attributed publicly.

The results would include repeated trials, complete experiment configurations and machine-readable data so others can reproduce or challenge the findings.

How this relates to existing work

FRP-31 identified important limitations of threshold-encrypted mempools, including early information access, decryptor collusion, share withholding and continued validator influence over transaction ordering.

More recent BTE research has improved setup, communication and decryption performance. TrX has also studied the integration of encrypted mempools with high-performance BFT consensus.

I see a remaining gap at the application and rollup boundary. We still need to understand who learns transaction contents first, how reveal conditions are enforced, which forms of MEV remain and whether the system produces better execution for users under adversarial conditions.

The intended contribution is not a new encryption scheme. It is an empirical study of the operational system around BTE and the tradeoffs users actually experience.

Scope and limitations

The first experiments would use controlled order flow and test environments. They would not represent the full behavior of production searchers or real market liquidity.

Replacing the trusted dealer with production-ready distributed key generation is also outside the initial scope. Dealer compromise will be included explicitly in the threat model, and a DKG design or proof of concept may be considered as a later extension.

The research will not assume that encrypted mempools remove all MEV. Backrunning, censorship, ordering advantages and cross-domain MEV may remain after transaction contents are revealed.

Expected outputs

I expect the project to produce:

  • A complete threat model for application-level BTE.
  • Independent block-based cue verification for operators.
  • An open-source adversarial testing framework.
  • Reproducible benchmark and MEV experiment scripts.
  • A public dataset with the experiment results.
  • A research report or preprint.
  • Practical recommendations for applications and rollups evaluating encrypted transaction submission.
  • A Flashbots forum summary and community presentation.

Feedback I’m looking for

I would especially appreciate feedback on:

  1. Is this sufficiently distinct from existing encrypted-mempool research?
  2. Which adversarial cases or comparison baselines am I missing?
  3. Which Ethereum L2, rollup devnet or sequencer interface would be the most useful additional testing environment?
  4. Is anyone interested in collaborating on the MEV measurement, mechanism-design or empirical-analysis side?

Links

So I’m sharing this as an initial research discussion. Formal FRP intake is currently paused, If submissions reopen, I plan to use the feedback from this thread to prepare the formal GitHub proposal.