Meeting Time: Thursday, March 26, 2026 at 14:00 UTC (90 minutes)
YouTube recording available: https://youtu.be/p0ll3Hj9_MU
The team reviewed updates on DevNet 2 progress and ePPS.net implementation, along with benchmarking improvements and gas repricing concerns from stakeholders. Extensive discussions centered around frame transactions as a potential headliner for the upcoming Hegota release, with debate over implementation complexity, client support, and long-term flexibility needs. After considering various proposals including frame transactions and account abstraction, the team ultimately decided to reject frame transactions as a headliner but agreed to prioritize account abstraction work through a Community Funded Initiative.
The team discussed updates on DevNet 2, with Stefan reporting that it was progressing well despite one issue with ethrex creating too many transactions. Barnabas provided an update on ePPS.net, indicating challenges and a decision to launch with DevNet 1 using new PTSC changes. The team also noted that Prism would likely be the first client ready for ePPS.net, with plans to onboard other clients as they complete their implementation.
Marius presented updates on benchmarking progress using the new Benchmark Core tool, which aims to achieve a 60 megabits per second baseline for all compute and state operations. He reported a roughly 3x improvement through block access lists (BALS) on most compute tests, and discussed several EIPs including EIP 8037 for state creation changes, EIP 7976 for call data flow increase, and EIP 7981 for access list gas cost increases. The team is working on updating legacy tests and contacting clients for potential improvements on specific opcodes that are currently above the target threshold.
Butta presented the results of stakeholder outreach regarding gas repricing, reporting that 21 entities were surveyed with most concerns focusing on complexity rather than price increases. Marius discussed security reviews, revealing that 6.8 million transactions would be affected by the changes, with most being arbitrage bots or ephemeral contracts that could be easily updated. He demonstrated a new benchmarking tool developed by Rafael and the team, which allows testing of different opcode implementations and provides detailed performance metrics. The conversation ended with plans to move to an update on EIP 8070 progress by Bosul.
The team discussed EIP 8070, a non-protocol change EIP that GAT has implemented and documented. Bosul and Ansgar explained they would like to see this EIP go through the same process as other EIPs and be introduced to DevNets. The group agreed to review this at the next DevNet scoping opportunity, with Nethermind also planning to look into it. Regarding the headliner selection, the team discussed whether to choose frame transactions as the EL headliner, with Fossil already selected as a cross-layer, CL-heavy headliner. The discussion included considerations about paymasters and reputation management for ePBS builders.
The team discussed updates on frame transaction mempools, with a formalized document outlining three strategies and updating the EAP to support Strategy 2. Felix announced the addition of native batching to the proposal, allowing users to batch adjacent frames and improving usability. Derek mentioned ongoing work to address concerns from high-performance L2s about the cost of validating transactions with frames, including plans to support pre-compilers in the frame specification. Chris from Base provided transparency about their current stance on EIP-8141, indicating they plan to ship an alternative solution earlier while remaining open to supporting the frame transaction in the future.
The team discussed a new proposal called “schemed transactions” as an alternative or complement to frame transactions. Giulio and Ben presented this proposal, which aims to provide a more minimal and safer approach to account abstraction by separating the signature from the transaction blob and allowing different signing schemes, including post-quantum options. Danno pointed out that there are existing EIPs that achieve similar goals with different approaches. The discussion highlighted the need to consider interactions between frame transactions and other proposals like FOCIL, particularly regarding statelessness and mempool validation. Ansgar clarified that the decision today is only about selecting a headliner proposal, with frame transactions being the main option under consideration.
The team discussed the frame transactions proposal as a potential headliner for account abstraction work. Toni highlighted its generalizability for privacy tools and withdrawal mechanisms, while Felix emphasized that the current proposal is not final and serves as a direction for future development over the next 12-14 months. The discussion also covered concerns about signature substitution attacks and the need for comprehensive support of various use cases including post-quantum signatures, key rotation, and multisig functionality. Vitalik defended the frame transactions approach as the most natural solution that satisfies multiple account abstraction use cases, arguing that simpler proposals would inevitably miss important features.
Vitalik discussed a mempool strategy that allows for restrictive transaction handling while maintaining flexibility for future developments, including the potential implementation of frame transactions. Ansgar advocated for immediate implementation of frame transactions, arguing that the opportunity should not be missed. The discussion centered on balancing immediate needs with long-term flexibility, with Vitalik suggesting that frame transactions could be implemented in a controlled manner without being fully uncontrolled. The group debated whether to generalize both execution and verification flows in the current hard fork or wait for a future opportunity, considering the time pressure due to post-quantum developments.
The team discussed the proposal for frame transactions as a potential headliner for the Hegota release. Most client teams expressed either no support or hesitation, citing complexity concerns, while some community members and L2 teams showed support. Ahmed and others argued for moving forward with frame transactions due to their potential benefits for UX and privacy, though the decision was deferred due to insufficient client support. The group considered alternative approaches, including a “nerfed” version of frame transactions with limited functionality, and discussed the possibility of selecting frame transactions as a non-headliner option.
The meeting focused on discussing whether to select frame transactions or account abstraction as a headliner for the upcoming fork. After extensive debate, the group decided to reject frame transactions as a headliner due to insufficient client support. They also chose not to select a general account abstraction theme as a headliner at this time. However, the group agreed to prioritize account abstraction work going forward, though this commitment would not have headliner status. As a compromise, they decided to CFI (Community Funded Initiative) frame transactions, allowing for further exploration and potential implementation in the future. The conversation ended with an acknowledgment that account abstraction remains an important topic for Ethereum’s development.
^!E?6#U5)^!E?6#U5)^!E?6#U5)YouTube Stream Links: