Masato/Technology & Life
繁中

Behind Binance's $6.3 Billion Asset Theft: How Can a Wallet Suddenly Start Executing Code?

Starting from Binance's $6.3 billion asset theft, this article explains how an ordinary Ethereum wallet can suddenly execute code and how EIP-7702 changes wallet behavior and security boundaries.

By

Binance $6.3 billion asset incident and EIP-7702 cover

The Binance 14 Incident

In the early hours of October 30, 2026, a series of unusual fund movements began appearing on-chain.

Several wallets related to Binance suddenly started moving large amounts of assets outward. Abnormal outflows appeared across Bitcoin, Ethereum, Tron, Solana, and other chains, at a scale that was difficult to dismiss as routine treasury movement. The major Ethereum transfer alone later included about 167,464 ETH, roughly $1.615 billion USDT, plus dozens of ERC-20 tokens. The market quickly began tracing addresses, inspecting transactions, and comparing fund flows. Binance also publicly said it was investigating a security incident and temporarily suspended some deposit and withdrawal services.

On Ethereum, however, one detail was especially strange.

The familiar Binance 14 hot wallet did not immediately send a giant “move the money” transaction before the assets disappeared.

Something less conspicuous happened first.

The address first underwent an account authorization change related to EIP-7702.

A few minutes later came the transactions everyone noticed: large amounts of ETH, USDT, and other tokens began leaving the wallet.

If you only watch the final large transfers, you see the result. The change that really deserves attention happened earlier.

That is what interests me most about this incident.

In the past, when we saw an ordinary Ethereum wallet address, the intuitive model was usually “one private key controls these assets.” But in this incident, Binance 14 underwent an EIP-7702-related change in account capability before the assets were moved.

That turned an EIP that once felt like something only found in protocol documents into a very practical question:

If an ordinary wallet can hand its execution capability to code, can we still understand it using the old mental model?

The incident quickly pushed EIP-7702 from a relatively obscure protocol-layer Ethereum feature into the center of security discussions.

One point needs to be clear: EIP-7702 itself is not a vulnerability, and it is not the “attack program” used in this incident. It is an important Ethereum upgrade designed to improve account usability. This event simply demonstrated that once a normal wallet can hand execution capability to code, the security boundary around signatures and authorization changes as well.

So I am not going to reconstruct the entire Binance incident here. I want to use it as an example to explain what EIP-7702 actually changes.

Start With the Basics: How Did a Normal Wallet Work Before?

Ethereum accounts can be roughly divided into two categories:

  1. EOA (Externally Owned Account)
  2. Contract Account

The addresses we normally use through MetaMask, hardware wallets, or private keys are usually EOAs: accounts directly controlled by a private key.

The traditional EOA model is very simple:

Private Key
    ↓
Sign Transaction
    ↓
EOA sends transaction

The EOA itself has no code.

That means more advanced features such as:

  • executing multiple operations at once
  • letting a third party pay Gas
  • setting a daily transfer limit
  • creating a session key
  • adding recovery mechanisms
  • assigning different permissions to different operations

normally require a Smart Contract Wallet or Account Abstraction.

EIP-7702 is designed to let existing EOAs gradually gain Smart Account capabilities without changing addresses.

It entered Ethereum mainnet with the Pectra upgrade on May 7, 2025.

What Does EIP-7702 Actually Do?

The shortest explanation is:

EIP-7702 allows an EOA to say: “From now on, use the code of this deployed contract as my execution logic.”

EIP-7702 adds a Type 4 transaction.

A transaction can include an authorization_list, and each authorization contains:

[chain_id, address, nonce, y_parity, r, s]

Here, address is the deployed code address being delegated to, while nonce restricts the authorization to a specific account nonce. y_parity / r / s are the authority’s signature over the authorization.

After successful verification, Ethereum writes a delegation indicator to the EOA that points to the chosen contract address.

Conceptually:

Your EOA
0xABC...

Before:
no code

After EIP-7702 delegation:

0xABC...
   ↓
delegate to
   ↓
contract code at 0x123...

The key point is:

The address does not change. The private key is still the same key. The assets remain in the same EOA.

What changes is that when the account is called, it can execute another contract’s code. The delegation persists until a new authorization replaces it or clears it.

That gives an otherwise simple EOA programmable-account capabilities.

Why Is This Useful?

Because many UX features that were previously impossible, or required moving to a Smart Contract Wallet, can now appear on an existing address.

For example, a DEX operation used to look like this:

Approve USDC
↓
wait for confirmation
↓
Swap USDC → ETH

EIP-7702 can let a wallet batch multiple operations together.

The user may see only:

Swap USDC → ETH

while approve + swap happen together underneath.

Another important use is Gas Sponsorship.

In theory:

User has no ETH
↓
App / Relayer pays Gas
↓
User still completes the on-chain operation

You can go further and implement privilege de-escalation.

For example, a delegate contract could be designed like this:

