Encrypt The Mempool #10, September 16, 2026

Protocol Calls & happenings
1

Agenda

Meeting Time: Wednesday, September 16, 2026 at 15:00 UTC (60 minutes)

GitHub Issue

2

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

3

Meeting Summary:

The meeting focused on the Encrypted Mempool project, specifically addressing the optionality problem in the Lucid protocol and discussing potential solutions. Justin proposed moving the meeting cadence to monthly, which was agreed upon. The group discussed the challenges of implementing post-quantum threshold encryption and decided to put it on hold until the cryptography matures. Jannik presented a proposal for a voting mechanism to allowlist key publishers, using a contract on the execution layer to manage and tally votes from validators. The discussion covered the details of this mechanism, including the threshold for acceptance, the cost of voting, and the potential for delegation. Gottfried suggested an alternative approach of using top-of-block ordering to prioritize transactions from allowlisted key publishers, which was well-received as it could mitigate market entry barriers. The group also touched on the possibility of splitting the EIP into separate documents and the idea of lowering the penalty constants in the Lucid design if the allowlist mechanism is implemented.

Click to expand detailed summary

The team discussed changing the meeting frequency from bi-weekly to monthly, with Justin proposing this adjustment due to the group still being in the design phase and maintaining good asynchronous communication through Telegram. They decided to remove threshold encryption and PQ requirements from current considerations, with Justin explaining that threshold encryption concepts aren’t mature enough yet and the team will continue monitoring post-quantum signature developments separately.

The team discussed the challenges with post-quantum (PQ) cryptography, noting that current solutions are not efficient enough and remain far off from implementation. They concluded that PQ solutions are still not viable and will likely not be ready for years. The discussion then shifted to focusing on the optionality problem with Lucid, which is currently post-quantum secure but has an optionality issue. They explored the idea of using a key publisher as a neutral party responsible for revealing keys after encryption transactions are committed to the blockchain, though they acknowledged the need to address how to track and trust this neutrality.

Jannik presented a proposal for implementing an allowlisting process where validators can whitelist trusted key publishers through a voting mechanism. The proposal involves validators voting on individual addresses, with addresses requiring 50% support from the total effective balance to be accepted. The implementation would use a voting contract on the execution layer to manage ballot lists and validator subscriptions, with delegation capabilities to allow validators to delegate the curation responsibility to others. The discussion included technical considerations about efficiency, with Gottfried suggesting potential optimizations around sampling and weight-based counting, though Jannik noted these might not significantly improve performance due to the need to update validator weights.

The team discussed the costs and mechanisms of validator voting for key publisher whitelisting, with Jannik and Gottfried highlighting challenges in determining appropriate compensation or restrictions. They explored potential issues with free voting, including spam and bribery risks, and considered solutions like rate limiting and smart contracts. The group also compared the current design to a previous trust graph approach, noting that while the trust graph provided some security, it imposed unnecessary ordering restrictions. The discussion concluded with agreement that the current fee-based mechanism for transaction ordering offers a better solution than the previous trust graph approach.

The team discussed implementing a whitelist system for key publishers, where validators would vote to approve trusted key providers who would be prioritized in top-of-block ordering. They agreed this approach would help address market entry barriers while allowing some revenue generation before reaching the 50% approval threshold needed for full participation. The group decided to keep the current EIP as a single document for now, with plans to potentially split it later if needed, and Jannik will open a PR to incorporate the whitelist concept into the existing EIP.

Next Steps:

  • Justin: Change the meeting cadence from bi-weekly to monthly.
  • Jannik: Write up the allowlist proposal (key publisher voting mechanism) and open a PR to EIP 8184.
  • Justin: Add Jannik as an author to EIP 8184.
  • Justin and Anders: Update EIP 8184 to include the allowlist mechanism and top-of-block ordering idea.
  • Gottfried: Check and remind about updating the hash in the Lucid EIP to include randomness.
  • Anders and Gottfried: Consider and discuss lowering the penalty constant (128x) in the Lucid EIP if the allowlist mechanism is implemented.

Recording Access: