RIP-7560 is a Rollup Improvement Proposal that moves account abstraction into the L2 protocol layer, eliminating the bundler infrastructure that ERC-4337 requires. Co-authored by Vitalik Buterin and Yoav Weiss, the proposal introduces a new AA_TX_TYPE transaction format that L2 nodes process natively, making smart contract wallets first-class participants in the transaction pipeline rather than wrappers around it.
​

The spec was created on September 1, 2023 and remains in draft status as of 2026. It builds directly on ERC-4337's design vocabulary (paymasters, UserOperations, EntryPoint) while replacing the off-protocol bundler layer with protocol-enforced validation frames. Existing ERC-4337 account contracts are compatible with RIP-7560 without redeployment. Understanding RIP-7560 starts with understanding why app-layer account abstraction has limits on L2s.
​

RIP-7560 is a draft protocol specification that implements account abstraction natively at the L2 transaction layer. Rather than relying on external bundler nodes to relay UserOperations, RIP-7560 defines a new transaction type that L2 nodes validate and execute directly, giving smart contract wallets the same protocol standing as standard EOA transactions.
​

The "RIP" prefix stands for Rollup Improvement Proposal, a category distinct from Ethereum mainnet EIPs. RIPs target L2 chains and rollups specifically, meaning adoption requires each L2 team to implement the changes in their node software. The full RIP-7560 specification on GitHub describes the new transaction type as AA_TX_TYPE, an EIP-2718 compatible envelope that contains separate gas limits for validation, execution, and post-operation phases.
​

The proposal requires EIP-7702 as a prerequisite. It also references ERC-7562 for the storage access rules that prevent bundler-style DoS attacks at the protocol level. The authors are Vitalik Buterin, Yoav Weiss, Alex Forshtat, Dror Tirosh, and Shahaf Nacson, several of whom also co-authored the original ERC-4337 spec.
​

One notable structural change: AA_TX_TYPE sets the base gas cost at 15,000 rather than the standard 21,000. The 21,000 baseline for EOA transactions includes the cost of ECDSA signature verification, which smart contract wallets perform in their own validation logic. Dropping that cost from the base reflects that protocol-level AA no longer needs the EOA verification step built into every transaction.
​

ERC-4337 routes smart wallet transactions through an off-chain bundler mempool and an EntryPoint contract, adding roughly 42,000 gas overhead per UserOperation versus a standard transaction's 21,000 gas base. That gap compounds on L2s, and the bundler dependency reduces censorship resistance and limits which nodes can participate in AA transaction ordering.
​

The overhead figure comes from the RIP-7560 motivation section, which the spec's authors used to justify the protocol-level redesign. UserOperations require separate off-chain simulation, off-chain mempool admission, and an on-chain bundling call, each of which adds gas that a native transaction type would not need.
​

The bundler model also creates structural fragmentation. UserOperations flow through a separate alternative mempool with non-standard RPC methods, which means only a fraction of nodes participate. That smaller participating set reduces censorship resistance compared to what a protocol-level solution would provide, since mainnet-grade protections like crLists target the standard transaction pipeline, not the bundler mempool.
​

A subtler problem involves tx.origin. In ERC-4337 flows, tx.origin returns the bundler's EOA address rather than the user's smart account. Any contract that relies on tx.origin for access control or identity fails in an ERC-4337 context. Native AA at the protocol level eliminates this issue because the chain directly identifies the smart account as the transaction origin.
​

Starknet and zkSync both implemented native AA systems before ERC-4337 reached production maturity, specifically to avoid these overheads. Their implementations share conceptual DNA with RIP-7560 but predate the spec. For EVM-compatible L2s looking to adopt native AA while staying aligned with the broader ERC-4337 ecosystem, RIP-7560 provides a standardized path that preserves contract compatibility.
​

RIP-7560 embeds a multi-frame validation sequence inside the L2 node. When a user submits an AA_TX_TYPE transaction, the node runs an optional deployment frame, a required sender validation frame, and an optional paymaster validation frame in sequence. All frames must succeed before execution begins. No bundler coordinates this process.
​

The entry point for these callbacks is address(7560), a protocol-reserved address. Smart accounts implementing RIP-7560 receive calls to acceptAccount() and sigFailAccount() from this address. Paymasters similarly receive acceptPaymaster() and sigFailPaymaster(). These explicit callback names make the validation intent clear and prevent accidental interaction with non-AA contracts.
​

