What Is Account Abstraction?

In brief

• An account is an onchain entity; a wallet is software or hardware used to control and interact with accounts.
• An Ethereum EOA has protocol-defined signature and nonce rules and is controlled by a private key. It is not literally “just a key pair.”
• A smart account is contract code that implements programmable authorization and execution.
• ERC-4337 defines an overlay transaction flow: users send UserOperations to bundlers, which submit them to an EntryPoint contract.
• A paymaster can pay native network fees from its EntryPoint deposit under programmable conditions. Paying the paymaster back in a token is application logic, not Ethereum accepting that token as gas.
• EIP-7702, live since Pectra in May 2025, adds type-4 set-code transactions and signed authorization tuples for EOA delegation.
• A 7702 delegation persists after the transaction until replaced or cleared; describing it as temporary is incorrect.
• Recovery, passkeys, session keys and spending limits are wallet policies, not automatic properties of either standard.

Why EOAs are restrictive

Ethereum has historically distinguished:

• externally owned accounts (EOAs), which can originate transactions when authorized by their secp256k1 private key; and
• contract accounts, which execute code when called but do not possess a protocol-recognized private key.

An EOA’s authorization rule is fixed by the protocol. It cannot natively require two devices, rotate to a new key after recovery, limit a session key to one game, or reject a large payment after a daily cap. It also must arrange payment of transaction gas in ETH.

Smart contract wallets have long implemented richer policy, including multisignature checks and ERC-1271 contract-signature validation. The awkward part is initiation: Ethereum still needs an ordinary transaction to call the contract. Account-abstraction systems standardize ways to validate and execute user intent without forcing every user-facing action into the EOA model.

“Abstraction” does not mean every account has identical features. It means the infrastructure no longer hardcodes all wallet policy into one private-key rule.

ERC-4337: an alternate transaction pipeline

ERC-4337 deliberately avoids a consensus-layer change. It introduces a higher-layer object called a UserOperation. The EIP calls it a pseudo-transaction to avoid confusing it with the Ethereum transaction that ultimately includes it.

A simplified flow is:

1. Wallet software builds a UserOperation naming the smart account, nonce, execution call, gas limits, fee parameters, optional factory data, optional paymaster and signature.
2. The wallet sends it to a dedicated UserOperation mempool through a bundler.
3. Bundlers simulate validation and reject operations that would fail or violate shared mempool rules.
4. A bundler groups operations and sends an ordinary Ethereum transaction calling handleOps on an EntryPoint contract.
5. EntryPoint validates each account and optional paymaster, ensures fees are covered, then calls the account for execution.
6. EntryPoint reimburses the bundler from account or paymaster deposits.

The EntryPoint is a shared contract, not an Ethereum protocol opcode. A smart account must trust the intended EntryPoint and reject unauthorized callers in its validation path.

Counterfactual deployment

A UserOperation can include a factory and initialization data for an account that has not yet been deployed. EntryPoint can ask the factory to create it before validation. This supports onboarding to a predictable smart-account address without requiring a separate deployment transaction first.

Nonces and replay protection

ERC-4337 maintains nonces through EntryPoint and permits multiple nonce “keys,” allowing account designs with parallel operation sequences. Signatures must bind the chain and EntryPoint address so an operation cannot simply be replayed through another deployment or network.

The account still decides what counts as authorization. It might verify one ECDSA key, multiple signatures, a passkey proof, a session key or another module. Bad validation code can lose the account’s assets.

Bundlers and the alternate mempool

Bundlers pay L1 or L2 gas to submit handleOps, so they simulate UserOperations before accepting them. Programmable validation creates denial-of-service risks: an operation could be cheap to announce but expensive or unstable to validate.

ERC-7562 defines validation rules used by ERC-4337 mempools to constrain opcode use, storage access and dependencies during validation. Staked factories, paymasters or aggregators can receive broader access under reputation rules.

These protections introduce practical tradeoffs:

• bundlers can apply local policies and may disagree about admissibility;
• a UserOperation accepted by one bundler may be rejected by another;
• limited bundler availability can delay inclusion; and
• private routing can improve reliability while reducing the benefits of a public mempool.

Users do not need to trust a bundler with custody or execution authority—the smart account and EntryPoint validate the operation—but they do depend on bundlers for timely submission unless another route exists.

Paymasters and “gasless” transactions

A paymaster is an optional contract that agrees to fund an operation. It deposits native currency in EntryPoint and validates whether it is willing to pay.

