Introducing: Ethereum Account Abstraction

February 27, 2026 by patrickd

As you're likely aware, Ethereum has two types of accounts: Externally Owned Accounts (EOA) and Smart Contract Accounts (SCA). Transactions can only originate from EOAs, which can then invoke the execution of an SCA's code. To send a transaction, you must be in possession of an EOA's private key and the account must be sufficiently funded with Ether to pay the transaction's gas cost.

While the effects of a transaction are fully programmable, the validity conditions of the transaction are fixed. In other words, once you've proven that you are indeed the address's owner, your transaction will be executed causing the programmed effects, incurring a cost up to the amount that you have promised to pay for. A transaction is dismissed as invalid if its ECDSA signature-related fields (v, r, s, nonce) don't allow the recovery of an Ethereum address that is sufficiently funded to cover what was promised as maximum gas payment.

Having such fixed validity conditions for block builders is very useful, since it allows verification in constant-time and guarantees that any work done during a transaction's execution will be appropriately paid. Unfortunately, it also means that a user receiving ERC-20 tokens cannot do anything with them until he funds his address with Ether, that access to the entirety of his tokens is controlled by a single private key which must be carefully stored, and that, if he loses it by accident or to a scammer, there's little to be done in terms of recovery or revocation of access.

Use Cases

Account Abstraction (AA) decouples the relation between account and signer, which is causing these user experience impediments. At its best, that means there's no longer a 1-to-1 relationship between a private key and an account. Instead, there can be a variety of ways to authenticate with an account in order to act in its name and make use of the funds it holds. The following is a list of typical use cases that result in consequence of this change.

History

Discussions on how Account Abstraction is best achieved are as old as Ethereum itself. An observable commonality in approaches is that they attempt to either teach EOAs to execute code, or SCAs to be invoked without requiring the user to have an EOA. Though ultimately, the goal has always been to eventually phase out EOAs completely by migrating them to become invocable SCAs.

There's also a notable crux issue in making a transaction's validity conditions programmable: The threat of Denial of Service (DoS) attacks on the Ethereum network by spamming it with transactions whose validation-program's execution is expensive and unpredictably invalid, causing unpaid work for block builders. Before, block builders could always rely on getting paid for spending time executing arbitrary code even if it eventually failed, because at that point it was already ensured that the EOA would have sufficient funds to pay for the gas. This is much more difficult to guarantee when the gas funding validation step itself requires code execution.

EIP-101

Even before its 2015 launch, the Ethereum project aimed to be as abstract as possible, to make as few assumptions as it could about how it would be used. We see this in a blogpost by Vitalik Buterin titled "On Abstraction"^[1] which discussed how Ethereum could be agnostic about its signature scheme, data structures, and currencies. The approach it suggested was attaching a verification code to EOAs which would be executed whenever a transaction was being processed. Instead of recovering a transaction's sender address from the ECDSA signature in the transaction's v, r, s fields, the sender is specified within a new sender field and a new signature field now carries an arbitrary byte array that is passed to the verification code.

Before, an account's address was the ECDSA public key's hash. Now, it would be the hash of the verification code attached to a transaction when the account would be first claimed. Each code hash would be unique as the code would contain the public key, though this time the key could be for any arbitrary signature scheme. To prevent DoS, the verification code would be restricted to 50,000 gas, subject to adjustments as needed.

Four months later, these ideas were formally defined within EIP-101^[2] where we can already see the first seeds of the "forwarding contract" idea. Transactions would have only had four fields (to, startgas, data and code) with to being the sender address, as well as the hash of the initial verification code to be set. The actual call's destination, the signature, and other information would have been moved into the data field. It additionally proposed moving Ether up a level of abstraction, allowing it to be treated similarly to other "sub-tokens".

EIP-86

In January 2017, we saw another attempt at "abstracting out" signature verification and nonce checking with the introduction of EIP-86.^[3] This time, the verification code would be placed in a "forwarding contract" which is called with transaction fields r, s, gasprice, nonce, and value set to zero, but with the v field containing the chain's ID. The user would specify the forwarding contract as the transaction's recipient, while the actual transaction information (signature, nonce, to, value, gasprice, and data) is sent to it as calldata.

The forwarding contract begins with validating whatever signature scheme it implements, updates its nonce in storage, pays the miner, executes the main call the user intended, and finally requests a gas refund. To prevent DoS, miners would either use pattern matching to only allow verification codes that are known to be safe, or by restricting how much gas the verification code may consume to perform nonce and signature checks.

EIP-859