The separation of validation from execution is not new to RIP-7560. ERC-4337 enforces the same separation through the EntryPoint contract's two-phase loop. What changes in RIP-7560 is where that separation lives: inside the L2 node's transaction processing code rather than inside an application-layer contract. This means validation failures can be caught at the mempool admission layer, the same way nonce and balance checks work for EOA transactions today.
​

Paymasters under RIP-7560 still follow the same conceptual model as ERC-4337 paymasters: a third-party contract can cover gas fees for the sender, enabling sponsored transactions without the user holding any native token. The post-operation hook, postPaymasterTransaction(), gives paymasters the final execution status and actual gas consumed so they can implement accurate accounting or conditional refunds. What's removed is the requirement to route through an off-chain bundler to reach the paymaster at all.
​

AA_TX_TYPE also carries an authorization list compatible with EIP-7702, which means EOAs that have delegated code under EIP-7702 can participate in the RIP-7560 flow without abandoning their existing delegation. This compatibility is deliberate: the authors designed RIP-7560 to work alongside the incremental path that EIP-7702 provides for smart EOA wallets, not to supersede it.
​

RIP-7560, ERC-4337, and EIP-7702 each address smart wallet functionality from a different layer of the stack and with different migration costs. The table below summarizes the six most operationally relevant dimensions for developers and L2 teams evaluating which path to take.
​

The key distinction between RIP-7560 and EIP-7702 is scope. EIP-7702 solves a specific problem: giving existing EOAs smart wallet capabilities without moving to a new address. It adds one new transaction type and requires no bundler or alternative mempool. RIP-7560 solves a different problem: making the entire AA transaction pipeline a native concern of the L2 protocol, which benefits all smart accounts regardless of how they were created. The two are complementary rather than competing, which is why RIP-7560's AA_TX_TYPE carries EIP-7702's authorization list format.
​

ERC-4337 remains the practical production standard. Every major EVM L2 supports it today. RIP-7560's bundler-free design would reduce the per-UserOperation gas overhead currently documented at roughly 42,000 gas above a standard transaction, but reaching that reduction requires L2 teams to implement protocol changes. Until they do, ERC-4337 is the path to smart contract wallet functionality onchain.
​

RIP-7560 enables gas sponsorship, session keys, and unified mempool processing for smart accounts as protocol primitives rather than application-layer workarounds. Because AA_TX_TYPE is a first-class transaction type, L2 nodes apply the same admission and ordering logic to smart account transactions that they currently apply only to EOA transactions, closing a long-standing asymmetry in how the two account types are treated.
​

Native paymasters under RIP-7560 remove the bundler from the gas sponsorship path entirely. An application that wants to cover gas fees for its users currently depends on bundler availability and bundler willingness to include specific UserOperations. Under RIP-7560, the paymaster validation frame runs inside the L2 node: if the paymaster contract approves the transaction, the node accepts it the same way it accepts any other valid transaction. No bundler coordination required.
​

Session keys become substantially simpler in a protocol-native AA context. A session key is a scoped signing key that authorizes a specific set of actions for a fixed time window, which wallets like Safe and Kernel implement today via ERC-4337 modules. Under RIP-7560, the session key's authorization logic runs in the sender validation frame, evaluated at the protocol level with the same DoS protections that apply to all AA_TX_TYPE transactions. There is no separate bundler that needs to understand or simulate the session key module before relaying.
​

The unified mempool is probably the longest-term structural benefit. ERC-4337 currently requires a parallel alternative mempool with non-standard RPC endpoints. Block builders that want to include UserOperations must run bundler software in addition to standard node software, which limits participation. RIP-7560 folds AA transactions into the standard mempool, meaning any node that processes blocks also processes smart account transactions. This matters for applications in custody or payment flows, where non-custodial wallets need predictable transaction inclusion without depending on bundler liveness.
​

Existing ERC-4337 account contracts are compatible with RIP-7560 without redeployment. The RIP-7560 specification explicitly preserves ERC-4337 design patterns, including the IAccount interface and paymaster ABI, so wallets built to the ERC-4337 standard can participate in the RIP-7560 flow on any L2 that implements the proposal. Bundlers can continue operating alongside RIP-7560 indefinitely on mixed networks.
​

The migration path is additive. An L2 that ships RIP-7560 support adds AA_TX_TYPE handling to its node software while keeping ERC-4337 compatibility intact. Users with existing smart accounts (Safe, Kernel, Biconomy, and others built to ERC-4337) gain the option to route through the native AA path for lower gas overhead without abandoning their current account addresses or losing accumulated nonce history.
​

