Gelato’s Guide to Account Abstraction: from ERC4337 to EIP7702

Overview (TL;DR)

This guide demystifies account abstraction, from ERC-4337 to EIP-7702, covering these major sections :

Introduction to Account Abstraction

• What are the limitations of traditional EOAs?
• How does account abstraction improve user experience?

Understanding ERC-4337

• What is a UserOperation and how does it work?
• What is a Bundler and what role does it play?
• What is an EntryPoint contract?
• What is a Paymaster and how does it handle transaction fees?

Current State of ERC-4337

• What adoption metrics exist for ERC-4337?
• What are the implementation challenges and gas inefficiencies?
• How does Gelato's implementation differ from standard approaches?

EIP-7702: An Update to Account Abstraction

• Is EIP-7702 a replacement for ERC-4337, or are they compatible?
• How does EIP-7702 differ from ERC-4337?
• What key innovations does EIP-7702 introduce?
• How does EIP-7702 allow EOAs to execute contract code?

Implementation Considerations

• How are wallets and infrastructure adapting to these standards?
• What are the UI/UX implications of account abstraction?
• What storage architecture challenges exist with EIP-7702?

Practical Applications and Demonstrations

• How does Gelato implement EIP-7702 with ZeroDev?
• How can Passkeys (WebAuthn) be integrated with EIP-7702?
• Deploying 7702 enabled rollups with Gelato RaaS
• What resources are available for developers?

Introduction to Account Abstraction

Traditionally, Ethereum has relied on two types of accounts: externally owned accounts (EOAs), which are controlled by private keys, and contract accounts, which are governed by smart contract code. EOAs face fundamental issues:

1. Security risks - There is no recovery option if key got lost/stolen
2. Limited functionality - EOAs could only do basic transactions, couldn’t schedule, and required extra approvals
3. Accessibility barriers - EOAs need Ether to pay for transactions fees (gas), forcing users to own Ether even if they’d rather use other tokens.

ERC-4337 emerged as an implementation of contract accounts, serving as a pivotal standard for implementing account abstraction (AA) on Ethereum without consensus changes. By shifting account logic to smart contracts, AA enhances user experience, security, and functionality in blockchain interactions. With ERC-4337, AA introduces “smart wallets” that replicate EOA functionality while adding programmable features. In contrast, EIP-7702, proposed for the upcoming Pectra hardfork, enables EOAs to use smart contract account features directly from their existing addresses. This allows EOAs to execute code, combining the benefits of both account types without creating a new address or transferring assets.

Understanding ERC-4337

ERC-4337 introduced "UserOperations"—pseudo-transactions that encapsulate user intents—which are collected and executed by a decentralized network of bundlers. These UserOperations are processed in a separate mempool and bundled into a single transaction, allowing smart contract logic to dictate account behavior. By avoiding protocol-level modifications, ERC-4337 makes AA accessible while preserving Ethereum's security and decentralization.

What is a UserOperation

A UserOperation is a specialized data structure serving as the transaction format for ERC-4337 account abstraction. It contains fields like sender, nonce, call data, gas parameters, and signature data. Unlike standard transactions, UserOperations flow through an alternate mempool and enable programmable accounts to execute transactions without requiring ETH directly from users.

Gelato offers two endpoints that relate to user operations: one is eth_sendUserOperation, which is used to send user operations, and the other is eth_getUserOperationByHash, which retrieves user operations by their hash.

What is a Bundler

A bundler is a node that bundles multiple UserOperations into a single transaction. Gelato's Bundler is a network node that collects UserOperations from the alternate mempool and submits them to the EntryPoint contract as standard transactions. It uses EOAs to cover gas costs upfront, later reclaiming them through 1Balance. Gelato's implementation offers instant inclusion without waiting for other operations, MEV protection via Flashbots, and removes restrictions on gas limits and opcodes for smart accounts.

What is an EntryPoint

The EntryPoint is a singleton contract that serves as the central verification and execution hub for all UserOperations. It applies standardized validation rules across the ecosystem while allowing wallet-specific logic through the validateUserOp interface. Gelato's approach uniquely sets maxFeePerGas=0 to eliminate the need for EntryPoint deposits, relying instead on post-execution settlement for more accurate fee handling.

What is a Paymaster

A paymaster is a service that covers transaction fees on behalf of the user. Gelato's Paymaster, implemented through 1Balance, covers transaction fees on behalf of users across all supported networks. Unlike other implementations that rely on on-chain fee transfers, Gelato settles fees post-execution, ensuring users are charged the exact amount of gas consumed rather than estimates. This approach reduces on-chain overhead, prevents overcharging, and enables cross-chain operations with a single deposit.

