What is Native Account Abstraction? RIP-7560 Explained

Ethereum continues to be the home for the majority of on-chain activity despite the network facing ongoing challenges with scalability and efficiency. 

At the forefront of solving this are rollups, as a Layer 2 solution, offering a way to handle transactions off the main Ethereum chain.

However, the status quo of these solutions needs to be more compelling for mass adoption in terms of attracting institutional interest or the masses. On the frontend aspect, account abstraction (ERC-4337) strives to improve the user and developer experience.

Now, enter a new (rollup improvement proposal) RIP-7560 that aims to integrate account abstraction directly into Ethereum rollups as a native feature. Unlike the popular ERC-4337 standard — which implements account abstraction as a layer on top of Ethereum, using smart contract wallets to simulate advanced features. 

So what is RIP-7560? How does it compare to ERC-4337, and what does it mean to have "native" account abstraction for Ethereum?

In this blog, we'll explain everything you need to know about RIP-7560 and native account abstraction.

What is native account abstraction (RIP-7560)?

RIP-7560 is a proposal for native account abstraction on Ethereum, intended to be an enshrinement of ERC-4337 standard for rollups. 

Native AA makes it possible for externally owned accounts (EOAs) to initiate account abstraction transactions. This serves as a better onboarding tool for existing user accounts and could lead to broader adoption of smart contract accounts. The native AA approach serves as a transitional step, unlike ERC-4337 where the standard required new smart contract accounts.

By supercharging standard EOAs, RIP-7650 can enable features like social recovery, multiple signatories, and the ability to change account signers.

In essence, RIP-7560, while being a native Ethereum proposal, is particularly designed to enhance the functionality of rollups. By optimizing AA for rollups, RIP-7560 is essentially future-proofing Ethereum, ensuring that it remains more accessible and appealing to a wider range of users and developers.

How RIP-7560 — native account abstraction works 

Here’s a breakdown of the key components and functionalities of RIP 7560:

New transaction type (AA_TX_TYPE) 

RIP-7560 introduces the EIP-2718 transaction type — designed for account abstraction. These AA transactions have a distinct payload structure including parameters like chainId, sender, nonce, and gas limits. 

AA transactions also have a base gas cost set to AA_BASE_GAS_COST. There is no standard ECDSA or signature processes for these transactions.

For developers, RIP-7560 and the new transaction type give the ability to design more complex transaction rules directly within the Ethereum protocol, more importantly, while bypassing the need for external contracts. 

Transaction counter header

RIP-7560 proposes an optional "counter" transaction subtype to facilitate the division of AA transactions into batches for separate validation and execution. 

By efficient processing of grouped transactions, RIP-7560 significantly improves scalability and throughput. Further, this is a boon for developers as they can optimize their dapps for performance. 

Non-sequential nonce support 

RIP-7560 introduces a 2-dimensional nonce system that allows for unique transaction identifiers without the constraint of sequential numbering. 

The shift to a 2-dimensional nonce system offers Ethereum developers greater flexibility in transaction management, especially in complex dapp environments. 

Builder fee inclusion

RIP-7560 includes a provision for a builderFee to remunerate the block builders. This fee acts as a compensatory "tip" for the block builder, covering off-chain work and potential Layer 1 gas costs.

It incentivizes the efficient construction of blocks, aligning the interests of developers and block builders. Since this fee is tied to their performance, block builders are more likely to construct and propose blocks more efficiently. This helps developers provide an efficient and responsive Ethereum to all.

Penalty for unused gas 

The proposal introduces a penalty for AA transactions that reserve but do not utilize significant amounts of gas. This calls for block builder efficiency — which will then be rewarded with builderFee.

Overestimation of gas leads to unnecessary reservation of network capacity. By discouraging this practice, the penalty for unused gas helps in reducing network congestion. Less congestion means faster transaction processing times, which improves user experience on Ethereum.

Multiple execution frames 

RIP-7560 supports multiple execution frames within a single transaction. This capability allows for more complex transaction processes to happen. 

Transactions that require a multi-step process, such as those involving various stages of validation, computation, and finalization.

