Native AA is shaping up to be one of the most controversial topics in Ethereum history. With no fewer than six competing EIPs, Ethereum’s core devs have already tried and failed twice to decide on a specific proposal, with a third attempt scheduled for this Thursday.

In this post, I’d like to make the case for Frame Transactions (EIP-8141). I argue that Frames provides the most flexible foundation for supporting AA use cases, and that the primary concern with it — the complexity it may introduce for developers — can be addressed with powerful defaults that simplify the common workflows. I will also zoom out and explain why now is the right time for Ethereum to start working on native AA.

Frame Transactions is the flexible foundation for today’s use cases, and tomorrow’s

When designing an AA protocol, most EIPs take a “top-down” approach:

• Identify a set of AA use cases that the authors believe are of the highest value.
• Design a protocol that supports those use cases.

While this approach is intuitive, it suffers from two limitations:

• Deciding which subset of AA use cases is most important is inherently subjective. Is paying gas with stablecoins important? Is sending transactions privately important? Is multisig important? Indeed, when you compare most AA proposals that position themselves as alternatives to Frames, you find that they support different subsets of use cases. But who’s to say which subset is the right one?
• Proposals designed around today’s use cases are bound to miss tomorrow’s. For example, with the rapid development of ZK technologies, we are seeing a wave of privacy protocols that could enable private transactions — but today’s AA proposals are rarely designed with those cases in mind.

Frame Transactions, on the other hand, takes a bottom-up approach. It starts by asking: what is the smallest set of axioms (think LEGO blocks) that, when composed together, can enable the largest set of AA use cases?

Frames’ surprising insight is that, to support all the AA use cases we know today — and the ones we don’t yet know — you only need three axioms:

• A transaction is composed of a series of contract calls that we call “frames.”
• A frame can authenticate and/or pay gas for the transaction.
• A frame can introspect other frames.

To understand how these seemingly simple axioms enable powerful AA features, let’s look at a concrete example that is rarely supported in other AA proposals: paying gas in ERC20 tokens.

Case study: paying gas in ERC20 tokens

Say a user owns some USDC but no ETH. In today’s world, the user would have to acquire ETH somehow in order to send any transactions, but they can’t even swap their USDC for ETH because they would need ETH for that transaction in the first place.

With frame transactions, users can pay gas in ERC20 tokens with no dependency on centralized relayers. Such a transaction would consist of five frames:

• Validating the sender: Call the user account to validate the signature, then approve the transaction.
• Validating the gas payer: Call the paymaster contract, which introspects the next frame to confirm that the user is transferring ERC20 tokens to the paymaster, then approves gas payment for the transaction.
• Paying the gas payer: Call the ERC20 contract to transfer tokens to the paymaster.
• Executing the target action: Call the target contract to execute the user’s intended action.
• Refunding unused gas: Call the paymaster contract to refund unused gas to the user.

Notice how this flow makes use of all three axioms:

• The transaction lifecycle is broken down into five steps (frames), all executed by smart contracts. None of the logic needs to be hardcoded into the protocol.
• Frame 1 authenticates the transaction.
• Frame 2 introspects Frame 3 to confirm that the user is transferring ERC20 tokens to the paymaster, and only approves gas payment if that condition is met.

Supporting this workflow requires careful orchestration between the transaction sender and the gas payer, which is why it’s difficult to hardcode this mechanic into an AA protocol. With Frames’ flexible architecture, however, no hardcoding is necessary. This complex use case emerges naturally from composing the three simple axioms.

Is flexibility a curse?

One common pushback against Frames is this: its flexibility is actually a curse, because it introduces complexity for downstream developers. For example:

• Wallets using frame transactions may need to entrust their security to smart contracts.
• Transaction validation shifts from a simple O(1) operation (checking signatures) to executing arbitrary EVM code, which introduces new DoS vectors for both L1 and L2 mempools.

These are valid concerns for early versions of Frame Transactions, and they are exactly the concerns I shared with the EIP co-authors. Over the last month, however, we’ve been working hard to address these issues. The solution can be summarized in one idea: powerful defaults.

Powerful defaults

Default account for wallets

From our experience with ERC-4337, the biggest hurdles to AA adoption come from two sources:

• Existing EOA users do not want to migrate to a new account, regardless of the UX benefits.
• Wallets do not want to introduce new attack surfaces by relying on smart contracts.

With the latest iteration of Frame Transactions, we address both concerns with a powerful idea: a default account for EOAs. When an EOA sends a frame transaction, it is treated as if it is operating through a “default smart account” whose security is guaranteed by the protocol. This default smart account supports the core flows of a typical smart account, without requiring wallets to trust new smart contracts.

The default account can also support more than k1-based EOAs — it can support other signature schemes such as passkeys (r1). This means that wallets can even support non-k1 keys without trusting new smart contracts, significantly lowering the barrier to adopting new signature schemes.

Canonical frame structure for mempools

Developers of high-performance L1s such as Tempo/Monad and L2s such as Base have raised concerns about turning transaction validation — normally just a signature check — into arbitrary EVM execution. This makes it harder to maintain both high throughput and mempool safety.

Again, the answer is defaults — specifically a canonical frame structure that mempools can rely on. For example, while a validation frame could theoretically appear anywhere in a transaction (even at the end), requiring mempool nodes to execute the full transaction to verify it, the default structure requires transactions to begin with a verification frame in order to be safely accepted.

To further bound validation cost, chains can implement a maximum verification gas limit, capping how much EVM execution a mempool node must perform per transaction. For mempools that prioritize maximal throughput or safety, they can go even further and support only the default account, which has known and bounded validation cost.

Defaults can be overridden

A natural pushback against defaults is: if the defaults are so good, why not just enshrine them? Indeed, many other AA proposals are effectively the equivalent of enshrining Frames’ default account and validation structure and therefore enabling common AA use cases such as alternative signature schemes and gas sponsorship, with only limited complexity and costs.

But this is precisely why Frames is the better design. The defaults work great for the common case, but they can be overridden for advanced use cases. When you build on a flexible foundation, you retain the ability to design new solutions when needed. That flexibility is lost when the foundation itself is rigid, which is the unfortunately reality with other AA proposals.

Why now is the time for native AA

It’s tempting to look at the current landscape of AA proposals and say: “why not wait one more hard fork?” Surely by the next cycle, we will have learned more and converged on the perfect design.

One argument against that is simple: we have already been debating AA for years, and there’s no reason to believe that it will be easier to come to a decision next time.

More importantly, within the broader Ethereum roadmap, there are three major efforts actively underway that have strong synergies with native AA. Delaying AA again would mean missing the opportunity to develop these systems together. These efforts are:

• Censorship resistance via FOCIL
• Statelessness via VOPS
• Quantum resistance

While a deep dive is out of scope for this post, it’s worth noting that Frames is unique among AA proposals in having been reviewed by researchers in all three areas and found to be architecturally compatible with each. Here is one example for FOCIL + Frames.

Of course, the details of these interactions still need to be worked out, but that’s exactly the point. We should begin now and develop native AA in parallel with these mechanisms, so that AA is treated by these important mechanisms as a first-class citizen rather than something bolted on later.

Conclusion

Frame Transactions (EIP-8141) is the best candidate for Ethereum’s AA standard, because it’s the only proposal that offers a flexible foundation that can support all AA use cases, while providing powerful defaults for the most common AA flows. Furthermore, it has great synergies with other areas of the Ethereum roadmap, including privacy, censorship resistance, statelessness, and quantum resistance. The best time to bring native AA to Ethereum is now, and Frame Transactions is our best shot.