Meeting Summary:
The meeting focused on discussing native account abstraction proposals, particularly EIP 8141 (Frame Transactions), which was recently proposed as a headliner for the Ethereum upgrade after Glamsterdam but was not selected by client teams. Participants shared their perspectives on what goals native account abstraction should accomplish, with wallet developers emphasizing practical efficiency and hardware wallet support, while others highlighted the importance of post-quantum security and reducing centralization around transaction flow. The discussion covered updates on various proposals, including Frame Transactions’ efforts to balance flexibility with performance concerns, and the introduction of new EIPs for contract payer transactions and counterfactual transactions. Key concerns were raised about mempool implications, statelessness, and the handling of ERC20 tokens, with participants debating implementation strategies and the need for further coordination with L2s and wallet teams.
Click to expand detailed summary
The meeting focused on discussing native account abstraction proposals following the recent proposal of EIP8141 (Frame Transactions) as a headliner for the Ethereum upgrade after Glamsterdam. Marc explained that while EIP8141 was not selected as the headliner due to client teams needing more time to understand implications, it generated momentum for shipping native account abstraction in the Hegotap fork. The discussion began with an acknowledgment that different stakeholders have different views on what account abstraction should accomplish, and the meeting was structured to help the group refine their understanding of goals and trade-offs before moving forward with proposals.
Ivo provided insights from a wallet developer perspective, highlighting challenges with existing account abstraction solutions, particularly around upgrade paths and hardware wallet support. Agusx1211 shared their team’s support for frame transactions, emphasizing their value in enabling new functionalities and reducing dependency on centralized relayers. Lightclient discussed the focus on post-quantum security as a rallying point for account abstraction efforts and highlighted the goal of reducing centralization in transaction flow. The discussion also touched on the importance of supporting post-quantum aggregation techniques and hardening functionality in the protocol.
Ben expressed concerns about the practicality of frame transactions, noting high gas costs for post-quantum signatures and the current lack of efficient EVM implementation. Mislav supported frame transactions, highlighting their ability to coordinate across the account abstraction community and address existing use cases effectively. The discussion touched on the need for native crypto operations and precompiles for efficient processing, with some participants suggesting that current frame transaction proposals could be improved with minor changes.
The discussion focused on key features needed for native account abstraction, with Prestwich highlighting the importance of transaction batching and permanent key invalidation. There was significant debate about the priority of gas abstraction features, with some participants emphasizing the need for ERC20 gas payment and sponsorship capabilities, while others argued against over-engineering for unspecified future features. Chris noted that different teams have varying opinions on priorities based on their specific use cases, and mentioned that frame transactions aim to address performance issues while being more defined than previous proposals. The conversation ended with a transition to proposal updates, as Marc acknowledged that reaching consensus on account abstraction features may not be reasonable yet but emphasized the value of hearing different perspectives.
Derek provided updates on the frames side, highlighting two competing goals of AA that are pushing YACs and EIPs in different directions: flexibility for privacy protocol transactions and predictable performance in the mempool. He introduced a new solution allowing payment frames to come before sender validation frames, enabling transactions to be approved and paid for without requiring immediate sender signature validation. This approach aims to achieve predictable performance in the mempool while still allowing arbitrary sender validation logic.
Ben discussed updates to frame transactions, including the addition of contract payer transactions (EIP-8223) and counterfactual transactions. He explained how these new features would allow for lighter verification of transaction payments and key rotation capabilities. The discussion touched on concerns about gas sponsorship for privacy pools and how guarantors would work in the new system. Parthasarathy raised questions about migration paths for existing wallets to adopt the new EIP, emphasizing the importance of user retention and ease of migration.
Fredrik discussed the development of transaction assertions as a solution to address security issues like phishing and draining attacks that prevent mass adoption of Ethereum. He explained that transaction assertions would allow users to approve an “envelope of effects” and revert transactions if the actual outcome goes outside of the specified policy. The team plans to create a proof of concept demo to show how transaction assertions work with frame transactions and prevent malicious transactions. Alex, the author of EIP-7906, joined the discussion and expressed interest in collaborating with Ethrex on the demo implementation.
The meeting focused on discussing Frame transactions and their implementation challenges. Key topics included adoption strategies for native Account Abstraction (AA), compatibility with existing systems, and post-quantum cryptography support. David from Trust Wallet highlighted the need for wallets to audit their smart contracts and implement new features, noting that nearly 100 million weekly transactions already use related techniques. Derek from Zero Dev emphasized three core adoption barriers: smart contract auditing, reliance on relayers, and compatibility across chains. The group discussed concerns about EVM usage costs and mempool implications of Frame transactions, with Ben raising questions about transaction processing efficiency. Carlos from the Ethrex team questioned the strategy for supporting ERC20 tokens and asked for clarity on the approach moving forward. The conversation ended with discussions about post-quantum cryptography support and the need to define specific implementation details in the coming weeks.
Next Steps:
- Derek and frame transaction authors: Continue working towards consensus with L2s (BASE, Arbitrum, OP) on frame transaction specifications to address their performance and cost concerns
- Fredrik and Alex (7906 authors): Create a proof of concept demo showing how transaction assertions work with and without EIP-7906
- Fredrik and Alex: Coordinate with Ethrex team on creating a demo showing how EIP-7906 integrates with frame transactions
- Fredrik and Alex: Create tests for EIP-7906 for potential inclusion in future hard fork
- Derek and frame transaction authors: Define and finalize the set of canonical verifiers (smart contracts wrapping existing pre-compilers like EC recover and P256 verify)
- Frame transaction authors: Resolve the strategy for ERC20 sponsorship (whitelist vs. requiring all nodes to hold all ERC20s vs. paymaster-based approach) and clarify approach with wallets and stakeholders
- Frame transaction authors: Address statelessness compatibility concerns raised by Carlos within the next few weeks
- OP team members: Join the group chat with BASE and Arbitrum regarding L2 discussions on native AA
- Marc: Work to get the meeting recording up on forecasts
Recording Access: