Summary: EIP-7702 is best understood as delegation infrastructure for Ethereum account abstraction rather than as a wallet product or a generic batching feature. Its core move is to let an externally owned account write a persistent delegation pointer to audited onchain code using a new transaction type, so the EOA can temporarily behave like a smart account without migrating assets or abandoning its original key. The important categorization clue is that EIP-7702 changes where wallet authority and execution logic can live: dapps are not supposed to ask users for raw delegation signatures directly, while wallets become the policy gatekeepers that decide which delegation contracts are safe enough to expose.
What it does:
Adds a new transaction type (0x04) that carries an authorization list of signed delegation tuples so EOAs can point to already-deployed contract code
Writes a delegation indicator (0xef0100 || address) into the EOA’s code slot so calls execute delegated code in the authority account’s context
Enables batching, sponsorship, and privilege-de-escalation patterns for EOAs without requiring a new smart-account address
Allows delegations to be reset by delegating to the null address, restoring the account’s empty-code state
Keeps the original EOA key in ultimate control, which means delegated accounts are not equivalent to fully sovereign multisigs or permission systems by default
Makes wallets, bundlers, paymasters, and module systems the practical control plane above the base delegation primitive
Key claims:
The final EIP says it adds a new EIP-2718 transaction type that allows EOAs to set code in their account by attaching authorization tuples, which makes this a base-layer delegation primitive rather than an app-specific UX trick
The motivation section explicitly frames the design around batching, sponsorship, and privilege de-escalation, showing that the standard is trying to pull legacy EOAs into the account-abstraction toolchain
The rationale says the delegation is persistent, not ephemeral, to avoid creating a separate “EOA scripting” ecosystem that would fragment smart-account UX development
The EIP says applications must not expect to suggest raw authorizations for users to sign and that wallets should not provide such an interface, which is a strong signal that wallet vendors become policy chokepoints for EIP-7702 adoption
The specification says processed delegation indicators are not rolled back even if later transaction execution fails, which matters because delegation state and transaction success can diverge
The rationale says EOAs can point directly to existing ERC-4337 wallet code, so EIP-7702 is designed as a bridge into the broader smart-account stack rather than a competing architecture
Ethereum.org’s official Pectra 7702 guidelines say dapps should integrate through standardized wallet interfaces such as ERC-5792 and ERC-6900 instead of directly requesting 7702 authorization signatures
Those same guidelines warn that msg.sender == tx.origin is no longer a safe reentrancy or EOA-assumption guard and highlight init frontrunning, storage collisions, phishing risk, and relayer centralization as key implementation hazards
The guidelines also recommend caution with arbitrary delegation exposure and list audited implementations, reinforcing that 7702 adoption will likely concentrate around wallet-approved contract templates rather than free-form user choice
Whitepaper: No standalone EIP-7702 whitepaper or litepaper surfaced in this pass. The clearest sources were the final EIP, its raw spec text, and Ethereum.org’s official implementation guidelines; see ../../whitepapers/eip-7702-primary-sources-2026-05-07.md.