Frame Transaction Breakout #2, August 25, 2026

Protocol Calls & happenings
1

Agenda

Meeting Time: Tuesday, August 25, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

2 Likes
2

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

3

Meeting Summary:

The meeting focused on comparing and discussing the two main proposals for native account abstraction on Ethereum: EIP-8141 (Frames) and EIP-8130. Matt provided an update on recent developments in Frames, highlighting clarifications and the integration of 2D gas support from the upcoming Amsterdam fork. Toni mentioned privacy protocol proofs of concept built on Frames. Chris presented the case for EIP-8130, arguing it offers a more cost-effective and declarative approach by keeping authentication, authorization, and execution decoupled, and cited its adoption by Base and other L2s. The discussion delved into technical differences, such as the account model, stateless validation, and the ability to support new signature schemes. Participants like Derek, Pedro, and Mislav debated whether the protocol should own the account model or provide generic tools, with some expressing concern about enshrining specific logic in the protocol. The conversation also touched on the potential for interoperability and the possibility of synthesizing elements from both proposals. The conversation ended with a call for further exploration of integrating key aspects, like a keystore, into Frames to address concerns and find common ground.

Click to expand detailed summary

The meeting focused on comparing two Ethereum account abstraction proposals: EIP-8141 (Frame Transactions) and EIP-8130. Matt provided an update on Frame Transactions, highlighting recent clarifications and integration of Glamsterdam changes, including explicit two-dimensional gas support. Chris presented EIP-8130, explaining its approach to maintaining a decoupled architecture for authentication and authority while enabling portability across different chains. The discussion revealed differences in how the two proposals handle gas payment and authentication schemes, with participants debating the merits and potential limitations of each approach. The conversation ended with an open discussion period, encouraging attendees to focus on finding solutions and next steps for moving forward with these proposals.

The discussion focused on comparing EIP-8130 and EIP-8141 proposals, with Chris explaining that EIP-8130’s decoupled architecture allows for easier implementation of pure function authenticators, including permissionless payers, while EIP-8141’s coupled bytecode structure limits this flexibility. Felix questioned the DOS risks and mempool considerations, leading to a discussion about pure execution and state access. Kushal asked about storing authentication information within account objects rather than in a separate contract, but Chris explained his preference for the contract approach due to portability reasons and to avoid larger EVM modifications.

The discussion centered around the implementation of EIP-8130 versus existing work on frames, with concerns raised about forcing 8130 onto L1 without incorporating feedback from L1 developers. Chris explained that 8130 allows for traceless profiles using pure functions and pre-compiled dependencies, while also discussing options for transaction assertions through either transaction events or a precompile. The conversation highlighted potential challenges with coexistence between 8130 and L1’s frames work, with some participants suggesting that the two standards might need to operate separately on different chains while maintaining compatibility at the SDK/interface level.

Derek raised concerns about shipping EIP-8130 without incorporating feedback from L1 teams, but Chris confirmed that Base would be willing to delay the fork to ensure alignment across L1 and L2 implementations. Ivan from Ifrex announced their continued support for frames, highlighting their implementation progress and upcoming network launches. Pedro emphasized that the core discussion should focus on whether the protocol should own the account model rather than getting caught up in EIP numbers, arguing that protocol ownership would provide better portability and reduce implementation burdens for wallet developers.

The team discussed whether the L1 should own account-related logic, specifically focusing on EIP-8130 which includes both account definitions and a validation model. Mislav suggested that account logic might be better handled outside core clients through a separate governance process, while Derek proposed considering only the validation model from EIP-8130 rather than the full account specification. Tomás emphasized the philosophy of keeping the EVM flexible to allow various implementations on top of it, supporting the decision to support Frames over EIP-8130.

Chris and others discussed the differences between proposals 8130 and 8141, focusing on account models, authority management, and the potential for recreating 8130’s functionality using 8141. Nicolas emphasized the benefits of Frame’s forward-thinking signature and Stark aggregation for scaling the L1, arguing that 8130 might sacrifice these gains for L2 efficiency. The group debated the expressiveness and scalability of different approaches, with Nicolas highlighting the potential for ongoing governance challenges and security concerns with enshrined account models.

The meeting focused on comparing EIP-8130 and EIP-8141 for account authentication models, with discussions about their respective merits for L1 and L2 implementations. Key points included:The group agreed that L1 should not enshrine opinionated account models but should provide tools for market adoption, while L2s may have more flexibility. There was consensus that the authenticator-based validation model from EIP-8130 offers benefits for L2s, though L1 may not adopt its full account system due to concerns about governance and maintenance.Next steps identified include creating a companion EIP for keystore functionality to address L1-L2 interoperability needs, with the goal of time-boxing collaboration between the two EIPs to find common ground before potentially accepting fragmentation between L1 and L2 standards.

Next Steps:

  • Chris: Share the slides and video link for the 8130 presentation in the chat.
  • Ifrex: Announce the two new networks (privacy-only testnet and Jigota-like playground) later this week or early next week.
  • Matt: Consider drafting a proposal to add a keystore to Frames (EIP-8141) or as a companion EIP, to explore integrating the keystore concept from 8130.
  • Chris: Work with L1 client teams and core devs to incorporate feedback and potentially delay the Base fork to ensure the best possible spec for 8130.
  • All stakeholders: Continue discussions to find common ground and consider specific tweaks to Frames (EIP-8141) that could make it more acceptable to a wider range of stakeholders.

Recording Access: