Agenda
TBD
Meeting Time: Wednesday, March 25, 2026 at 15:00 UTC (60 minutes)
1 Like
Meeting Summary:
The team discussed three strategies for implementing Frame Transactions in the mempool, with a focus on paymaster approaches and mempool integration preferences. Various implementation approaches were explored for EVM restrictions and transaction validation, including pre-compiles, delegation mechanisms, and cryptographic schemes. The conversation ended with discussions about EIP-8141 as a potential headliner for the next fork, with the team agreeing to make a final decision at tomorrow’s core dev meeting.
Click to expand detailed summary
Lightclient presented three strategies for implementing Frame Transactions in the mempool, with the first strategy allowing only senders to pay gas and the second strategy recommending a canonical paymaster approach. The team had discussed these proposals in a previous All Core Devs meeting two weeks prior, and Lightclient noted that the second strategy involving a canonical paymaster could serve 95%+ of use cases while being safer than the full permissionless approach outlined in EIP-7562. Lightclient also mentioned that while Frame transactions could be shipped as a protocol feature without immediate mempool support, their preference was to include mempool support from the start.
The team discussed implementation approaches for EVM restrictions, with Felix clarifying that while tracing could be used, it’s not necessarily required and could be implemented through policies directly in the EVM similar to how static calls work. Lightclient explained that the current 4337 implementation was built as an external mempool system, which differs from their proposed deeper integration approach. Derek suggested an alternative approach of whitelisting pre-compilers to minimize overhead, particularly for frames targeting pre-compilers directly.
The group discussed using pre-compiles for transaction validation, with Felix explaining that while this approach is possible, they have moved away from it in the current proposal. Felix noted that pre-compiles would restrict the chain to a specific approval mechanism and limit key rotation capabilities. Vitalik suggested an alternative approach using in-protocol enshrined code delegation, where users could delegate to pre-compiles representing signature schemes, allowing for approval bits to be used while maintaining similar UX and API as account type declarations.
Vitalik discussed the potential for upgradeability and key rotation through enshrined delegation EIP, noting that it could provide upgradeability “for free” and be the most natural way to implement key rotation. The group explored the trade-offs between single-key and multi-sig approaches, with Chris mentioning a recent EIP on schemed transactions and gas requirements. Nico corrected some gas calculation errors in a previous proposal and highlighted drawbacks of the Falcon scheme, including potential side-channel attacks. Vitalik outlined two possible paths forward: either adding Falcon as a pre-compile or pursuing a more flexible vectorized math pre-compile approach that could support multiple cryptographic schemes without hardcoding specific choices into the protocol.
Felix and Chris discussed the benefits of the Frame Transaction (8141) and proposal 8130 for transaction validation. Felix emphasized that the Frame Transaction allows users to experiment with different signature types without requiring a fork, leveraging existing extension points in the protocol. Chris highlighted the advantages of proposal 8130, including the ability for users to permissionlessly deploy validation logic as a contract and the explicit validation logic in transactions, which enables experimentation and optimization. The discussion also touched on the potential for implementing these features as an ERC and the importance of agreeing on a standardized location for configuration.
The meeting focused on discussing EIP-8141 (Frame Transactions) as a potential headliner for the next fork. Chris explained that 8130 cannot be implemented on 8141 in its current form due to delegation limitations, while Felix clarified that 8141 is intended as a starting point for discussions rather than a finished proposal. The team discussed various implementation challenges, including approval mechanisms and mempool safety rules. They reviewed different mempool strategies, with Ben expressing preference for allowing paymasters in the public mempool rather than requiring bundlers. The group agreed to make a final decision on whether to proceed with Frame Transactions as a headliner at tomorrow’s core dev meeting at 1400 UTC.
Next Steps:
- lightclient: Share the All Core Devs meeting link in relevant places (Discord Ethern D, Telegram AA Mafia) before the meeting at 1400 UTC tomorrow
- vitalik/Matt: Extend the mempool strategies document to add strategy 4 and 5 with more restrictive whitelist-based options for review
- Felix and team (8141 authors): Improve the EIP specification to make the approval mechanism clearer and easier to understand, addressing feedback about complexity
- Felix and team (8141 authors): Work on Derek’s proposal to simplify the approvals in the EIP
- All participants: Attend All Core Devs meeting tomorrow at 1400 UTC to make decision on Frame Transactions as the Headliner
- Non-client developers with perspectives on Frame Transactions: Join All Core Devs tomorrow to share input with core developers
Recording Access:
- Join Recording Session
- Download Transcript (Passcode:
7k=Q15#+) - Download Chat (Passcode:
7k=Q15#+) - Download Audio (Passcode:
7k=Q15#+)
YouTube recording available: https://youtu.be/IJrBJpbnkpg