Safe released a benchmark comparing gas usage across bundler providers, with Gelato consistently outperforming competitors. Gelato's ERC-4337 compatible bundler demonstrates significant gas savings in key operations compared to competitors’ implementations.

The original intent of the ERC-4337 authors was to create a decentralized and open system for account abstraction on Ethereum, featuring a decentralized mempool, an open bundler ecosystem, and more. Gelato identified fundamental flaws in ERC-4337's implementation, particularly its inefficient gas handling. The EntryPoint contract enforces arbitrary gas constraints that force bundlers to overestimate gas requirements, and its batch-processing design adds unnecessary complexity when most transactions are processed individually.

ERC4337: Promises vs. Practical Limitations

ERC-4337 has achieved decent adoption with 25.5 million smart accounts executing nearly 132 million UserOps across multiple chains. While initially dominated by Polygon, Base has emerged as a leading network for account abstraction since mid-2024. The total gas covered by paymasters ($5.7M) demonstrates growing transaction sponsorship infrastructure.

Current Hurdles to ERC4337 Adoption

Despite its potential, account abstraction faces four key challenges: (1) higher gas costs due to smart contract deployment and transaction overhead, (2) incompatibility with existing applications that assume EOA wallets, (3) complex multichain experience since state must be synchronized across networks, and (4) unreliable infrastructure that hasn't reached the robustness of traditional Ethereum infrastructure.

Adoption patterns reveal these key challenges with activity peaking at around July-August 2024 but has declined since October. Integration complexity and a fragmented landscape where different AA solutions use different smart contracts, bundlers, and paymasters, making them difficult for developers to implement.

The fragmentation across chains (Base, Polygon, Arbitrum, etc.) illustrates the difficulty in creating seamless cross-chain experiences. Additionally, the irregular bundler revenue pattern and the division between users who perform either just 1 UserOp or more than 10 UserOps point to economic sustainability challenges.

Also, the $5.7M in gas fees covered by paymasters underscores a major push to tackle gas cost barriers, a persistent adoption challenge. By subsidizing fees, paymasters make ERC-4337 more user-friendly, yet this amount—while substantial—shows how costs remain to be a hurdle, especially on pricier networks like Ethereum. UserOps are approximately twice as expensive as regular transactions on L2 networks and practically unusable on Ethereum's mainnet due to prohibitive gas fees. This cost inefficiency means applications sponsoring transactions for their users are losing thousands or even tens of thousands of dollars monthly to overhead expenses.

As Luis Schliesske, founder of Gelato, stated: "If these blockchain networks and rollups were significantly cheaper, then at some point, it wouldn't matter as much whether account abstraction is slightly more expensive or not." (He continued with additional remarks.) "And the problem is that we are so far from that reality today that even small differences in gas consumption are highly noticeable."

Gelato recognized early on that high gas fees hinder crypto adoption, as covering users' costs is often too expensive for developers. To solve this, Gelato launched Rollup-as-a-Service, leveraging emerging rollup technologies like OP, Arbitrum Orbit and ABC stacks and data availability layers like Celestia or Anytrust. These modular solutions enable developers to build cost-efficient blockchains with Ethereum-like security. By significantly reducing gas fees, Gelato makes it feasible for developers to cover costs, removing a major friction point in user experience.

Size of Account Abstraction Market

The account abstraction market is tiny. Let’s take a look at Base and Arbitrum. From the start of 2025, Base has been consistently processing between 7-8 million daily transactions. During this same period, daily successful UserOps (ERC-4337) on Base have stabilized at approximately 120,000-150,000 daily operations, following a significant decline from their mid-2024 peak of nearly 800,000. UserOps currently represent only about 1.5–2% of Base's total transaction volume.

Seeing Arbitrum, the total daily transactions chart shows a much larger scale of activity compared with UserOps, regularly exceeding 2 million transactions per day from the start of 2025. Arbitrum's daily successful UserOps actually experienced a sudden and dramatic plummet in early 2025 and has entered a state of stagnation. The UserOps volume has substantially decreased, dropping to few thousands of daily operations by March 2025. Despite earlier enthusiasm, AA has faced adoption challenges in the Arbitrum ecosystem.

Overall, data indicates that account abstraction is still a small subset of overall activity on all chains, its steady presence highlights its growing role in enabling functionalities such as gasless transactions and smart contract wallets. However, when comparing usage of AA on Base and Arbitrum, the difference subtly demonstrates the impact of leadership commitment on driving account abstraction standardization forward.

For account abstraction to succeed, the underlying infrastructure must reduce complexity and costs while improving user experience. AA can be integrated with just 1-click directly from the Gelato Marketplace on the RaaS App—no negotiations, no contracts, instantly available on your rollup.

Account Abstraction Smart Contract Protocol Implementation Issues

Gas estimation presents a significant challenge in ERC-4337 implementations. EntryPoint v6 made accurate gas estimation particularly difficult—a known issue that was later addressed in v7. When developers hardcode gas values rather than implementing proper estimation, transactions revert after consuming gas, forcing users to pay for failed operations.

The EntryPoint contract enforces verificationGasLimit and callGasLimit on-chain by checking gasleft() at specific execution points. These checks require more gas to be available than what's actually needed, creating inherent inefficiency. The overall implementation complexity of ERC-4337 introduces additional gas overhead, making transactions more expensive.

Gelato solves these pain points by leveraging the 1Balance system, which eliminates the need for on-chain EntryPoint deposits and paymasters by settling transaction fees post-execution across all supported networks. This approach ensures developers can offer users gasless transactions with exact fee calculations (not overestimations), instant inclusion without waiting for batching, and freedom from restrictive gas limits or blacklisted opcodes—all while maintaining full ERC-4337 compatibility.

Though not an issue with ERC-4337, the EVM’s 63/64th forwarding rule exacerbates this in deep call stacks, as each nested call requires more gas than actually consumed. Gelato addresses this through binary search methods for gas estimation, similar to other bundler providers, ensuring transactions succeed even with complex nested calls.

EIP-7702: An Update to Account Abstraction

EIP-7702 allows EOAs to execute contract code directly from their address while maintaining their ability to sign transactions with private keys. This allows EOAs to execute smart contract logic directly from their own address while maintaining their ability to sign transactions with private keys.

This proposal builds on concepts similar to those in EIP-3074, which allows EOAs to delegate their signing authority to smart contracts through new opcodes like AUTH and AUTHCALL. With EIP-3074, an EOA can authorize a contract to execute transactions on its behalf, effectively blending the simplicity of EOAs with the programmability of contracts. EIP-7702 takes this a step further by focusing on contract wallets—smart contracts designed to manage assets with advanced features like multi-sig security or social recovery—and enabling them to operate as EOAs under specific conditions, enhancing their compatibility and flexibility within the Ethereum ecosystem.

Implementation Changes with EIP-7702

Is EIP-7702 a replacement for ERC-4337, or are they compatible?

EIP-7702 is not a replacement for ERC-4337 but a complementary enhancement that allows EOAs to be upgraded to smart accounts while maintaining their original address. The upgraded account can then utilize ERC-4337 infrastructure (bundlers, paymasters) for transaction relaying.

For instance, EIP-4337 introduced a separate smart contract proxy for each user's EOA, creating a distinction between the user's EOA address and their on-chain representation. This required maintaining a registry to map EOAs to their corresponding smart contract proxies. With EIP-7702, smart wallet code (like ZeroDev's) can be initialized directly at the EOA address, allowing ERC-4337's entry point to call the EOA instead of a separate proxy. This enables existing bundlers and paymasters to work seamlessly with upgraded EOAs, while wallets like MetaMask can implement standardized batching and gas sponsorship within the account itself.

Their Difference

ERC-4337 and EIP-7702 however do differ. EIP-7702 proposes a more integrated approach by allowing EOAs to become smart accounts directly at the protocol level through new EVM opcodes, eliminating the need for separate proxy contracts. The key advantage of EIP-7702 is that it simplifies the user experience and improves interoperability. With EIP-7702, a user's account has the same address for both their EOA and smart contract functionality, making it easier for user interfaces, wallets, and indexers to track and manage on-chain data.

Smart Contract Layer

EIP-7702 introduces a new transaction type called SET_TX_CODE_TYPE. Now, when the user signs a "set code transaction," they're essentially authorizing the association of contract code with their account address. The wallet then sends this transaction with initialization data to a relayer, which is a third-party service that helps broadcast transactions to the network. The relayer forwards this transaction to a node on the blockchain network. Later, when the user wants to perform operations, they encode multiple function calls into a single "multicall" transaction. This multicall is sent to the relayer rather than directly to the network. The relayer then forwards this multicall transaction to a node for execution.

The key innovation here is that this allows regular EOA (Externally Owned Account) addresses to execute contract code directly from their address, without needing to deploy separate contract instances. It essentially turns a regular address into a "smart account" that can execute arbitrary logic while maintaining the same address identity.

Infrastructure Layer

Bundlers must now adapt to handle and validate the new authorization field in user operations, and modify their simulation process to incorporate the authorization contract's code. Paymasters gain expanded capabilities, allowing them to interact with upgraded EOAs as if they were smart contracts. These changes enhance the flexibility of the account abstraction ecosystem, enabling more sophisticated transaction handling and gas sponsorship services for a broader user base, including traditional EOA holders.

Wallet & Embedded Wallet Layer

SDKs must be updated to support the new SET_CODE_TX_TYPE, enabling EOAs to permanently transition into smart contracts. This change opens up opportunities for embedded wallets to offer advanced features like gasless transactions and programmable controls without new account creation.

For embedded wallet providers like Dynamic, EIP-7702 integration offers day-one support, allowing developers to activate smart account features through a simple dashboard toggle. Their SDK enables wallets to access features like gas sponsorship and transaction batching while maintaining the same user addresses. This eliminates the need for separate smart contract deployments and preserves backward compatibility with existing applications.

The abstraction layer effectively decouples user experience from protocol implementation, enabling developer-facing APIs to remain stable while underlying transaction construction adapts to EIP-7702 requirements.

Wallet RPC Standardization

Standardized JSON-RPCs are crucial for EIP-7702 adoption. ERC-5792 serves as a meta-standard for wallet RPC interactions, creating a framework where specific smart account features can be standardized independently while maintaining consistency. Under this approach, individual features are being standardized separately—gas sponsorship through ERC-7677 and permissions (session keys) through the proposed ERC-7715.

For gas sponsorship, paymaster URLs can be included in the JSON-RPC call. This allows applications to simply specify their sponsorship provider when sending transactions, with the wallet handling all routing complexity. But advanced features such as session keys and cross-chain transactions are still being standardized, with discussions about optimal approaches for cross-chain functionality—particuarly whether chain identifiers should exist at the request or individual call level.

A significant technical advantage of EIP-7702 is that EOAs can execute contract code directly, enabling self-contained transaction batching without requiring bundler/paymaster infrastructure. The EOA simply sends a transaction that calls into itself to execute multiple operations. This creates a much more efficient and interoperable approach to batching.

As Derek Chiang, founder of ZeroDev, stated: "But with EIP-7702, if all you want to do is batching and you don't want to care about things like gas sponsorship and other features, the EOA can literally just send a regular EOA transaction that calls into itself. [Further elaboration.] So now you're able to do batch transactions through a regular EOA transaction, independent of any smart account infrastructure, which is way more efficient as well as way more interoperable."

With wallet RPC standardization, we’re creating a foundation for iteratively improving blockchain UX while maintaining interoperability across the ecosystem.

UI/UX Implications of Account Abstraction

By enabling EOAs to simultaneously function as smart accounts, wallet interfaces can introduce advanced features like gas sponsorship and transaction batching without forcing users to navigate entirely new mental models. With EIP-7702:

1. Users won’t need to transfer assets to new addresses

2. Can interact with previously incompatible applications

While promising, the long-term impacts and potential challenges of this implementation remain to be seen in practice.

EIP-7702 enables EOAs to execute smart contract code during transactions without permanent migration. This solves key integration problems with ERC-4337, eliminating the need for invoker contracts and allowing consistent UserOp structures across both account types.

The temporary code execution model introduces significant storage architecture challenges. Since EIP-7702 only attaches code during transaction execution, persistence between transactions requires external storage contracts. Developers must design specialized patterns for managing state that functions within these constraints. The proposal's approach to nonces and signatures also creates replay protection considerations that differ from both traditional EOAs and permanent smart accounts, particularly for implementations requiring multi-step operations or time-locked transactions.

Since an EIP-7702 account functions as both an EOA and a smart contract account, the EOA key will always retain "sudo access" to the wallet. This means you must continuously safeguard your seed phrases.There are also unique replay protection considerations and which require refinement for cross-chain implementations.

Going Beyond with Native Account Abstraction

Account abstraction allows smart contracts to initiate transactions, but it is not native (not integrated into the protocol itself ). Developers must implement it for specific applications using standards like ERC-4337. Native account abstraction however, enables smart contract accounts by default, so all accounts can execute code and initiate transactions autonomously and act similarly to EOAs in terms of transaction initiation.

With native AA, accounts are smart contracts by default, eliminating the concept of "sudo access" tied to EOA keys. You wouldn’t have to manage seed phrases, struggle with gas fees in specific tokens, or risk losing access after forgetting private keys.

EIP-7702 with ZeroDev and Gelato

EIP-7702 enables EOAs to be upgraded into dual-purpose accounts that retain their original addresses while gaining smart account functionality. ZeroDev implements this through a process where the EOA signs a 7702 authorization message that specifies which smart contract code should be attached to the account. This attached code is typically a proxy that points to ZeroDev's Kernel implementation.

Gelato provides the bundler infrastructure that processes the resulting UserOperations and handles gas payment. Their system executes the operations immediately upon receipt and calculates gas costs post-execution based on actual usage. The integration allows developers to leverage account abstraction features such as sponsored transactions, batched operations, and custom validation logic without requiring users to migrate to new addresses.

How ZeroDev is changing to add support for 7702

ZeroDev is expanding its account abstraction capabilities by adding support for EIP-7702, enabling users to upgrade existing EOAs into "dual accounts" that function simultaneously as EOAs and smart accounts. This implementation leverages ZeroDev's Kernel architecture, allowing users to maintain their original EOA addresses while gaining access to advanced features like gas sponsorship, transaction batching, and session keys.

The integration process is straightforward—users sign a 7702 authorization that specifies a proxy contract to be "copied" into their EOA, with ZeroDev handling the technical complexities through their SDK. By specifying parameters like eip7702auth: authorization and address: signer.address during setup, developers can seamlessly transform standard wallets into powerful smart accounts while preserving the EOA's root access for maximum security and backward compatibility.

Several possible use cases now emerge. ZeroDev's SDK implements EIP-7702 to provide transaction batching functionality for EOAs upgraded to smart accounts. This technical foundation could eventually support complex multi-operation batching for DeFi interactions. Instead of executing separate transactions for distinct operations—token unwrapping, asset swapping, and liquidity provision—a single batched transaction could handle the entire sequence. Such an approach would technically reduce total gas costs, eliminate the time gaps between sequential operations, and prevent the technical risks associated with partial execution states.

All code & docs are available to clone from open-source repositories ↓

Demo UI: gelato-eip-7702-demo.vercel.app

Demo Repo: gelatodigital/gelato-eip-7702-demo

Account Abstraction Demo Overview

Gelato’s Passkeys & EIP-7702 demo is a NFT marketplace that combines WebAuthn with EIP-7702 for enhanced wallet functionality. This implementation allows users to authenticate and execute blockchain transactions through secure biometric authentication (in this case fingerprint) rather than managing private keys.

We begin by generating an EOA with a random private key. It then creates a WebAuthn credential (Passkey) associated with this account. Using EIP-7702, the EOA delegates call execution to a pre-deployed contract called ExperimentDelegation, which adds the ability to verify Passkey signatures and batch transactions.

Implementation

In the UI code, the delegation process is executed through the signAuthorization function, which creates an EIP-7702 authorization object. This authorization is then included in the writeContract call through the authorizationList parameter, which instructs the blockchain to delegate call execution from the EOA to the ExperimentDelegation contract. The same transaction also calls the contract's authorize function, registering the WebAuthn public key parameters that will be used for future signature verification.

Transaction Execution flow

After the initial setup, the UI code handles transaction execution through the execute function. It fetches the current nonce from the contract, creates a transaction digest, and prompts the user to sign this digest with their Passkey. The resulting WebAuthn signature components (r and s values) are extracted and passed to the contract's aggregate function, along with the transaction data. The contract verifies the signature and executes the batched transactions if the signature is valid. Developers can now access our 7702 ABC testnet, which runs on Abundance's high-performance Rollup L1 framework. Check it out now at abundance.xyz!

ERC-4337 introduces programmable accounts through bundlers and EntryPoint contracts, enhancing the capabilities of smart contract wallets. However, it faces challenges related to gas efficiency and complex integration requirements. EIP-7702 offers a complementary solution by enabling EOAs to execute contract code without requiring a permanent address migration.

Gelato bridges infrastructure gaps by replacing EntryPoint's on-chain reimbursement with post-execution settlement, delivering superior gas efficiency, instant inclusion, and eliminating estimation errors. As these technologies mature, they promise to simplify blockchain interactions while preserving the security and flexibility that define web3's core value proposition.

Developer Library

Demo UI: gelato-eip-7702-demo.vercel.app

Demo Repo: gelatodigital/gelato-eip-7702-demo

Gelato Docs: docs.gelato.network

ZeroDev Docs: docs.zerodev.app

For developers looking to integrate their applications with Gelato Web3 Services, check out Web3 Functions, Relay, and apply for beta access to VRF! Visit our Discord server for developer support and engagement, and stay updated with the latest developments by following us on X.