The same year, in November, Vitalik made a comparison^[4] of some of the account abstraction approaches that would get rid of EOAs, by moving signature verification, gas payment, and replay protection out of the core protocol and into the EVM. The discussion resulted in an EIP draft that would have become EIP-859,^[5] though with core devs busy trying to figure out sharding, it never matured into a merged proposal. Even so, discussions on ways to achieve account abstraction continued,^[6] and we saw the first sophisticated Smart Contract Wallets such as Gnosis Safe and Parity Multisig Wallet emerge.

In case you're curious, the improvement proposal that wasn't meant to be, used a forwarding contract, similar to EIP-86, that verified the signature, paid for gas, and executed a call to the actual destination. It differed in introducing a new transaction type, instead of setting most fields of a normal transaction to zero. It also introduced a new PAYGAS opcode for paying the miners with gas, instead of having to make that transfer manually. Once the transaction execution would have reached PAYGAS, gas payment would have been guaranteed even if the execution reverted at a later point. The proposal dropped abstracting replay protection (nonces) in favor of preserving the invariant that "each transaction can only appear once in the chain".

EIP-2711

In 2020, we saw several proposals that offered partial solutions to AA's use cases.

EIP-2711^[7] would have introduced a new transaction type adding support for:

• Sponsored Transactions by allowing a signature to be signed by both the sender and the gas payer. By recovering the gas payer's address from the additional ECDSA signature, the gas cost would be subtracted from the sponsor's account, rather than the sender. The sender would have needed to submit their transaction to be signed by the sponsor off-chain.
• Batch Transactions by moving the transaction's payload into an array of child-transactions that would be executed in sequence.
• Expiring Transactions by adding an optional validUntil field that would cause the transaction to become invalid after a certain point in time.

EIP-2803

EIP-2803^[8] would have introduced "Rich Transactions", where a transaction sent to a special address, one in the range reserved for precompiles, would have its call data treated as EVM bytecode and executed within the context of the signer's EOA.

EIP-3074

EIP-3074^[9] proposed to introduce the AUTH and AUTHCALL opcodes, which would have temporarily delegated control of an EOA to an existing contract account. In the end, the proposal did not make it because it would have further enshrined EOAs, instead of being a step towards moving beyond them.^[10]

To delegate control of his EOA, a user would first (ECDSA) sign a message containing the contract's address, which is then passed as a function argument to the same contract. That function would invoke the AUTH opcode while passing it the signature, proving that the EOA's owner has indeed agreed upon giving its control to the contract.

From this point onward, within the same EVM context, that contract would be able to make external calls, equivalent to the CALL opcode, with AUTHCALL. The main difference being that msg.sender would be set to the EOA's address, instead of the contract's. Furthermore, any value sent as part of the AUTHCALL would be deducted from the EOA, instead of from the contract.

EIP-2938

Out of all the Account Abstraction proposals that never happened, EIP-2938^[11] was the most promising one, combining all of the learnings so far into a single coherent proposal. Specifically, it would have introduced a PAYGAS opcode which contracts can use to set the gas price and gas limit they're willing to pay. The opcode would also serve as an execution checkpoint, where the transaction only reverts up to the point right after it was called.

Practically, a user would send a new type of transaction containing only a nonce, the target address, and a byte array of arbitrary data. Lacking abstraction of replay protection, the target account's nonce-value would be compared against the transaction's nonce and incremented by one if it matched. Next, the code at target would be invoked and expected to execute PAYGAS to signal the transaction's validity within 90,000 gas.

Until PAYGAS is called, the contract's sole concern should have been determining whether the signature, passed within the transaction's data, is valid. Though it wouldn't have to be a signature, any arbitrary authentication method would work as long as it doesn't need to make use of environment opcodes, external calls, contract creations, or access to other contract's code. This restriction would be necessary to prevent a transaction from pretending to be valid off-chain, but then making use of state changes to become invalid on-chain, causing unpaid work for the network (DoS vector).

ERC-4337

Over time, it became clear that Account Abstraction via protocol changes (EIP) wouldn't happen any time soon, given that they're generally time intensive and most of the core developer's focus was committed to achieving Ethereum's switch to PoS. Instead, we saw ERC-4337^[11] emerge as a proposal for introducing AA as an optional, out-of-protocol solution in September 2021, though arguably we've seen first signs of it in 2018 with Justin Drake's Application-layer account abstraction^[12] post and the emergence of relay-based solutions such as the ERC-1613 Gas stations network^[13] proposal. Since its launch in March 2023 it has been widely integrated with SCA wallets such as Safe, but overall adoption and usage still remains relatively niche compared to the total EVM account base.

Given its length, a first look at the ERC can certainly be intimidating. It declares various aspects "out of scope", leaving the reader wondering where these things are specified. Moreover, the standard has been continuously evolving with the latest changes for "v0.9" having been applied just a few months ago.^[14]