The compatibility extends to paymasters. An ERC-4337 paymaster contract needs minimal changes to serve as a RIP-7560 paymaster: the core validation logic and post-operation hooks map directly to RIP-7560's acceptPaymaster() and postPaymasterTransaction() callbacks. Wallet teams that have already built paymaster infrastructure for ERC-4337 can reuse most of that code when L2s ship RIP-7560 support.
​

One area requiring attention is storage access rules. RIP-7560 references ERC-7562 for anti-DoS storage restrictions during the validation phase. ERC-7562 defines which storage slots a validating contract is allowed to read during validation to prevent unbounded state access that could be exploited to stall block production. ERC-4337 uses compatible rules enforced by the bundler; under RIP-7560, these rules move into the protocol, so account contracts need to comply with ERC-7562 at the contract level rather than relying on off-chain bundler enforcement.
​

For teams building or auditing smart wallets that use permission delegation standards like ERC-7715, RIP-7560 is a relevant protocol horizon. ERC-7715 defines how wallets express granular permissions for delegated signers. Under RIP-7560, those permission checks run in the sender validation frame at the protocol level, which tightens the security model around permission delegation compared to the current ERC-4337 flow where bundlers must simulate and enforce those checks off-chain.
​

RIP-7560 is a draft as of 2026. The fork block is listed as TBD, and no EVM-compatible L2 has shipped a production implementation. Starknet and zkSync operate native AA systems with similar design principles, but those predate RIP-7560 and are independent implementations rather than conformant deployments of the spec.
​

The proposal's status as a Rollup Improvement Proposal rather than a core EIP gives individual L2 teams the authority to adopt it independently. No mainnet hard fork is required. This lowers the coordination cost compared to mainnet EIPs, but it also means adoption will likely be uneven across the L2 landscape. An L2 that ships RIP-7560 first gains a gas efficiency advantage for smart account transactions and a simpler infrastructure stack for application developers building wallet-integrated products.
​

RIP-7560's requirement for EIP-7702 as a prerequisite links its adoption timeline to Pectra, the Ethereum mainnet upgrade that shipped EIP-7702. L2s that have already incorporated Pectra changes into their node software are closer to the prerequisite baseline for RIP-7560. The Ethereum Magicians discussion thread from late 2023 shows active engagement from L2 developers, with several noting the design's alignment with their existing native AA plans.
​

For developers building wallet infrastructure today, RIP-7560's draft status means ERC-4337 remains the reliable production target. Building to the ERC-4337 IAccount and paymaster interfaces now ensures compatibility with RIP-7560's migration path when L2 implementations ship, since the specs share the same core abstractions.
​

RIP-7560 does not replace ERC-4337. The two can coexist on the same L2, and existing ERC-4337 account contracts are compatible with the RIP-7560 flow without redeployment. RIP-7560 offers a protocol-native alternative that removes bundler overhead, but ERC-4337 remains the live production standard on all major EVM L2s as of 2026.
​

No EVM-compatible L2 has shipped a production implementation of RIP-7560 as of 2026. Starknet and zkSync run native AA systems with similar design principles, but those are independent implementations that predate the RIP-7560 spec. Adoption by EVM rollups requires a separate protocol upgrade by each team.
​

AA_TX_TYPE is the new EIP-2718 compatible transaction envelope that RIP-7560 introduces. It carries separate gas limits for the validation phase, execution phase, and optional post-operation phase, plus sender, deployer, and paymaster addresses. Its base gas cost is 15,000, lower than the 21,000 baseline for standard EOA transactions.
​

Yes. ERC-4337 paymaster logic maps directly to RIP-7560's acceptPaymaster() and postPaymasterTransaction() callbacks with minimal changes. The core validation and post-operation logic is reusable. Teams that have already deployed ERC-4337 paymasters will not need to rebuild from scratch when L2s implement RIP-7560.
​

RIP-7560's AA_TX_TYPE carries an authorization list in the same format EIP-7702 defines for EOA code delegation. This lets EOAs that have already delegated code under EIP-7702 participate in the RIP-7560 flow without conflicting with their existing delegation. The dependency ensures the two standards compose cleanly across the same L2.
​

Sources and methodology. Specification details sourced from the RIP-7560 draft on GitHub (created September 1, 2023). ERC-4337 gas overhead figure sourced from the RIP-7560 motivation section. EIP-7702 status sourced from eips.ethereum.org. L2 adoption context from the Ethereum Magicians discussion thread, November 2023. Figures reflect draft specification state as of Q2 2026.
​