RIP-7560: Native Account Abstraction

An account abstraction proposal that introduces consensus-layer protocol changes, instead of relying on higher-layer infrastructure.

Combining the EIP-2938 and ERC-4337 into a comprehensive Native Account Abstraction proposal.

We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,
and post-transaction logic.
Transaction validity is determined by the result of the validation steps of a transaction.


Wow! That’s awesome!
and what does ‘EIP-9999’ refer to in the markdown file?


This is really nice, stays compatible with 4337, optimizes Gas, and solves the problem of Bundler being private now, which is very significant for account abstraction adoption!

1 Like

Why is unused gas a concern specifically for AA transactions and not regular EOA transactions?

Because of the separate validation and execution stages for AA transactions, it’s harder for the block builders to account for an unused gas discrepancy.

It’s described here


Generally this RIP is amazing but the elephant in the room is the upcoming/placeholder EIP-9999, would be really fantastic to see what it refers to.

Otherwise great job!

My main comment would be about the version parameter in the validation function. I think it makes way more sense for upgrading to simply change the signature of the function either by changing the parameters or append a _v* to the function name. The rationale for this is that it allows wallet implementation with fallback handlers and modules to update in an easier way.

At the risk of sounding like an optimizooor, it’s unfair to expect wallet implementations to implement full delegatecall upgradability cause it adds one mandatory SLOAD to each transaction.

IMO, this adds lots of complexity to the core protocol for something that can be done outside of it.

There’s the issue of multiple competing AA standards, with none having widespread use. If AA ends up being enshrined, it should look like what the leading AA standard looks like. Changing how AA works after a hard fork enabling it would be a massive PITA for everyone and would only slow progress.


IMO, the amount of complexity that this adds to the core protocol makes it not worth it. AA is continuing to evolve (for example intent based AA like UniswapX, ERC-7521, etc) and this would lock things into only the current solution.

Also, does this remove support for signature aggregation? I thought that was one of the biggest selling points of ERC-4337 since it gives huge cost savings to optimistic rollups.

1 Like

I also don’t see how the “unused gas” griefing vector described can’t also be done with an EOA transaction. Is there a better description of the attack somewhere that explains how it’s unique to user ops?

what’s the estimated timeline for EIP-9999? it contains some important things regarding this RIP, but overall a good proposal, is backwards compatible, enshrines most of the stuff

@cejay @Ivshti @sk1122
The EIP-9999 was just a temporary placeholder for the “ERC-7562: Account Abstraction Validation Scope Rules” document before it had an assigned number. I apologise for any confusion.

@pantaovay thank you very much!

Re: “changing the signature of the function instead of a version parameter”, we had an intention to make sure that we are only creating a single set of ‘special’ method IDs. However, if the method signature were to change with every revision of this RIP, their method IDs would change as well.

@makemake @PixelCircuits
This complexity is one of the reasons this proposal has been labeled as a “Rollup Improvement Proposal”, so hopefully it would not lead to locking things into a single solution too much.

Re: Signature Aggregation, it will not be removed from Native Account Abstraction but it is not part of this RIP, which is complex enough. “Native Account Abstraction Signature Aggregation” will probably be a separate RIP document in the near future.

1 Like

I also don’t see how the “unused gas” griefing vector described can’t also be done with an EOA transaction. Is there a better description of the attack somewhere that explains how it’s unique to user ops?

The issue of unused gas is only relevant for Type 4 Transactions because they can have their execution behaviour influenced by transactions that are coming after them in a block. This does not seem to be a problem unless the transaction suddenly starts using more gas than it used before.

Here is an example of how this could be turned into an attack on the block builder.

Here, Transaction #4 has a gas limit of 10’000’000. However, it only used 50’000 gas so there is a lot of available gas space in a block.

However, once Transaction #6 is included in a block and its validation phase flips some flag, Transaction #4 starts consuming the entire 10’000’000 gas.


So does the unused gas penalty go away after ERC-7562?

So does the unused gas penalty go away after ERC-7562 ?

Unfortunately, there seems to be no way to prevent the “flickering” gas usage by transactions with validation rules alone.
The “waste gas flag” storage can be read during execution phase of any transaction, and the “validation rules” are not meant to be applied during the execution phase.

1 Like

TL;DR: that’s the cost of account abstraction.

The complexity doesn’t come from the protocol itself (eip-7562 or ERC-4337) - It comes from the fact we want to use general-purpose EVM code for validation, which makes one transaction depend on external data - shared with other transactions, or with the external world.
With EOA, the validation is hard-coded into the protocol and depends only on the state of the account itself.
This means that a previously validated transaction can only be invalidated by issuing another transaction with the same sender (and nonce) to replace it.

