What Is EIP-7702? Understanding the Security Risks of Ethereum Account Authorization Through the Binance Hot Wallet Theft

In the blockchain world, private keys have always been considered the last line of defense for protecting digital assets.
As long as your private key hasn’t been compromised, it’s difficult for someone else to take direct control of your wallet.
But if one day your assets could still be at risk of being transferred out even though you didn’t initiate a transfer and your private key hasn’t been definitively confirmed as compromised, would you be surprised?
The Binance hot wallet security incident on October 29, 2026, brought a previously rather specialized technical issue to the attention of a much wider audience: the EIP-7702 account delegation mechanism and the security risks it may pose.
Public security analyses indicate that this incident involved an attacker using the EIP-7702 mechanism to delegate the wallets in question to a malicious sweeper contract, then transfer the assets.
What exactly happened?
What is EIP-7702, and why might it affect wallet assets? How can ordinary users identify and guard against related risks?
This article starts with the basic principles and explains these questions step by step.
I. First, understand this: why can wallet approvals pose a risk?
Suppose your Ethereum wallet contains:
2 ETH;
5000 USDT;
Some other ERC-20 tokens.
Your private key has stayed in your possession, and you have not made any transfers yourself.
One day, you visit a DeFi website. It prompts you to sign an authorization message. Thinking it's just a routine step, you click confirm.
Later, you notice unusual activity involving the assets in your wallet.
Here's the question: if you didn't initiate a transfer, why could your assets still be moved?
One reason is that the action you signed may not have been a simple login or message verification. It may have granted another program some ability to manage your assets.
To understand this risk, first distinguish between two different types of authorization.
1. Traditional ERC-20 approval: allowing a specified address to use a type of token
Take USDT as an example.
When you call the token contract's approve method, you can authorize an address to use your tokens up to a specified amount.
For example:
Wallet address: W
Token: USDT
Spender: A
Allowance: 5000 USDT
This means that while the approval remains valid, A can use the relevant methods in the token contract to transfer your USDT, up to the approved amount.
Please note:
A will not gain access to your private key;
A will not gain permission to use your other tokens;
This approval applies to a specific token contract;
If some of the approved amount remains unused, the risk may persist.
That's why wallet security tools often check Token Approvals.
2. EIP-7702 delegation: allowing a wallet to use code from a specified contract
EIP-7702 is a different mechanism.
It allows a traditional Ethereum externally owned account (EOA), after authorization, to delegate code execution to an already deployed smart contract.
Put simply:
A traditional token approval means:
I allow A to use a certain type of my tokens.
An EIP-7702 delegation is closer to:
I allow my wallet to use the program logic provided by A to perform operations.
These two mechanisms have different scopes of impact.
If the delegated code is designed securely, it can let a wallet support batch transactions, gas sponsorship, more flexible permission management, and other features.
But if the delegation target is a malicious contract, or the code contains a serious flaw, the risk goes far beyond that of an ordinary token approval.
Ethereum's official specification also explicitly warns that poorly designed delegated code could give an attacker almost complete control over an account's assets.
II. What exactly is EIP-7702, and why was it designed?
EIP stands for Ethereum Improvement Proposal.
The formal name of EIP-7702 is:
Set Code for EOAs.
It is part of Ethereum's Pectra upgrade and was enabled on Ethereum mainnet with that upgrade in May 2025.
To understand it, you first need to know about two common types of accounts on Ethereum.
1. EOA: a traditional wallet account
The ordinary accounts we create with wallets such as MetaMask are usually EOAs.
Typical characteristics include:
Controlled by a private key;
Can sign transactions directly;
Does not itself have deployed application code like an ordinary smart contract;
Traditional operations usually require the user to sign the corresponding transaction.
2. Smart contract account: behavior defined by code
A smart contract account's behavior is determined by code deployed on the blockchain.
Developers can use code to implement:
Bundled execution of multiple operations;
Complex permission management;
Transaction sponsorship;
More flexible asset management workflows.
However, traditional EOAs and smart contract accounts differ in how they are used.
One of EIP-7702's goals is to give traditional EOAs some smart-account capabilities without requiring them to give up their original account address entirely.
3. How does EIP-7702 work?
Suppose you have an ordinary wallet W and want it to have smart-account capabilities.
With EIP-7702 authorization, you can delegate code execution for W to an already deployed contract A.
Conceptually, this can be understood as:
Original wallet W
    |
    | Sign a valid EIP-7702 authorization
    |
    v