A paymaster might:

• sponsor a new user’s first action;
• pay only for calls to a particular application;
• require an offchain authorization from a service; or
• charge the user an ERC-20 token through separate accounting.

“Gasless” means the user did not directly supply the native gas asset for that operation. Somebody still pays the validator or sequencer. If a paymaster’s validation or accounting is unavailable, sponsored operations can stop. A malicious or poorly written paymaster can also grief bundlers or overcharge users under its own rules.

EIP-7702: persistent delegation for EOAs

EIP-7702 is a protocol change included in Ethereum’s Pectra upgrade. It introduced the type-4 set-code transaction, whose authorization list contains tuples signed by EOAs.

For each valid authorization, Ethereum writes a 23-byte delegation indicator into the authorizing EOA’s code:

0xef0100 || delegate_address

When the EOA is called, Ethereum follows that indicator and executes code stored at the delegate address in the EOA’s context. The EOA keeps its address, balance, nonce and storage. It does not copy arbitrary runtime bytecode into itself.

The delegation is persistent. It remains after the set-code transaction—even if that transaction’s execution later reverts—until a later authorization points elsewhere or uses the zero address to clear it. Wallets must treat delegation as an account upgrade, not a one-click temporary script.

Sponsorship and batching

The transaction sender and the EOA signing an authorization tuple can be different accounts. This permits a sponsor to submit and pay for a type-4 transaction containing someone else’s valid authorization. Once delegated code is active, that code can implement batching and other wallet behavior.

EIP-7702 itself does not define paymasters, guardians or passkeys. Those features must be implemented by the delegated code or by another system such as ERC-4337.

Security of delegation

An authorization points to deployed code with broad power over the EOA’s execution. The EIP warns that applications should not casually ask users to sign arbitrary delegations; wallets should recognize and audit supported implementations.

Risks include:

• delegating to malicious or unexpectedly upgradeable code;
• cross-chain differences at the same delegate address;
• initialization mistakes because 7702 does not run contract-creation initcode;
• signatures with overly broad chain scope;
• storage collisions when changing implementations; and
• assuming that clearing delegation reverses actions already taken.

The original EOA key remains important because protocol-level authorization tuples use its signature. Delegated code can add policy for calls, but 7702 does not erase the root key’s power to replace delegation.

ERC-4337 and EIP-7702 are different—and composable

ERC-4337:

• works through contracts without an Ethereum consensus change;
• uses UserOperations and a dedicated mempool;
• relies on bundlers and EntryPoint;
• naturally supports counterfactually deployed contract accounts; and
• lets each account define validation through contract code.

EIP-7702:

• is an Ethereum transaction-type and state-transition change;
• upgrades an existing EOA by writing a delegation indicator;
• uses ECDSA-signed authorization tuples at the protocol layer;
• does not require EntryPoint or a UserOperation mempool; and
• keeps delegation until it is deliberately changed or cleared.

They can work together. The current ERC-4337 specification describes how a bundler can include 7702 authorizations in a type-4 bundle transaction, allowing an EOA with delegated code to participate in the EntryPoint flow.

Recovery and passkeys are policy, not magic

A smart account can authorize multiple devices, guardians or keys and replace one credential after a delay. It can verify WebAuthn/passkey signatures if the chosen implementation supports them. It can also issue narrowly scoped session keys.

Each feature adds failure modes:

• guardians can collude or become unavailable;
• a recovery delay can be abused or be too slow;
• cloud-synced passkeys introduce platform and account-recovery dependencies;
• modules may have upgrade or storage bugs; and
• a spending limit is useful only if every execution path enforces it.

Account abstraction can reduce dependence on one seed phrase, but it replaces a simple security model with programmable policy. Users still need a trustworthy root of recovery and clear ways to audit or revoke authority.

What users should check

Before using a smart account, identify:

• whether it is an ERC-4337 contract account, a 7702-delegated EOA or both;
• which keys, guardians and modules can authorize actions;
• who can upgrade the account implementation;
• which EntryPoint and bundlers it relies on;
• whether a paymaster can refuse service or charge another asset;
• how recovery works and how long it takes; and
• how to revoke sessions, modules and 7702 delegation.

The live Crypto wallet, Private key, Seed phrase, Self-custody and Smart contracts articles provide the surrounding concepts. Account abstraction changes authorization plumbing; it does not change the basic rule that control follows whatever credentials and code the account recognizes.