Meeting Time: Thursday, March 05, 2026 at 15:30 UTC (60 minutes)
The meeting focused on discussing a proposal to add EOA support to Frame transactions, with participants debating the benefits and trade-offs of this approach compared to existing solutions like EIP-7702. The team explored various technical implementation details including performance concerns, validation methods, and mempool rules, while discussing how Frame transactions could provide more flexibility and better defaults for users. Concerns were raised about user safety and mempool implementation, with the discussion concluding on the need for further exploration of implementation details and a follow-up meeting to make final decisions.
The meeting focused on discussing a proposal by Derek from Zero Dev to add support for EOAs (Externally Owned Accounts) natively in the Frame transaction. Derek explained that this change would address concerns about adoption pace and make Frame transactions more impactful by allowing EOAs to send sponsored transactions and pay gas in ERC20 tokens. The group discussed how this modification would enable existing EOA users to benefit from Frame transactions, potentially increasing adoption and community engagement.
The team discussed adding EOA (externally owned account) support to EIP-8141 frame transactions as an alternative to EIP-7702. Derek and Felix clarified that this would not insert permanent code into EOAs but rather define client behavior for accounts without existing code during frame transactions. The group agreed that providing good defaults is important, especially for wallets and applications that may not have resources to audit custom account implementations. While some questioned whether this would reduce incentive for hardware wallet support of EIP-7702, the consensus emerged that this trade-off was acceptable to enable broader adoption of frame transactions and batching capabilities.
The team discussed the long-term strategy for EIP-7702, agreeing that it needs to be replaced due to its lack of post-quantum security. Felix outlined two potential approaches: either deploying new accounts without ECDSA keys using frame transactions, or upgrading existing accounts to smart accounts through delegation. The group acknowledged that EIP-8141’s addition of EOA support would likely improve its adoption, with most attendees already supporting the standard. Nicolas highlighted the need for additional EIPs to support PQ migration, including private key deactivation and EOA system contract features. The team agreed to continue developing the default EOA interaction format in open forums over the coming weeks.
Chris discussed exploring a new verification approach for EOA transactions that would use native implementations rather than running arbitrary code, potentially through a new “native verify” frame type or by targeting verification to a precompile. Felix clarified that the current EIP structure allows for this approach by enabling direct verification through precompiles, which would provide a fast path for authorization similar to existing extensibility mechanisms. The discussion focused on balancing performance benefits with maintaining security and compatibility with existing signature schemes like EIP1271.
The group discussed performance concerns with the current EIP implementation, particularly around the need for transaction simulation to validate rules and determine if transactions should be stored in the mempool. Chris highlighted that without precompiles or native validation, they need to simulate transactions to check for compliance with rules like ERC7562, which creates significant computational overhead. The discussion explored options including using precompiles for verification frames and batched signatures, with Vitalik questioning whether the performance impact from 100 EVM steps was a major concern. The conversation also touched on the possibility of native delegation and account wrappers as alternative approaches.
The team discussed the performance implications of transaction approvals in the context of account abstraction, acknowledging that validation costs will increase compared to the current state. Felix explained that the Frame Transaction approach aims to provide users flexibility while maintaining low gas limits suitable for mempool validation. The discussion covered two main transaction flows: deploying a new account and sending to an existing verified smart account, with specific frame structures being proposed for the public mempool. The team also addressed concerns about gas limits and mempool rules, noting that while the framework provides flexibility, mempool environments will necessarily have more restrictive requirements than the full execution environment.
DanielVF expressed concerns about frame transactions, arguing that providing nearly unlimited flexibility could expose users to significant danger and create user experience friction similar to existing account abstraction methods like 7702 and 4337. He favored simpler, tempo-style transactions that would be safer and more likely to achieve user adoption without limiting future evolutionary possibilities. Felix defended the frame transaction approach, explaining that it aims to create a single, comprehensive transaction type that can handle all current and future needs without requiring additional transaction types, while also removing signatures from the protocol level to enable future flexibility in signature schemes.
Felix explained the key differences between adding cryptographic systems at the EVM level versus transaction level, highlighting that Frame Transactions provide more flexibility and allow users to handle implementations as they see fit. He also addressed concerns about batch validation of post-quantum signatures, noting that verify frames in Frame Transactions cannot influence transaction outcomes and can potentially be batched or elided to reduce block size. The discussion concluded with Parthasarathy raising questions about Tempo Transactions and requesting more technical details on why they might be considered superior to Frame Transactions.
The team discussed the possibility of restructuring Frame transactions to separate transaction payload and signatures into different top-level elements, similar to EIP 6404. Felix clarified that while the current EIP proposal is not final and may undergo significant changes, they are exploring solutions to enable signature aggregation while maintaining transaction hash integrity. Chris raised concerns about frame ordering and state visibility across the EVM, but Felix explained that frames provide necessary visibility into user intent and computation structure, and any required changes could potentially be addressed through additional frame types if needed.
The group discussed concerns about mempool rules and their implementation in relation to frame transactions and EIP proposals. Frangio highlighted the need for clearer guidelines on what is allowed in the mempool from a developer’s perspective, referencing issues encountered with EIP 7702. Felix acknowledged these concerns and explained that the team is still exploring implementation details, including frame structure and gas considerations. Lightclient suggested reviewing the ERC 7562 standard created by the 4237 team as a starting point for addressing mempool challenges. The discussion concluded with an announcement that the proposal would be discussed again at the upcoming AllCoreDevs meeting next Thursday, where a decision on the Headliner for Hagota would be made.
d1QHe&b+)d1QHe&b+)d1QHe&b+)YouTube recording available: https://youtu.be/JWXwDn50oXM