With account abstraction (ANY implementation - 7560, 4337, 2938, and even 3078) we must have a mechanism to ensure the same isolation, otherwise, maliciously crafted transactions can cause mass invalidation: transactions that are accepted and propagated into the mempool, which later becomes invalid and thus draw resources from all nodes without a cost.

Removing this complexity exposes block-builders to DoS attacks, or requires removing the general EVM-code usage (the essence of account abstraction)

1 Like

I’m not against complexity, just complexity at the core protocol level. At least ERC-4337 is opt-in and I can ignore it if I think there is too much risk or chose an alternate smart contract based AA solution. With this proposal, if something goes wrong for builders (some new DoS vector is found and exploited) or some bug is found, it would take down the whole network, including users who never cared about ERC-4337 style AA.

To me, it feels like trying to embed an OS into the bare metal. The bug surface area is too large and it would alienate others who want to use a different OS.

Pasting the reply I sent you in 4337 Mafia on telegram in case others also wonder:

It protects the builder against a DoS vector, also applicable to 4337 bundlers (which is why the next EntryPoint version will have this as well).

Consider a builder trying to construct a block containing many AA transactions. It creates a batch of AA transactions (equivalent to a 4337 bundle) where all the validations will be executed, followed by all the executions. To work efficiently and not have to validate transactions sequentially, it wants to create the largest possible batch, validating all the transactions in parallel against the same state. Otherwise it can’t parallelize because transactions can invalidate each other, which makes it vulnerable to DoS by many mutually-exclusive transactions where one transaction’s execution invalidates another’s validation.

An attacker could send transactions that have a high callGasLimit which they actually use when simulated separately, but that changes its behavior to use almost no gas when it detects that another transaction’s validation has been executed. Suppose the batch has [tx1,tx2]. tx2.validation sets tx2.sender.flag=1, and tx1.execution does return (tx2.sender.flag==1 || waste5Mgas()). It is allowed to access tx2.sender.flag because it happens during execution rather than validation. The builder created the batch, thinking tx1 will use 5M gas and fill up the rest of the block, but due to the above behavior, 5M gas worth of of blockspace is not utilized. The builder now has to append more transactions sequentially (not parallelized), simulating each of them against the state after all the others in order to know how much gas it really uses.

By penalizing unreasonably high unused gas, we make this attack less scalable.

It’s ERC-7562. We extracted the ERC-4337 validation rules to a separate (and hopefully more readable) ERC since they’re identical in both systems.


I see Alex already replied this, but I’ll add that it was requested by one of the L2s. They wanted to be able to add future extensions (maybe even specific to their own network) without having to redeploy or update accounts.

I think making accounts upgradable offers security and usability benefits, well worth the SLOAD. But we’re also looking for ways to make it cheaper. For example, EIP-7557 could make it as cheap as 32 gas for a widely used account while also making the protocol fairer. Support EIP-7557 :slight_smile:

To put this in context, the RIP is meant for rollups that already added, or are considering adding the complexity of native AA. Some already have, and some are planning to. The purpose of this RIP is to standardize it for those who do, and avoiding fragmentation of the wallet ecosystem (wallets supporting only one chain, which is currently the case in chains that added their own form of native AA).

and that’s precisely what this RIP does. ERC-4337 has been gaining some traction, and has been used to add native AA in nonstandard ways by two L2 chains. RIP-7560 is an enshrined version of ERC-4337, optimized for rollups.

It shouldn’t. That’s why we separated RIP-7560 and ERC-7562. The mempool validation rules are incompatible with some forms of intents, but RIP-7560 isn’t. Intent systems could benefit from RIP-7560 while being incompatible with the ERC-7562 mempool and using a separate intent-solvers network. It’s one of the design goals.

No. But aggregation will be a separate RIP, to be published soon.

It’s meant for chains that choose to embed this into their “OS”. For example, Starknet and zkSync already embedded a similar native AA system (both are based on ERC-4337 with some mods). You’re right that there is no way for you to opt out of it on these chains, whereas on a chain that doesn’t implement native AA, you can choose whether to use ERC-4337 or not. L2 chains sometimes choose to be more opinionated about their OS for the sake of optimizing their UX and efficiency. However, the Ethereum ecosystem offers enough choice of L2s so you can opt out by using a different one. Some may choose to implement it early, some may be more conservative and wait.

1 Like

Will this lead to a precompiled contract for secp256r1 curve support, so we can finally implement wallets that integrate with the built-in private key encryption used in operating systems and secure enclaves?

1 Like