Wallet W sets a delegation marker
    |
    v
Points to contract A
    |
    v
When wallet W is called
It can execute code provided by contract A
Note carefully: this does not transfer the wallet's assets into contract A.
Wallet W remains at its original account address, and its assets are not automatically transferred just because a delegation is set.
What changes is that the code execution behavior of wallet W can be affected by code provided by the delegation target.
That is both where its value and its risks lie.
III. The Binance hot wallet incident: what should we pay attention to?
In the Binance hot wallet incident on October 29, 2026, an attacker used the EIP-7702 delegation mechanism to point the affected hot wallets to a sweeper contract deployed by the attacker, then transferred assets. Independent analyses have also described fund movements across multiple chains.
However, not every unconfirmed detail about the attack should be treated as fact. In particular, how the attacker obtained signatures, why the authorization passed security checks, and whether the attacks on different chains used exactly the same method should be established based on official investigations and reliable follow-up evidence.
From a security perspective, there are three things worth noting about this kind of incident.
1. EIP-7702 is not the attacker
EIP-7702 is a protocol feature.
It allows wallets to delegate code, enabling more flexible account capabilities.
Without this feature, an attacker could not exploit the EIP-7702 delegation mechanism in the same way. But that does not mean the protocol itself has a vulnerability.
Just as cars help people get around but can also be misused by criminals, the technology itself and specific attacks should be discussed separately.
2. How did the attacker obtain valid authorization?
EIP-7702 authorization must meet protocol requirements, including signature and account-state conditions.
Therefore, an important question when analyzing a specific incident is:
How was the attacker able to obtain valid authorization, or get the system to accept the authorization in question?
Potential security issues include:
Exposure of a private key or signing capability;
Compromise of a wallet or transaction-signing system;
A user or operator being tricked into signing a dangerous authorization;
Flaws in authorization verification, transaction approval, or security monitoring.
These are different attack paths. Without evidence, we cannot conclude that any one of them was the actual cause of the incident.
3. Authorizing a malicious contract can put assets at significant risk
Suppose a wallet delegates to a malicious sweeper contract.
If the contract's code can access the wallet's asset-management capabilities and there are no effective safeguards, the attacker may be able to try to transfer assets to a specified address.
So what needs to be examined is not just the delegation target's name, but:
What the delegation target is;
What its code actually does;
Who can call the relevant functions;
Whether it restricts the recipients and amounts of transfers;
Whether it contains dangerous paths that can be executed without authorization.
That's why EIP-7702 delegation should not be treated as equivalent to ordinary ERC-20 approval.
IV. Can a wallet delegate to multiple contracts?
This is an important question.
Suppose your wallet W first delegates to contract A, then later changes its delegation target to contract B.
Step one:
Wallet W
    |
    v
Delegation target A
Step two: Change the delegation target
Wallet W
    |
    v
