EIP-7702 explained: how Ethereum accounts can run smart contract code, and the new risks

Since May 2025, ordinary Ethereum accounts can run smart contract code. The change, EIP-7702, makes wallets more useful, but it also created a new kind of permission that attackers can abuse. According to TRM Labs, it played a part in the October 2026 Binance hack.

This guide explains what EIP-7702 does, using the proposal itself and ethereum.org’s guidelines, and what it means for your security.

Two kinds of Ethereum account

ethereum.org says Ethereum has two account types:

• Externally owned accounts (EOAs): controlled by anyone with the private keys, like most wallets.
• Contract accounts: smart contracts deployed to the network and controlled by code.

Before EIP-7702, an EOA couldn’t run code. EIP-7702 changed that. See what is a smart contract?

How a delegation works

EIP-7702 added a new transaction type that carries a list of authorizations. Each one is signed by the account’s private key and names:

• the address of a contract whose code the account will use;
• a chain ID, which locks the authorization to one network, or 0 for all networks;
• the account’s nonce, its transaction count, which locks the authorization to a specific point in the account’s history.

Once processed, the account’s code becomes a short pointer to that contract (a “delegation indicator”). From then on, whenever someone interacts with the account, the contract’s code runs in the account’s context, with the account’s funds.

The delegation is persistent: it stays until the account signs a new one. ethereum.org says it can be reset by delegating to the null address. It also notes that the account’s private key keeps full control after a delegation.

What it’s for

The proposal names three main features:

1. Batching: several operations in one transaction, for example approving a token and spending it in one step instead of two.
2. Sponsorship: another account pays the transaction fees, for example an app covering its users’ gas.
3. Privilege de-escalation: sub-keys with limited permissions, such as spending only one token, or only up to 1% of the balance per day.

These features are part of a wider push towards smart accounts. For gas, see Ethereum gas fees explained. For the upgrade, see Ethereum’s recent upgrades.

The risks

Delegating to the wrong contract

ethereum.org’s guidelines are blunt: if a user unknowingly delegates their account to a malicious contract, an attacker could easily gain control and steal funds. The proposal itself warns that a poorly implemented delegate contract can let a malicious actor take “near complete control” over an account.

Chain ID 0

An authorization signed with chain ID 0 applies on every network that supports it. ethereum.org warns that unless the contract is deployed in a way that guarantees the same code everywhere, such a delegation can put the account at risk on all other EVM chains.

Front-running and storage problems

For developers, ethereum.org and the proposal describe further pitfalls: attackers front-running a new account’s setup, storage collisions when switching delegate contracts, and old assumptions that a transaction’s sender is never a contract.

What wallets are told to do

ethereum.org says hardware wallets shouldn’t expose arbitrary delegation, and that the consensus is to allow only a list of trusted delegate contracts. It lists several audited implementations, and says companion apps can tell users when a delegation is in place and offer to remove it. There’s no standard way for apps to request a delegation signature directly; they’re expected to go through wallet interfaces.

How EIP-7702 featured in the Binance hack

TRM Labs says that on Ethereum, the Binance attacker submitted a transaction with 50 authorizations, each signed by a Binance hot wallet and each pointing it to a sweeper contract that took instructions only from the attacker. Because the hot wallet’s nonce kept changing as it processed withdrawals, signing 50 consecutive nonces made sure one would still be valid. One matched.

About three and a half minutes later, the attacker had the hot wallet send its entire balance. The delegation stayed in place, so funds that later arrived in the wallet were swept again.

TRM says EIP-7702 doesn’t explain the whole attack. In the same window, Binance wallets on the other nine blockchains sent funds to the attacker through ordinary signed transfers. In TRM’s assessment, the attacker had gained control over Binance’s signing infrastructure. See the $6.3 billion Binance hack.

How to protect yourself

1. Only accept delegations your wallet offers itself, to contracts it presents as trusted. Be suspicious of any website asking you to sign one.
2. Read what you sign. ethereum.org warns about blind signing, approving a transaction without understanding what it will do, and says wallets are moving to clear signing that shows it in plain language. If your wallet can’t show you what you’re approving, don’t approve it.
3. Check for an existing delegation if your wallet offers it, and remove any you don’t recognize.
4. Treat signature requests like transfers. A signature can give away control as surely as sending funds. See token approvals and how to revoke them.
5. Keep large holdings in a separate wallet that you don’t connect to apps. See hot vs cold wallets.