EIP-7702 Delegation
EIP-7702, “Set Code for EOAs,” adds an Ethereum transaction type 0x04 that lets an externally owned account (EOA) install a pointer to smart-contract code. Calls to the account then execute the delegate’s code in the EOA’s context, including its address, balance, and storage. The mechanism supports batched operations, transaction sponsorship, and smart-account features without transferring assets to a separate contract wallet.
Authorization and execution
A set-code transaction carries an authorization_list. Each tuple contains [chain_id, address, nonce, y_parity, r, s]; the EOA’s key signs the chain ID, delegate address, and nonce. During processing, the protocol verifies each tuple and writes 0xef0100 || address to the authorizing account’s code. Execution operations such as CALL, DELEGATECALL, and STATICCALL follow that pointer and run the target code in the authority’s context.
Authorization tuples are processed independently. If one fails validation, the protocol skips it and continues with later tuples. When several valid tuples belong to the same authority, the last valid one determines its delegate. Processed delegation indicators are not rolled back if the transaction’s later execution reverts.
chain_id restricts an authorization to one chain unless it is zero, which makes the authorization chain-agnostic. Since the signature covers a delegate address rather than its bytecode, the signer must also trust what that address contains on every chain where the authorization can be used.
Persistence and revocation
Delegation persists after the transaction. It has no passive expiry and no privileged administrative unset: the account must sign a new authorization that changes or clears the delegate. Authorizing the zero address resets the account’s code hash to the empty-code hash. Revoking the key or shutting down an off-chain service does not itself clear on-chain delegation.
The standard warns that delegate code has unrestricted access to the account. Fine-grained permissions must be implemented by audited delegate code or standardized modules, not assumed from the authorization envelope. Delegate contracts also need their own replay protection and signatures over security-relevant fields such as target, calldata, value, and gas. Initialization and storage migration require care because delegation itself does not run initcode and old storage persists.
These properties shift an important part of threat modeling from key custody to code and revocation custody: which delegate can execute, what operations it permits, on which chains, and how the account can clear it under incident conditions?
Binance containment case
Binance’s preliminary account of its October 2026 incident says an attacker used unauthorized access to an internal signing service to install malicious EIP-7702 delegation over a hot wallet. The delegation operated independently of the normal withdrawal infrastructure, so suspending withdrawals did not stop all asset movement. Binance cleared the delegation with a new authorization to the zero address at 00:10 UTC on October 30; its multi-party-computation wallet required a specialized revocation procedure.
The public report leaves the container-to-signer path and some authorization details undisclosed. It nevertheless supplies a concrete example of a confused deputy creating durable authority outside the control plane used for routine containment. Key protection and service shutdown addressed neither the delegate already installed nor the on-chain transaction required to remove it.
Operational checklist
- Treat an authorization signature as delegation to code, not as a narrow approval encoded by the tuple itself.
- Audit delegate code, initialization, replay protection, storage layout, and upgrade behavior before signing.
- Scope
chain_iddeliberately and inspect the delegate address on each applicable chain. - Monitor account code for delegation indicators across every chain where the account holds assets.
- Maintain and rehearse the ability to sign a zero-address authorization, including under MPC or other distributed signing arrangements.
- Include delegated state in containment inventories; credential rotation and withdrawal suspension are separate actions.
Related
- confused-deputy-problem — a signing service can validly produce an illegitimate delegation when it authorizes the wrong semantic operation.
- threat-modeling — delegation, persistence, and recovery alter both attack paths and response dependencies.
- eip-8363-tapered-issuance-burn — another protocol-level proposal whose security evaluation depends on explicit mechanism and incentive assumptions rather than application labels.