Ethereum’s Pectra account abstraction and EIP-7702 on Base
The EOA and smart contract gap
Ethereum uses two primary account types: externally owned accounts (EOAs) and smart contracts. EOAs use private keys to sign transactions. They cannot respond to inputs like receiving tokens and lack flexibility. Smart contracts run programs without associated private keys. Account abstraction bridges this gap by allowing smart contracts to perform user actions on the blockchain. I find the distinction between these account types easy to define. Externally owned accounts rely on private keys to sign transactions. Smart contracts execute code when triggered by those transactions. Account abstraction combines these two models into a single programmable unit. This combination allows for features like social recovery and gas sponsorship.
The earliest examples of account abstraction used multi-signature smart contracts from platforms like Safe. These contracts hold assets and require multiple signatures for transaction approval. This approach separates asset custody from transaction authorization. The community developed ERC-4337 in 2023 to provide a unified framework for smart contract wallets. ERC-4337 uses UserOperations, which are objects containing user intent and smart contract addresses. These operations sit in an alternative mempool and get collected by Bundlers. Bundlers group these operations into single transactions and submit them to the EntryPoint contract.
ERC-4337 provides gas sponsorship through Paymaster contracts. This allows users to trade on DEXs without holding ETH. It also enables transaction batching, where a smart contract combines multiple actions into a single call. Social recovery allows users to set up guardians to recover accounts if they lose their private keys. However, ERC-4337 requires users to create new addresses to use smart wallets. Users with existing EOA accounts cannot convert to ERC-4337 without transferring all assets.
Traffic patterns on Base and Mainnet
The data from September 14, 2026, refutes the idea that EIP-7702 replaced ERC-4337. On Base, EntryPoint calls ran at 3.105% of transactions while type-4 setcode transactions reached 0.26%. This means ERC-4337 traffic exceeds type-4 traffic by about twelve times. Because the EIP-7702 delegation mechanism only requires a single transaction to set the code, the current traffic on the Base network shows that ERC-4337 still handles much more than twelve times the transaction volume of EIP-7702. On Ethereum mainnet, type-4 transactions fluctuated between 0.76% and 1.20% in two different samples, while ERC-4337 EntryPoint calls held a 1.404% share.
I also note that cumulative counters can mislead people. The 5,336,879 setcode transactions on mainnet include many instances where sweeper contracts re-authorize constantly. These sweeper contracts account for a huge portion of the count and represent zero actual users. On Base, 4% of distinct senders returned delegated code in the sampled window. I find the ratio of 12 to 1 on Base to be a clear indication that ERC-4337 still carries real, recurring traffic.
The lifetime statistics for ERC-4337 show high adoption. The standard has facilitated the creation of over 26 million smart wallets and 170 million UserOperations. Regarding gas sponsorship, paymasters account for roughly 1.01 billion UserOperations. This means most UserOperations are sponsored. However, sponsors cover roughly $0.014 of gas per sponsored operation over the lifetime of the standard. This is a small per-operation subsidy.
Comparing account abstraction standards
ERC-4337 and EIP-7702 work together to improve the user experience. ERC-4337 provides a framework of smart contracts that uses UserOperations and Bundlers to process intents. This standard requires users to deploy new smart contract wallets with new addresses. EIP-7702 allows existing EOAs to delegate execution to smart contracts for a single transaction via a new transaction type. This transaction includes an authorization_list field containing chain IDs and smart contract addresses. Users do not deploy separate smart wallets but instead delegate transaction execution to predefined smart contract code. This delegation can be revoked when desired.
You likely already know the difference between a private key and a smart contract.
| Wallet | AA Standard | Signing | Gas Sponsorship | Best for |
|---|---|---|---|---|
| Coinbase Smart Wallet | ERC-4337 | Passkey | Paymaster, USDC on Base | Consumer onboarding |
| Safe | ERC-4337 | Multi-sig | Paymasters | Institutions |
| Biconomy SDK | ERC-4337 + 7702 | Varies | Full paymaster | White-label apps |
| Magic.link | EOA + 4337/7702 | Email/Social | Via paymaster | Web2-style apps |
The combination of these tools enables features like batching multiple actions into one call. It also enables gas sponsorship, where a paymaster covers transaction costs. This allows a user to trade on a DEX without holding ETH. Users can also use passkeys for faster authentication. EIP-7702 also allows for session keys, which let an application execute transactions within defined parameters. This is useful for gaming applications that need to execute transactions without constant signatures.
EIP-7702 provides a transitional path for existing users. Users can maintain their assets and on-chain identity while gaining the UX benefits of ERC-4337. An EOA can use EIP-7702 to delegate to a contract handling UserOperations. This allows users to benefit from proven paymaster infrastructure while retaining their original address.
Security and the private key problem
The security of all account abstraction standards rests on the private key. I find the reliance on private keys in EIP-7702 to be a massive security weakness. The private key remains the root of control. If a thief steals the private key, they gain full authority over the account. EIP-7702 does not add social recovery or multi-factor authentication at the protocol level. Users must still use purpose-built smart contract wallets for those needs. EIP-7702 also introduces delegation risk because users must trust the implementation they delegate to.
Smart contract risk also exists because smart wallets rely on smart contract code. Bugs or vulnerabilities in the wallet implementation could lead to a loss of funds. While established, audited implementations reduce this risk, they do not eliminate it. Additionally, EIP-7702 creates a complex new attack surface with bundlers, paymasters, and delegation permissions.
For institutional users, EIP-7702 offers a lower-friction entry point to programmable transaction execution. Custody providers can implement delegation to give EOA-based products programmable behavior without full migration. However, most institutional use cases still require the persistent programmability found in full smart contract wallets. Will the integration of EIP-7702 into every major wallet provider finally eliminate the need for seed phrases?
