# Roadmap for Native Account Abstraction Introduction

The [ERC-4337 Account Abstaction](https://eips.ethereum.org/EIPS/eip-4337) model has been [gaining traction on many networks](https://dune.com/niftytable/account-abstraction). Multiple L2 protocols, such as [ZkSync](https://era.zksync.io/docs/reference/concepts/account-abstraction.html) and [StarkWare](https://starkware.co/resource/native-account-abstraction-opening-blockchain-to-new-possibilities/) have moved forward with the introduction of a modified version of ERC-4337 Account Abstraction into the core of their execution layers.

We believe standardization and network effect are critical to the success of any Account Abstraction initiatives, so we are inviting everyone to participate in the creation of the Native Account Abstraction standard that can be adopted by all Layer-2 and Layer-1 networks.

The draft PR for the RIP-7560 is available here:
[RIP-7560: Native Account Abstraction](https://github.com/ethereum/RIPs/pull/3)

## What does this mean for the ERC-4337 ecosystem?

First of all, cross-compatibility with the ERC-4337 is going to be the top priority for the Native AA design. It is crucial that we do not end up creating two competing Account Abstraction protocols but provide a continuous ecosystem. Some networks are expected to implement Native AA earlier than others and both flavors of Account Abstraction will coexist indefinately. Crucially, there is a straightforward migration path for projects to gradually migrate to the Native Account Abstraction once it is added by the respective network.

However, making Account Abstraction a first-class citizen changes some things and there are some modifications that all ERC-4337 projects will have to make in order to support Native AA in the future.

### The `UserOperation` becomes `TransactionType4`

The original struct and its name were specifically chosen to avoid confusion with actual Ethereum transactions.
As this is no longer the case with Native AA making `UserOperations` actually individual transactions, this term is no longer relevant. However, TransactionType4 will have fields similar to UserOperation and work the same way when put on chain.

### Smart Contract Accounts

Smart Contract Accounts will need to upgrade their implementation to support the Native Account Abstraction protocol.

The full list of changes from the wallet's perspective:

1. The `EntryPoint` address is set to a system-wide constant value.
2. The `validateUserOp` function is renamed and has some different parameters. It has to return a "magic value" to accept a transaction.
3. The accounts will no longer need to maintain a deposit in the `EntryPoint` contract to pay for gas and their balance will be charged directly. Of course, if a `Paymaster` contract is used the account will not be charged.

### Paymaster Contracts and Paymaster Services

A `Paymaster` contract will likely need to be upgraded or redeployed with some modifications to their code.
Approvals for ERC-20 tokens and other assets, including state may require manual migration in this case.

The full list of changes from the Paymaster's perspective:

1. The `validatePaymasterUserOp` function is renamed and has some different parameters. It has to return a "magic value" to accept a transaction.
2. The `Paymaster` contracts will no longer need to maintain a deposit in the `EntryPoint` contract to pay for gas and their balance will be charged directly.

### Account Factories

There is no change to the `Factory` contracts used in Account Abstraction. The same contracts can be used and account addresses will be the same whether deployed via ERC-4337 or the Native AA flow.

### Aggregators

Signature Aggregation is not a part of the first Native Account Abstraction EIP and will be introduced as a standalone, optional, and backward-compatible EIP later. Some changes to the `Aggregator` flow from the ERC-4337 are to be expected.

### Validation Code Rules, Staking, and Reputation systems

`Validation Code Rules`, `Entity Staking`, and `Entity Reputation` are identical to those of ERC-4337 but they are not part of the Native AA EIP/RIP.

These concepts are an important part of the Account Abstraction protocol and there will not be two separate rule systems.

Instead, the definitions and specifications for these concepts are being moved into a separate [ERC-xxxx: Account Abstraction Validation Scope Rules](https://github.com/eth-infinitism/account-abstraction/pull/342/files#diff-bcee933283b40cf03dcf7913aad7c6437f25dcf4ffe2365dcc09d00e3e6512f3) that the bundlers and block builders in both ERC-4337 and Native AA will use to enable safe and efficient operation of a mempool and block production.

### Mempool

The `TransactionType4` mempool will operate in exactly the same way as the ERC-4337 mempool does. The `TransactionType4` struct has minor differences compared to the `UserOperation` but everything else remains unchanged. Any work done on the ERC-4337 mempool will carry over to the Native Account Abstraction mempool.

The ERC-4337 specifies that bundlers have the option to maintain multiple mempools with different alterations to the ERC-xxxx rules in order to support trusted code execution in the validation phase.

This option remains unchanged with the Native AA protocol.

### Bundlers

Bundlers as defined by ERC-4337 must maintain a special relationship with a block builder for including the `handleOps` bundle transactions, and bundle transactions cannot be broadcast via public mempool.

Block builders are delegating the bundling not out of necessity but largely due to a "separation of concerns".

This remains largely the case with the Native Account Abstraction. Bundlers are expected to have access to a privileged API of block builders, similar in nature to the [`eth_sendTransactionConditional`](https://forum.arbitrum.foundation/t/aip-2-activate-support-for-account-abstraction-endpoint-on-one-and-nova/14790) that has been proposed for ERC-4337.

Bundlers are expected to provide the block builder (or L2 sequencer) an unsigned array of `TransactionType4` objects that are all valid if included in the specified order, and the block builder should compensate the bundler if it makes a profit on those transactions. The model is similar to how MEV searchers interact with Builders.