Encrypt The Mempool #1, March 4, 2026

Protocol Calls & happenings
1

Agenda

  • status of EIP-8105
  • Beacon Chain RPC APIs. Notification of Inclusion and reveal of key.
  • ciphertext encapsulation - AEAD and DEM (RFC 9180)
  • Bundling

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

GitHub Issue

2

Meeting Summary:

The meeting focused on the withdrawal of EIP8105 and the implementation of a new two-slot design called Lucid, which allows for optional transaction encryption with specific penalty systems for non-revealed encryption keys. The team discussed technical aspects including beacon chain RPC APIs, transaction bundling capabilities, and the management of multiple transaction types while addressing concerns about network overhead and censorship resistance. The discussion concluded with considerations about block size limits, ticket inclusion rules, and an invitation for further conversation on Discord’s R&D channel.

Click to expand detailed summary

The meeting discussed the withdrawal of EIP8105, a Universal Encrypted Enshrined Mempool design, which was replaced by pursuing improvements to the Lucid design. It was mentioned that Anders Ellison had published a new EIP that morning, but the details were not provided. The meeting also touched on the use of Fireflies.ai for recording and taking notes, with instructions on how to opt-out.

The meeting focused on a pull request for an EIP, where Justin shared a link to the engineering document and encouraged feedback. They discussed the need for beacon chain RPC APIs to listen for events and send messages, with Justin noting that EIP-8105 is being withdrawn and replaced by this new pull request. The group briefly discussed the availability of beacon RPCs from providers, with no major concerns raised.

The team discussed the implementation of a new two-slot design called Lucid, which allows users to encrypt transactions and reveal them in a reserved block space. Justin explained that the feature is optional and would require updates to existing RPC methods and the addition of new event types. The group also addressed concerns about potential pitfalls, including a one-slot delay that could lead to stale prices and increased network overhead. Ameziane raised questions about network overhead, and the team acknowledged that while the traffic would be small, it would introduce new traffic and topics to the CL P2P network.

Anders explained the penalty system for encrypted transactions: if the encryption key is not revealed, the sender pays a top-of-block fee, and the commitment that pays the highest fee goes first. If the transaction is decrypted and matches the commitment, the sender receives 63 out of 64 of the top-of-block fee (approximately 98%). If the transaction is not decrypted, the sender loses the top-of-block fee and may not be included in the block if someone else pays a higher fee. Additionally, if the encryption key is not revealed, the builder of the next block simply ignores the transaction, preventing it from counting against the block size limit.

Anders explained the current implementation of PTC votes to determine if keys were revealed in transactions, which builders must adhere to. Justin raised a question about how proposals would interact in Hagoda, particularly regarding frames and encrypted transactions, noting the complexity of having three headliners and a hard fork. Anders mentioned that while encrypted transactions can interact with FOCIL’s inclusion list, this is not a strict requirement for censorship resistance, as the sender and content are already hidden.

Mark and Anders discussed the challenges and economic rationale of transaction censorship in a blockchain context. Mark highlighted the need for both censorship and non-disclosure, emphasizing the role of encryption in protecting against information leakage and inclusion order issues. Anders questioned the economic motivation for censoring transactions, suggesting that it would be difficult to profit from such censorship, which supports the idea of upholding censorship resistance without relying on specific tools like FOCIL.

The meeting discussed EIP 105 and the implementation of symmetric encryption with AEAD as described in RFC 9180 for encrypted transactions. Luis explained that EIP 105 did not involve FOCIL but was a normal transaction type. Justin introduced the topic of bundling and ciphertext encapsulation, highlighting the flexibility to extend or create new encapsulations for post-quantum security. Anders described the bundling feature, explaining that it allows multiple CL transactions to be bundled into one commitment, with the option to use one key for all transactions or individual keys for each.

The team discussed the challenges and potential solutions for managing an increasing number of transaction types, with Łukasz suggesting frame transactions and composition as alternatives to an expanding inheritance hierarchy. They explored the possibility of allowing both normal and encrypted transactions simultaneously, with Luis Pinto raising concerns about potential censorship of private transactions. Justin explained that FOCIL, along with other privacy features like proposer-builder separation and mempool encryption, provides a comprehensive system to address these concerns, emphasizing the importance of all three features for legal and practical reasons.

The team discussed the advantages and disadvantages of encrypting transactions, with Anders explaining that reserving 1/8 of the block space for encrypted transactions prevents priority gas auctions and allows for payload withholding as a fallback. They addressed concerns about the ACDE, including its maturity, complexity, and compatibility with the roadmap. Łukasz raised questions about the reserved space and gas auction mechanism, which Justin and Anders clarified, explaining that it’s a maximum limit rather than a fixed reservation, and transactions exceeding this limit would be delayed to subsequent blocks.

Anders explained the block size limit, stating that if a block is filled, the builder has the freedom to decide which transactions to include. He clarified that when a builder is working on a block, they already have committed transactions, and can include up to one-eighth of new CL transactions that have been decrypted and will be executed first. Justin suggested adding a block-linity rule to check for this, ensuring that the number of tickets included in the previous block does not exceed the available space in the next block.

The meeting focused on discussing ticket inclusion limits, with Anders explaining that tickets can include up to one-eighth of the gas for the next block. Justin encouraged participants to continue the conversation on Discord’s R&D channel and encrypted mempools sub-channel, inviting input from builders, searchers, and wallets. The conversation ended with Justin inviting participants to reach out to him, Julian, or Anders with any concerns.

Next Steps:

  • Anders Ellison: Specify one new Beacon RPC API method and update existing method for encrypted transaction key reveal and event listening
  • All participants: Direct further discussion and improvements to the EIP pull request (asynchronously)
  • Justin/Anders/Julian: Explore design space for gas auction mechanism instead of reserved space (follow up with Łukasz)
  • Justin/Anders/Julian: Reach out to builders and searchers in MEV ecosystem to get their perspectives and opinions
  • Justin/Anders/Julian: Engage with wallet developers to ensure their concerns are heard and addressed
  • Anders/Justin: Add block validity rule to check that tickets included in block N-1 don’t exceed 1/8th of gas limit for block N

Recording Access:

3

YouTube recording available: https://youtu.be/vJqyJ6XTGa0