#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
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.