The standard introduces a new type of data object called UserOperation which, similar to a transaction, is send to a peer-to-peer (P2P) network (JSON-RPC API eth_sendUserOperation call) of nodes keeping track of such operations in an "alternate mempool". This means that UserOperations are kept track of in a mempool separate from the one keeping track of transactions, avoiding changes to Ethereum's consensus protocol.

Whether nodes accept such operations is up to them, but those that do may participate in bundling multiple UserOperations into a single transaction, similar to how Block Builders bundle multiple transactions into a single block to be added to the chain. It should be noted that the details on the validation of user operations has changed over the various versions of the standard.

function handleOps(PackedUserOperation[] calldata ops, address payable beneficiary);

All operation-bundling transactions call the handleOps() function on one of the official EntryPoint contracts:

Each version, being the central trusted manager of all ERC-4337 UserOperations, has been audited to ensure that invariants such as the following hold:

The handleOps() function is passed the bundle of user operations as well as the beneficiary address that should receive the gas refund. The function makes two loops, the verification loop and the execution loop. The first iterates over all operations calling sender.validateUserOp() on each, with sender being a SCA wallet.

function validateUserOp(
  PackedUserOperation calldata userOp,
  bytes32 userOpHash,
  uint256 missingAccountFunds
) external returns (uint256 validationData);

Aside from checking whether the UserOperation is valid for the given signature value, validateUserOp() must at least send the missingAccountFunds to the EntryPoint contract. Any Ether sent above this amount is automatically considered a deposit. Note that EntryPoint has a set of functions for managing Ether deposits. A sender that has deposited a sufficient amount into EntryPoint will receive 0 for missingAccountFunds and can save gas by skipping the refunds to EntryPoint for every UserOperation.

Once the verification loop has finished, the execution loop begins calling on each sender for which validateUserOp() succeeded and necessary payment has been made. The call is executed using the UserOperation's callData, meaning that there's no specific "execution function" that must be used. Though if the calldata starts with the function signature of validateUserOp(PackedUserOperation,bytes32), the rest of the callData will be ignored and the appropriate call will be made passing the UserOperation and its hash instead.

Once the SCA has finished executing the operation, the wallet is refunded the excess gas cost that was pre-charged during verification, the rest is used to reimburse the Bundler. To prevent a UserOperation from reserving too much gas space within a bundle, a penalty of 10% is applied on gas that remained unused if that remaining amount is $\ge{40},{000}$.

With that we've walked through the entire flow following a normal ERC-4337 operation from submission to execution. The flow is slightly extended when the UserOperation specifies a paymaster, which usually either means that the operation is being sponsored (gas is payed by paymaster) or that it wants to pay for the gas cost in another way (e.g. with ERC-20 tokens).

Though the ERC-4337 standard introduced much needed account abstraction at the application layer, there are ongoing efforts to natively enshrine it. In RIP-7560 (opens in a new tab) we see how splitting a transaction into multiple frames leads to an elegant introduction of user operations for Layer 2 protocols. And with EIP-7701 (opens in a new tab) account abstraction would finally land on mainnet together with EOF, allowing the EVM to remain language agnostic. Overall, the hope is to keep such changes as compatible as possible with ERC-4337 to ensure that the existing account abstraction ecosystem will be able to go native with little effort.

EIP-7702

This standard complements ERC-4337 by basically allowing users to turn their existing EOA wallets into SCA wallets. Though, that's not the complete story: The account will remain accessible through its original public-key pair, presenting both a potential weak point and backdoor in the long term. Even so, EIP-7702 went live in May 2025 as part of the Pectra update with great hopes of incentivizing ERC-4337 use.

EIP-7702 introduces a new transaction type called Set Code (setcode) or Type-4 (0x04) which contains a so-called authorizationList. As you might have guessed from the name, each of the "authorizations" in this list delegates an EOA account to a specified contract account.

Each of the list's items is signed by that EOA's private key which has several implications:

• Users can convert multiple of their EOAs to become a smart contract account in a single transaction.
• Users can convert multiple EOAs across multiple specific chains with the same transaction.
• Wallet providers can collect authorizations and make a bulk-conversion-transaction for which they sponsor the fees.

When such an authorization is applied upon an EOA account, its code is set to begin with 0xef, a banned opcode. A purposeful choice to indicate that this account's code must be handled differently than regular code (ie. not to be executed by the EVM). To control how exactly the code should be dealt with instead, the opcode is followed by 0100 and then by the specified contract address from the authorization. Specifying a delegation to the zero-address resets the account's code and turns it back into a normal EOA.

The standard does not implement any explicit initialization phase here: The code is simply set as a "template" for the EOA, which means that no constructor will be executed to initialize the EOA's storage. Neither is it possible to specify a call to an explicit initialization-function to initialize the EOA's storage when the delegation is set.

References