Encrypt The Mempool #2

Protocol Calls & happenings
1

Agenda

  • Demonstrator stack?
  • Outstanding design questions

Meeting Time: Wednesday, March 18, 2026 at 15:00 UTC (60 minutes)

GitHub Issue

2

YouTube recording available: https://youtu.be/109IE6-yDfg

3

Meeting Summary:

The Encrypted Mempool Working Group meeting focused on reviewing a new EIP proposal for the Lucid design and discussing implementation approaches including demonstrator creation and simulation methods. The team explored various technical considerations around transaction encryption, back-running efficiency, and MEV classification, with particular attention to design trade-offs between simplicity and flexibility. The discussion concluded with debates about transaction interleaving approaches and the economic implications of different implementation strategies, including concerns about market fairness and protocol welfare.

Click to expand detailed summary

The meeting focused on the Encrypted Mempool Working Group, with Justin leading the discussion. The group reviewed a new EIP number (8184) for the Lucid design and discussed potential agenda items including back running efficiency and on-chain versus off-chain implementations. Justin proposed creating a demonstrator and observability stack to test and observe encrypted mempool functionality before implementing the actual design. The team also briefly mentioned a recently published proposal for encrypted frame transactions.

Luis discussed two approaches for simulating an AMM model: a simple model built by Yannick and an implementation on the Gnosis chain. Justin expressed interest in a local simulation that could easily demonstrate transaction ordering and back-running efficiency. Stefan suggested using a builder for ePBS as an alternative approach. Luis agreed to follow up with Yannick about publishing his work and explore how the builder could fit into the simulation. The group also discussed the importance of creating a frontend for visualization to help tell the story of the sandwiches and their prevention.

Luis discussed concerns about the current private Mempool landscape, particularly regarding transaction back-running in PBS models where users typically receive around 90% of proceeds back. He expressed a desire to achieve similar per-transaction back-running efficiency in Lucid as exists in current systems, though questioned whether this approach is economically desirable compared to larger background transactions per block. Justin acknowledged the first question as an economic inquiry beyond his expertise, while Anders was about to provide an answer when the transcript ended.

Anders explained Lucid’s approach to MEV (Miner Extractable Value) by classifying it into three categories and describing how Lucid facilitates endogenous MEV through transaction bundling and background interactions. The discussion focused on the potential for increased on-chain searching to execute background transactions, with Anders arguing this approach could scale Ethereum compute by approximately 10x. Luis raised concerns about potential opposition to this approach due to efficiency and spamming concerns, while Gottfried highlighted an alternative risk of free option problems in the current Lucid design. Anders clarified that while optionality exists, Lucid’s design allows senders to compose their own background trades directly after their transactions, preventing others from exploiting this optionality.

The group discussed the design considerations for handling encrypted transactions versus plain text transactions, particularly around interleaving them versus keeping them separate. Anders expressed skepticism about the benefits of interleaving, citing concerns about revealing transaction details and the complexity it would introduce to the design. soispoke argued that interleaving could reduce competition concentration and provide benefits, though acknowledged it would require significant design changes to the current model. The discussion highlighted the trade-offs between maintaining a simple design versus enabling more flexible transaction ordering.

The group discussed the benefits and challenges of transaction encryption and back-running in a blockchain context. Justin questioned the effectiveness of encrypted transactions once commitment to ordering is made, while soispoke noted that some metadata leakage could still allow for educated guesses about transactions. Luis suggested a hybrid approach where users could share transaction details while restricting front-running. The discussion highlighted differences between this approach and existing systems like Lucid, with Mark explaining that in traditional financial markets, market data is shared more widely among participants. Murat from PryMab pointed out the economic implications of returning 90% to users, which creates a “rigged market” at the cost of other network participants.

The group discussed design options for encrypted transactions and block construction, focusing on whether to interleave transactions or use a separate slot approach. Mark suggested that interleaving might be better for searchers but less optimal for protocol welfare, while Anders proposed a one-slot design with semantic chunking to avoid gas waste. The discussion highlighted trade-offs between timing, complexity, and compatibility with existing frame transaction frameworks. Murat mentioned that giving builders optionality to include encrypted transactions in the same slot, contingent on key availability, could work within current timing constraints. The group agreed to further evaluate these proposals, with Murat planning to provide a written description of the key distribution approach.

Next Steps:

  • Luis: Talk to Yannick about the AMM simulation work and check if it has been published anywhere, share the repo if available
  • Justin: Review the AI-generated meeting transcription to ensure accuracy before distribution
  • Justin: Attach the meeting transcription and AI summary to Encrypted Mempool channel and various Telegrams
  • Murat: Do a write-up on the proposal for builder optionality to include transactions in same slot (n) or n+1

Recording Access: