RIP-7560: Native Account Abstraction at the Consensus Layer—The Ultimate Form of Account Abstraction?
TechFlow Selected TechFlow Selected
RIP-7560: Native Account Abstraction at the Consensus Layer—The Ultimate Form of Account Abstraction?
ERC-4377: Account abstraction without changing the consensus layer; RIP-7560: Standardized native account abstraction implemented at the consensus layer.
Navigating Web3 tides with focused insightsWritten by: 0XNATALIE
ERC-4337 is likely no stranger to most readers. First proposed by Vitalik in September 2021 and deployed on the Ethereum mainnet in March 2023, it has since seen improved versions adopted into the core execution layers of multiple L2s. However, widespread wallet adoption of ERC-4337 has yet to materialize. To promote standardized account abstraction and network effects, Ethereum protocol contributor Alexander Forshtat introduced the RIP-7560 proposal—with Vitalik as the lead author—marking the first Rollup Improvement Proposal (RIP) for Ethereum, aiming to establish a native account abstraction standard adoptable across all L1s and L2s.
RIP stands for Rollup Improvement Proposal. The initiative began with the first RollCall on October 18, designed to help L2s build optional specifications and standards that allow them to extend the EVM and related tooling while minimizing conflicts with the L1 EVM.
RIP-7560: Introducing Native Account Abstraction
To achieve better standardization, RIP-7560 introduces native account abstraction through consensus-layer protocol changes, merging EIP-2938 and ERC-4337 into one comprehensive account abstraction proposal. Before diving deeper into RIP-7560, consider reviewing our earlier article on the concept of "account abstraction": "EIP-7377: The Accelerator for Full Account Abstraction (AA)?"
Compatibility and Coexistence with ERC-4337
RIP-7560’s native account abstraction is compatible with ERC-4337, and both approaches are expected to coexist long-term. RIP-7560 provides a migration path for projects already using ERC-4337. However, current ERC-4337 implementations will require modifications to support native account abstraction in the future:
-
UserOperation becomes TransactionType4: The original UserOperation structure and name were designed to avoid confusion with actual Ethereum transactions. Since native account abstraction turns UserOperation into a real Ethereum transaction, it is renamed TransactionType4. While the name changes, its on-chain behavior remains similar to UserOperation.
-
Smart Contract Account Upgrade: Smart contract accounts must upgrade their implementation to support the native account abstraction protocol. Specific changes include setting the EntryPoint address as a system-wide constant to simplify operations, renaming the validateUserOp function and modifying its parameters, and eliminating the need for accounts to maintain deposits in the EntryPoint contract for gas payment—instead, gas will be deducted directly from their balance.
-
Paymaster Contract Upgrade: Paymaster contracts will need to be upgraded or redeployed. For ERC-20 tokens and other assets—including state—manual migration of approvals will be required. The validatePaymasterUserOp function must be renamed and accept different parameters. Additionally, Paymasters no longer need to maintain gas deposits in the EntryPoint contract; instead, they pay gas directly from their own balance.
-
Account Factories: Existing factory contracts can still be used. Account addresses created via either ERC-4337 or native account abstraction workflows will remain consistent.
-
Bundlers: Bundlers in native account abstraction still need to align incentives with block builders to ensure inclusion of bundled transactions. Bundlers retain privileged API access to block builders, enabling direct communication and negotiation before transaction packing—including handling nonce collisions (e.g., when a user sends two UserOperations with the same nonce to two different bundlers under EIP-4337, causing one transaction to fail).
Community Discussion on RIP-7560
Community discussions around RIP-7560 reflect diverse perspectives. John Rising, co-founder of Stackup, believes that addressing certain issues from ERC-4337 might be beneficial. He highlights key problems in the current ERC-4337 implementation—particularly that post-EIP-4337 activity has largely centralized among three cloud service providers or companies. This suggests the account abstraction infrastructure is overly centralized relative to the broader ecosystem, with low account retention rates and limited profitability for bundler operators.
Jarrod Watts, an engineer at Polygon, also notes that mainstream wallets like MetaMask have not made significant progress in implementing EIP-4337-style account abstraction, suggesting application-layer adoption of new features remains suboptimal. Thus, RIP-7560 could serve as a breakthrough.
Peter Pan, co-founder of Particle Network, is highly optimistic about the proposal, praising its compatibility with 4337, gas optimizations, and resolution of private bundler issues—all critical for wider account abstraction adoption.
Foobar, founder of Delegate, argues that 4337 failed to gain traction due to excessive overhead. He sees 7560 as moving toward formally cementing account abstraction at the protocol level, suggesting the best approach is to eliminate redundant components rather than striving for backward compatibility with 4337—especially given that 4337 hasn’t existed for very long.
Despite differing opinions, RIP-7560 offers a new reference model for standardizing account abstraction. As the Ethereum community continues deepening its discussion, the evolution of the account abstraction framework will move forward. We believe that regardless of the path taken, account abstraction will ultimately achieve widespread adoption.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@ChainFeedsxyz
