Derek Chiang | Ethlabs(@decentrek):TLDR: Frames (8141) was just SFI-ed, but it was only meant to signal that Ethereum WILL ship AA in Hegota. It does NOT mean that Frames as written, or even the final EIP number, are set in stone. In the ACDE I was pushing against making the SFI decision now, given that the public pushbacks against Frames and support for 8130 have not been sufficiently addressed. So I felt SFI-ing Frames right at this moment would send the wrong signal that ACD doesn't care about community feedback. However, ACD moderators later clarified that SFI-ing Frames is intended to only signal the ACD's commitment to ship AA, not to Frames's specific content or even the final EIP number. Therefore, this decision does NOT affect the ongoing collaboration between 8130 and 8141, where we are trying to either: - Settle on a shared transaction type that is both flexible and future-proof enough for the L1, and is friendly for the scaling needs of L2s. - Or, if the above is not achievable, then at least ensure that 8130 accounts can be built on top of Frames, so that a 8130 account can share the same address across L1 and L2s, even if it has to use two different transaction types under the hood. In any case, Ethereum WILL ship native AA in Hegota, because Ethereum L1 and L2s deserve the best UX in Web3. Let's get this done.

2026.08.27 17:21

TLDR: Frames (8141) was just SFI-ed, but it was only meant to signal that Ethereum WILL ship AA in Hegota. It does NOT mean that Frames as written, or even the final EIP number, are set in stone. In the ACDE I was pushing against making the SFI decision now, given that the public pushbacks against Frames and support for 8130 have not been sufficiently addressed. So I felt SFI-ing Frames right at this moment would send the wrong signal that ACD doesn't care about community feedback. However, ACD moderators later clarified that SFI-ing Frames is intended to only signal the ACD's commitment to ship AA, not to Frames's specific content or even the final EIP number. Therefore, this decision does NOT affect the ongoing collaboration between 8130 and 8141, where we are trying to either: - Settle on a shared transaction type that is both flexible and future-proof enough for the L1, and is friendly for the scaling needs of L2s. - Or, if the above is not achievable, then at least ensure that 8130 accounts can be built on top of Frames, so that a 8130 account can share the same address across L1 and L2s, even if it has to use two different transaction types under the hood. In any case, Ethereum WILL ship native AA in Hegota, because Ethereum L1 and L2s deserve the best UX in Web3. Let's get this done.

nixo.eth@nixorokish

2026.08.27 17:04

AA update: The Frame Transactions EIP was moved today to Scheduled status for the Hegotá upgrade. It was proposed as a headliner and moved in March of this year to Considered status. There was strong consensus that it was important to ship Account Abstraction in Hegotá even if the specific implementation was still up for debate. There's been a lot of progress in the past few weeks as another implementation, EIP-8130, became a contender. This EIP is scheduled to be shipped on @base in September. It spurred productive conversation async and in a breakout this past Tuesday about the best way to not fracture standards across the ecosystem by shipping two incompatible Account Abstraction implementations between the L1 and L2s. The crux of the issue is arriving at a shared transaction type that both preserves flexibility and future-proofness for the L1 and allows L2s to statically analyze transactions for performance and DoS-resistance reasons. At a minimum, we should make sure that the AA scheme we adopt for the L1 is flexible enough that 8130, or any future account system, can be built on top of it so that from the user's perspective the same account can work across L1 and L2s. Authors of both EIPs, core devs, researchers, and testing teams have been working toward a solution that respects the imperative to get Account Abstraction in the next fork without delay but avoids fracturing ecosystem standards. That said - Account Abstraction _will_ ship in Hegotá, so core devs decided today to move EIP-8141 from Considered to Scheduled today. This was made with the caveat that the version of Account Abstraction that ships in Hegotá may significantly change from what's on the Hegotá Meta EIP right now: potentially the EIP number, the transaction type, etc. The move to Scheduled doesn't materially change the conversation that's been happening over the past few weeks or enshrine the current spec. When an EIP is proposed as a headliner and moved to Scheduled, it just signals an intention to make the fork schedule dependent on that feature being shipped. It's more common than not for the implementation to change significantly between being Scheduled and shipping. Big appreciation to @_chunter of @base, @Offchain, @EthLabs_org, and client teams for moving the conversation forward. Progress is ongoing and can be followed at the AA breakouts on Tuesdays at 14:00 UTC or asynchronously on Forkcast.

Forward to community