Delegation target B
For a wallet on the same chain, a new EIP-7702 delegation can replace the previous one.
A does not permanently retain the ability to execute code through the old delegation just because it was once the delegation target.
But this does not mean that changing the delegation completely eliminates the risks associated with A.
We need to distinguish among three situations.
Situation one: A only has the old EIP-7702 delegation
If A can execute the relevant code only through W's current EIP-7702 delegation, then once W's delegation is replaced with B, A can no longer execute through the old delegation.
Situation two: A also has a separate token approval
Suppose you separately approved A to use 5000 USDT.
Later, you change the EIP-7702 delegation from A to B.
This separate USDT approval is not automatically revoked when the delegation changes.
As long as the token approval remains valid, A may still use the remaining allowance.
Changing the delegation target is not the same as revoking all token approvals.
Situation three: The attacker already has the wallet's private key
If the attacker already has W's private key, the situation is more serious.
The attacker may use the private key to sign new transactions or authorizations. Even if you clear the old delegation, that alone cannot restore the wallet's security.
A common misconception needs to be cleared up:
A smart contract cannot directly read your wallet's private key just because it has been delegated to.
Private keys are usually stored in a secure wallet environment and are not automatically exposed to a contract through EIP-7702 delegation.
The real risk is that malicious code can use the account's granted execution capabilities, or that the attacker has already obtained valid signing capabilities.
If your private key has been exposed, migrate your assets to a secure new wallet and check for any other approvals that are still active.
V. How can you check whether your wallet has an EIP-7702 delegation?
Once you understand the principles, the most practical question is:
How can I tell whether my wallet has already delegated to a contract?
For Ethereum mainnet, you can query a wallet's on-chain code through RPC.
1. What does an EIP-7702 delegation look like on-chain?
A standard EIP-7702 delegation marker consists of two parts:
0xef0100 + 20-byte delegation target address
Therefore, a standard delegation marker is 23 bytes long in total.
For example:
0xef0100
490aac77c960b0569c8e446ac7e12490bd44ca1d
The 0xef0100 prefix is the delegation marker, and the following 20 bytes are the delegation target address.
This is the format defined by the EIP-7702 specification.
2. Why can eth_getCode be used to check?
Ethereum provides the eth_getCode RPC method, which can query the on-chain code at an address in the state of a specified block.
If a wallet currently has a standard EIP-7702 delegation, the query result can be used to identify the delegation marker described above.
So the detection process can be simplified as follows:
Enter wallet address
    |
    v
Query on-chain code through RPC
    |
    v
Check whether the code is 23 bytes long
    |
    v
Check whether the first 3 bytes are ef0100
    |
    +---- Yes: parse the remaining 20 bytes
    |          Output the delegation target address
    |
    +---- No: no standard delegation marker found