Main private key
├── can do anything
│
└── Session Key
    ├── can spend at most 100 USDC per day
    ├── can only use one specific DEX
    └── expires after 24 hours

For wallet UX, games, Agents, and payment systems, these capabilities are extremely useful.

So EIP-7702 is not inherently a “dangerous feature.” It solves a user-experience problem.

It addresses a long-standing Ethereum question:

We already have a huge number of users living in the EOA world. How can those existing accounts gradually gain Smart Account capabilities?

But the Security Model Changes Too

The risk comes from the same capability.

The old intuitive wallet-security model was:

Do not leak your Seed Phrase
Do not leak your Private Key
Do not blindly sign Transfer / Approve

With EIP-7702, one more rule is required:

Do not delegate your account to code you do not understand

That is because EIP-7702 delegation is not an ordinary ERC-20 approve.

An ERC-20 approve usually means:

I allow this spender to use up to this amount of this token.

EIP-7702 delegation is closer to:

I allow this code to become my account’s execution logic.

Those are completely different permission levels.

The official EIP-7702 specification even warns that a badly written delegate contract can let an attacker obtain near-complete control over the signer EOA.

That is not an EIP-7702 bug. It is the other side of programmable-account capability.

The more powerful the capability, the more the signer needs to understand before authorizing it.

EIP-7702 Does Not Give Your Private Key to a Contract

This is an easy point to misunderstand.

Delegation does not mean:

Give Private Key to Contract

The private key still belongs only to the EOA controller.

A more accurate model is:

Private Key
   ↓
sign an authorization
   ↓
allow the EOA to use specified contract code

The EOA’s private key also retains ultimate control. It can use a new authorization to replace the delegation or clear it.

So EIP-7702 does not turn an EOA into a conventionally deployed contract.

It is more like:

Adding an execution entry point to an existing EOA that can point to implementation code.

For Ordinary Users, the Real Change Is the Mental Model of Signing

This may be the most important part of EIP-7702 for ordinary users.

Web3 has spent years teaching users:

Sign Message is not the same as Send Transaction.

Now there is another kind of authorization.

On the surface, it may not directly show:

Transfer 1000 ETH

Yet its actual effect can be larger than a single transfer.

A future wallet cannot simply show:

Sign EIP-7702 Authorization?

Contract:
0x63e8...

and then present a Confirm button.

A reasonable wallet UI should answer questions such as:

  • Who are you delegating your account to?
  • Is the code verified?
  • Has it been audited?
  • What operations can it execute?
  • Can it move ETH?
  • Can it move ERC-20 tokens?
  • Does it perform additional signature validation?
  • Does it enforce limits?
  • How long does the delegation persist?
  • How do you revoke it?

The official EIP-7702 documentation explicitly recommends that wallets be highly cautious with third-party delegation. The specification uses strong language: code referenced by an authorization has unrestricted access to the account.

In other words, a wallet cannot treat this as a normal authorization where the user pastes an address and clicks sign.

The reason is simple:

An ordinary user cannot determine whether a contract is safe just by looking at its address.

What Matters Most to Me About EIP-7702 Is This Shift

We used to think of Ethereum accounts roughly like this:

EOA = simple account controlled by a private key
Contract = account that can execute code

After EIP-7702, that boundary becomes less clear.

An address can retain:

  • its original EOA private key
  • its original address
  • its original assets
  • its original nonce

while also gaining:

  • programmable execution
  • batch
  • sponsorship
  • session key
  • custom permissions
  • recovery logic

This is an important transitional design in Ethereum’s path toward Account Abstraction. Since Pectra activated on May 7, 2025, this is no longer just a research proposal. It is a capability that exists in Ethereum mainnet’s account model.

It means a “smart account” does not necessarily need to begin with a new address.

But it also means:

We can no longer see an EOA address and assume it is simply an account directly controlled by a private key.

For on-chain analysis, security monitoring, transaction simulation, and even risk control, there is now an extra question to ask:

Does this EOA currently have an EIP-7702 delegation? Which code does it delegate to?

That will likely become a standard check over time.

Conclusion

What I find most interesting about EIP-7702 is that it shows the next step in both Ethereum UX and Ethereum’s security model.

It lets existing EOAs gain Smart Account capabilities, lowers usability barriers, and makes features such as batching, gas sponsorship, and session keys easier to adopt.

But it also makes “what exactly did I sign?” more important than before.

In the past, the risk from a dangerous signature was easier to think about as one approve or one transfer.

Now a dangerous delegation may change how the account executes code from that point onward.

So if you see an EIP-7702 Authorization in a wallet, do not treat it as just another Sign Message.

The question you should really ask is:

Am I handing my account’s execution authority to another piece of code?

That may become one of the most important new security instincts in the EIP-7702 era.

References

Share this post:
Share this post on WhatsappShare this post on FacebookShare this post on XShare this post on TelegramShare this post on PinterestShare this post via email
Previous Post
What If AI Could Research Blockchains on Its Own? I Built It a Local Base Node