EIP-7702 Delegation Risk Explainer

EIP-7702 ("Set Code for EOAs") adds a new transaction type, 0x04, that lets an externally owned account attach signed authorizations so that a delegation indicator is written into its code. Its status on the EIP site is Final. ethereum.org says the Pectra upgrade that included it went live on 7 May 2025, at epoch 364032 (10:05 UTC).

The account owner signs an authorization tuple [chain_id, address, nonce, y_parity, r, s], and anyone can include it in a set-code transaction. If the checks pass, the account’s code becomes 0xef0100 followed by the 20-byte delegate address. That 23-byte value is the delegation indicator (sometimes called the designator), and calls to the account then run the delegate’s code.

By signing and submitting a new authorization whose address is the zero address. The EIP says that clears the account’s code and writes no delegation indicator. The authorization still needs a valid signature from the account and a nonce equal to the account’s current nonce, and any account can send it. The Ethereum Foundation notes the owner can always create another authorization that revokes or replaces the delegation.

Whatever its code allows, with the account’s funds and permissions. The EIP says the code an authorization points to has unrestricted access to the account and must be closely audited, and that a poorly implemented delegate can let a malicious actor take near-complete control of the account. Good delegates are meant to add batching, gas sponsorship and spending limits.

In its 4 November 2026 post Binance said the attacker used its internal wallet signing service to exploit EIP-7702 and give an attacker-controlled smart contract partial execution rights over a hot wallet. It said suspending withdrawals alone could not stop this, because the malicious authorizations existed on-chain independent of withdrawal infrastructure, that the attackers submitted 50 signing transactions to manipulate the account nonce and establish delegations, and that it cleared the delegation at 00:10 UTC on 30 October with a new authorization to the zero address. This is Binance’s account; it is not independently verified and its investigation is ongoing.

Binance said that because its hot wallet used MPC there was no single private key to revoke the delegations with, so a specialised procedure was needed and it took time. In general, revoking is one more signature, so the question is whether your custody setup can produce it quickly and whether your signing policy allows that message type. The worksheet in this tool turns that into questions to answer and a drill to run.

It is opt-in and needs the account’s own signature, and the Ethereum Foundation lists safety checks: delegations are chain-specific by default, can be bound to the account nonce, and can always be revoked or replaced by the owner. The risk the EIP names is signing an authorization for code you have not vetted. For organisations the extra exposure is anything that can make a signing key sign, which is why the signing policy must cover authorization types.

No. It makes no blockchain calls and no requests to third parties from your browser, never asks for keys or a wallet connection, and the simulator uses a made-up account. Your worksheet is kept in this browser’s local storage only.