3. Here's a simple detection program implemented in Go
I also built and tested this basic detection program myself.
The project uses Go and the go-ethereum client library to query a specified wallet's on-chain code through an Ethereum mainnet RPC.
The key code is as follows:
code, err := client.CodeAt(ctx, address, nil)
if err != nil {
	log.Fatalf("Failed to query wallet's on-chain code: %v", err)
}
fmt.Printf("On-chain code length: %d bytes\n", len(code))
fmt.Printf("On-chain code: 0x%x\n", code)
fmt.Println()
if len(code) == 23 && bytes.Equal(code[:3], delegationPrefix) {
	delegateAddress := common.BytesToAddress(code[3:])
	fmt.Println("Detection result: EIP-7702 delegation found")
	fmt.Printf("Current delegation target: %s\n", delegateAddress.Hex())
	fmt.Printf("Delegation target explorer: https://etherscan.io/address/%s\n", delegateAddress.Hex())
	fmt.Println()
	fmt.Println("Note: Detecting a delegation does not mean the target is necessarily malicious.")
	fmt.Println("We recommend further checking the delegation target's contract code, source, and security.")
	return
}
fmt.Println("Detection result: No standard EIP-7702 delegation marker found")
fmt.Println("Note: The on-chain code returned by this query does not match the standard delegation marker format.")
fmt.Println("This does not mean the wallet has no ERC-20 approvals or has never used EIP-7702.")
If a delegation is detected, the program outputs the current delegation target address; if not, it reports that no standard delegation marker was found.
========== EIP-7702 Delegation Check ==========
Network: Ethereum Mainnet
RPC: https://ethereum-rpc.publicnode.com
Wallet address: 0x1111111dD38A3739119BeA9fB2211A13e0306A8c
On-chain code length: 23 bytes
On-chain code: 0xef0100490aac77c960b0569c8e446ac7e12490bd44ca1d
Detection result: EIP-7702 delegation found
Current delegation target: 0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
Delegation target explorer: https://etherscan.io/address/0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
Note: Detecting a delegation does not mean the target is necessarily malicious.
We recommend further checking the delegation target's contract code, source, and security.
This program only identifies delegation relationships; it does not determine whether the target contract is malicious.
The query result reflects only the selected chain and the state at the time of the query. It cannot prove that the wallet has never used EIP-7702, nor can it replace separate checks on other chains.
4. Does detecting a delegation mean the wallet has been compromised?
Of course not.
A wallet may delegate to an audited contract to use smart-account features legitimately.
So after detecting a delegation, you still need to investigate further:
Is the delegation target the address you expected?
Has the target contract been audited?
Does the contract have dangerous functions that anyone can call?
Was the delegation set by you or by a trusted wallet service?
Does the wallet also have separate ERC-20 approvals?
Similarly, not detecting an EIP-7702 delegation does not mean the wallet is absolutely safe.
Traditional token approvals, private key exposure, and other types of signature-based authorization can all pose different risks.
VI. EIP-7702 delegation and traditional token approvals should be checked separately
To avoid confusion, we can compare the two types of checks side by side.
The key takeaway is:
The two checks complement each other and cannot replace one another.
VII. How can ordinary users reduce risks?
Not every user needs to avoid EIP-7702 entirely.
This technology can indeed improve the wallet experience. But for ordinary users, understanding what an authorization does is more important than blindly pursuing new features.
1. Don't sign authorizations you don't understand
If your wallet suddenly asks you to sign an authorization that clearly doesn't match the action you're taking—especially if it involves code delegation, account permissions, or complex transactions—pause before proceeding.
Don't assume every signature is safe just because a website says “claim a reward,” “verify your wallet,” or “claim free tokens.”
2. Carefully verify the delegation target
If your wallet prompts you to delegate your account to a contract, confirm that:
The address comes from an official source;
The contract is the implementation you expect;
There is a credible audit report;
The wallet clearly shows the delegation target and its actual effects.
Seeing the contract address alone isn't enough, because ordinary users usually can't directly determine whether the code is safe.
3. Check traditional token approvals regularly
If you've used DEXs, lending protocols, or other DeFi apps, check your token approvals regularly.
You can consider revoking approvals you no longer need, but keep in mind that revocation transactions also require gas.
Also, revoking token approvals is not the same as clearing an EIP-7702 delegation.
4. If you find an unknown delegation, don't proceed without checking
First confirm the current network and delegation target, then assess the risk.
If you confirm that the delegation was not authorized by you or is clearly malicious, prioritize protecting your remaining assets, and use trusted wallet tools to manage the delegation and other approvals.
If you have reason to suspect that your private key or signing system has been compromised, simply changing the delegation target is not enough to solve the problem.
5. For exchanges, risk controls should not rely on a single technology
Exchange hot wallets typically involve multiple components, including signing systems, transaction approvals, permission management, monitoring, and fund management.
To address risks related to EIP-7702, consider:
Setting stricter approval procedures for sensitive authorizations;
Restricting the operations that hot wallets can perform;
Monitoring unusual delegations and large fund movements;
Applying isolation and access controls to signing systems;
Adding independent verification before broadcasting critical transactions.
These measures are intended to reduce the likelihood of a failure at a single point causing major asset losses.
VIII. Summary: EIP-7702 is not the problem; authorization security is what matters
Back to the original question:
Why can an Ethereum wallet still face serious asset risks even when its private key has not been directly exposed in the traditional sense?
Account security depends not only on whether a private key has been exposed, but also on what permissions the user has granted, how those permissions are verified, and what the code with those permissions can actually do.
EIP-7702 gives traditional wallets new account capabilities, but it also introduces new security considerations.
There are three key takeaways:
First, EIP-7702 is a protocol feature in itself. Attacks that use this feature should not automatically be treated as protocol vulnerabilities.
Changing or clearing an EIP-7702 delegation does not automatically revoke all separate token approvals, nor can it resolve a private key that has already been exposed.
When assessing wallet security, you should consider the current delegation, traditional token approvals, and the security of the private key or signing system. No single check can prove that a wallet is absolutely safe.
Thanks for reading to the end. The most important thing is not to memorize every technical term, but to understand before every signature:
What am I authorizing?
Who will gain what capabilities?
If I change my mind, how can I revoke it?
Understanding these questions can help you better protect your digital assets while enjoying the convenience of blockchain technology.
Follow me so you don't miss the next market update.