Developers gain flexibility in how they structure transactions. They can bundle various operations that might be interdependent or need to be executed in a specific sequence. 

They no longer have to build multiple separate transactions for complex operations. Developers and users alike can now save on transaction fees. It also reduces the overall load on the network, contributing to the greater efficiency of Ethereum. 

Transaction validation 

RIP-7560 extends the execution layer transaction validation process and modifies RPC methods to accommodate the new AA_TX_TYPE transactions.

This ensures seamless integration into the existing Ethereum infrastructure and projects that have already built ERC-4337 components.

Now that we know about the key components behind the working process of RIP-7560, let us discuss how it differs from ERC-4337 — the account abstraction standard.

Technical differences between ERC-4337 and RIP-7560

At the current state of the proposal, here are five key differences between the ERC-4337 standard for account abstraction and RIP-7560’s proposal for native AA.

1. UserOperation becomes TransactionType4 

The struct and its name are changed to reflect its new role in native AA, where UserOperations are treated as individual transactions.

2. Smart contract account upgrades 

Smart contract accounts that follow the ERC-4337 standard need to implement several changes to support native AA:

• The EntryPoint address is set to a system-wide constant value.
• The validateUserOp function is renamed and modified, and it must return a specific "magic value" to accept a transaction.
• Accounts will be directly charged for gas, eliminating the need for a deposit in the EntryPoint contract.

3. Paymaster contracts and services 

Paymaster contracts will likely require upgrades or redeployment, including:

• Renaming and modifying the validatePaymasterUserOp function.
• Removing the requirement for Paymaster contracts to maintain a deposit in the EntryPoint contract for gas payments.

4. Aggregators 

Signature aggregation is not part of the initial native AA EIP. This feature is expected to be introduced later as a standalone, optional EIP. The Aggregator flow that is currently in place with ERC-4337 will need some changes and modifications.

5. Bundlers

Although bundlers focus on grouping transactions even in native AA while interacting with block builders or L2 sequencers, there is a change. The introduction of TransactionType4 objects requires Bundlers to provide an unsigned array to block builders for inclusion in the blockchain. 

Interestingly, bundlers under native AA will also receive a portion of the builderFee.

What's next for ERC-4337 and account abstraction?

The status quo suggests that ERC-4337 is set to evolve alongside RIP-7560 with a focus on maintaining compatibility and providing a seamless transition path. So, projects using ERC-4337 will need to adapt to the changes brought by native AA.

Compatibility and co-existence

The primary focus of RIP-7560 is to maintain cross-compatibility with ERC-4337 to provide a unified account abstraction ecosystem. Networks are expected to implement native AA at varying times, leading to the coexistence of both ERC-4337 and RIP-7560. 

This coexistence is essential for networks that have already embedded a version of ERC-4337, such as Starknet and zkSync. The goal is to standardize account abstraction across Layer-1 and Layer-2 networks, preventing fragmentation, especially in the wallet ecosystem.

Migration and adaptation

For projects currently utilizing ERC-4337, a clear migration path to native AA will be outlined, allowing for a gradual transition to adopt the new standard.

However, this shift necessitates some modifications like transforming UserOperation into TransactionType4 to adapting paymaster contracts for existing ERC-4337 projects.

Is RIP-7560 the game changer for on-chain interactions?

At the outset, the embedding of account abstraction natively into Ethereum's rollups is a move in the right direction. It has the potential to enhance the scalability and efficiency of the network while also improving the user and developer experience. 

However, the transition at a consensus and protocol level is a huge logistical challenge. This is where the coexistence and compatibility with ERC-4337 ensure a smooth transition, allowing projects to adapt and migrate at their own pace. 

As we look forward to how RIP-7560 comes to reality, there’s no doubting the potential of rollups and AA in making Ethereum a simpler, more intuitive platform for users and builders alike.

We hope this blog post has helped you better understand what native account abstraction is, what RIP-7560 entails for web3, and a brief roadmap into how it will come to fruition.

If you have any questions, join 40,000+ other builders in our Discord community — or reach out to the team directly for more info on how to get started with native account abstraction.

And if you want to start building web3 apps using account abstraction, get started with thirdweb’s web3 tools & SDKs — they’re free!