# EIP-7702 and ERC-4337: what changes for an EOA?

## Short answer

EIP-7702 lets an externally owned account (EOA) authorize a pointer to already-deployed contract code. Ethereum records that pointer as a delegation indicator in the EOA’s code field, and EVM calls to the EOA execute the pointed-to code in the EOA’s account context. The account can therefore gain programmable wallet behavior—such as batching, sponsorship, and restricted sub-key permissions—while retaining its address and ability to originate ordinary transactions. The EOA’s private key remains powerful: it can still authorize transactions and change or clear the delegation, so delegation alone does not turn a single-key EOA into a multisig.

ERC-4337 supplies a higher-layer account-abstraction transaction path. Its `UserOperation`, bundler, and `EntryPoint` can operate with a 7702-delegated EOA as the account, provided the account code implements the expected ERC-4337 behavior and the bundler/EntryPoint supports the 7702 authorization flow. In that arrangement, 7702 supplies the EOA’s delegated account code; 4337 supplies standardized UserOperation processing, validation, bundling, and optional paymasters.

## What EIP-7702 changes

EIP-7702 defines a new set-code transaction (type `0x04`) containing signed authorization tuples. For a valid tuple, the protocol writes a 23-byte delegation indicator (`0xef0100` plus a contract address) to the authorizing EOA. When code-executing operations call that EOA, the EVM loads the designated contract’s code but executes it in the EOA’s context. The delegation is persistent until replaced or cleared; setting the target to the zero address clears it. The authorizing account must have empty code or an existing delegation, and the authorization nonce and chain ID are checked. [Official EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702)

That gives an existing EOA a route to smart-account-like behavior without moving its assets to a newly deployed account. EIP-7702’s stated use cases include:

- **Batching:** combine multiple actions, such as token approval and a subsequent spend, atomically.
- **Sponsorship:** another party can submit and pay for the transaction, potentially recovering the cost in another token or subsidizing it.
- **Privilege de-escalation:** the delegated logic can accept narrower keys or permissions, such as app-specific or amount-limited authority.

These are capabilities of the delegated code and its policies, not automatic protocol features. In particular, the original EOA key retains control and can bypass restrictions implemented only in the delegated code. EIP-7702 also does not directly install arbitrary bytecode or run initialization code as part of the authorization; it points to deployed code, and setup is done by a later call. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)

## How it fits with ERC-4337

ERC-4337 represents an account’s requested action as a `UserOperation` sent to a separate mempool. A bundler validates and packages operations into an on-chain `EntryPoint.handleOps` call; the EntryPoint asks the account to validate the operation and then executes it. A paymaster can sponsor gas through the EntryPoint’s defined flow. ERC-4337 is designed to provide this abstraction through higher-layer infrastructure rather than a new Ethereum consensus transaction model. [Official ERC-4337 specification](https://eips.ethereum.org/EIPS/eip-4337)

The ERC-4337 specification explicitly supports EIP-7702 on enabled networks:

1. A `UserOperation` may carry an `eip7702Auth` authorization signed by its `sender`. The bundler includes the required authorizations in the transaction’s authorization list and submits the bundle as a 7702 set-code transaction.
2. An EIP-7702 account is indicated in the packed operation’s `initCode` using the `0x7702` marker. This path does not call a factory; any bytes after the marker can be used as account initialization calldata.
3. The UserOperation hash incorporates the desired delegation address when the marker is used. The 7702 authorization cost is not visible to the EntryPoint itself, so the specification says it must be included in `preVerificationGas`.
4. A 7702-delegated account implementation must protect initialization: ERC-4337 says initialization calls must originate from `EntryPoint.senderCreator()`, and recommends allowing initialization only once.

A UserOperation can still be submitted without the marker/initCode, but then its hash does not bind the current delegate address; ERC-4337 warns that the operation could consequently be executed against a modified account. Correct wallet and bundler handling of the marker, authorization, hash, initialization, and gas accounting is therefore material to safe integration. [ERC-4337, “Support for EIP-7702 authorizations” and “EIP-7702 delegated Smart Contract Accounts”](https://eips.ethereum.org/EIPS/eip-4337)

## Practical distinction

EIP-7702 and ERC-4337 complement one another rather than describing the same layer. EIP-7702 is a consensus-level mechanism to make an EOA execute code by delegation. ERC-4337 is an account-abstraction flow for expressing, validating, sponsoring, and bundling account operations. A delegated EOA can use ERC-4337 when its delegate implements the account interface and the infrastructure supports 7702; 7702 by itself does not create the whole ERC-4337 mempool and paymaster system, and ERC-4337 by itself does not change EOA code under the protocol.

## Limitations

This report summarizes the specifications, not the security of any particular delegate contract, wallet, bundler, paymaster, or chain deployment. EIP-7702 gives delegated code access to the EOA’s account context and assets, while the original key retains authority; users and integrators must assess the specific implementation and authorization flow. The compatibility described here depends on implementation support and correct operation of the ERC-4337 requirements cited above.