Cardano founder Charles Hoskinson has highlighted security concerns surrounding Ethereum’s EIP-7702 (Ethereum Improvement Proposal 7702) after researchers alleged that the delegation feature may have contributed to the scale and speed of a major Binance security breach.

Recent reporting has put the value of the crypto assets lost by Binance at about $6.3 billion. Investigators have not yet established exactly how the attackers obtained access to the signing systems involved in the incident.

Hoskinson Highlights Binance Sweeper Code

Hoskinson shared a technical analysis by researcher CyberSatoshi on October 30, 2026, with the warning: “Careful, there is some seriously dangerous code out there.”

Careful, there is some seriously dangerous code out there.

— Charles Hoskinson (@IOHK_Charles), October 30, 2026

X post: https://x.com/IOHK_Charles/status/2116246648716411341?ref_src=twsrc%5Etfw

The analysis identified the Binance wallet known as “Binance 14” as the target of a custom sweeper contract — code built to automatically transfer assets out of a targeted address as they become available. When moving ETH from the wallet, the contract allegedly left exactly 1 ETH behind. According to the analysis, this may have allowed Binance’s automated transaction systems to continue operating while assets were being removed.

The contract was also designed to continue processing token transfers even when individual transfers failed, rather than allowing one unsuccessful or blocked transaction to stop the broader operation.

$823M USDC Vault Allegedly Within Reach

CyberSatoshi said the compromised execution function could also act on an external vault holding approximately $823 million in USDC, a dollar-pegged stablecoin.

In a post on October 30, the researcher described reconstructed bytecode from the Binance EIP-7702 sweeper, identified as 0x63e8…6fae, as custom-engineered for Binance 14 rather than a generic draining tool.

The analysis said the contract:

• Left exactly 1 ether behind when sweeping ETH, using bal – 1 ether, so Binance’s automated hot-wallet queue would not encounter a gas-related error or trigger an alarm.
• Used raw staticcall and continue loops, along with the custom SweepItemFailed error code, so that a broken or blacklisted ERC-20 token would not revert the broader $6 billion batch.
• Included a custom callExecute function that could impersonate Binance 14 as the controller of an external vault holding $823 million in USDC.

Hot wallets are internet-connected wallets that exchanges use to process ongoing deposits and withdrawals, and automated queues like the one described rely on them executing without errors.

The analysis included the comment: “robberies could be prevented if getaway cars were slower.” It argued that EIP-7702 could not by itself be blamed for the breach but may have accelerated the operation.

According to CyberSatoshi, without EIP-7702, draining 64 tokens and the external $823 million vault from a live exchange hot wallet would have required managing changing nonces across more than 70 transactions — under Ethereum’s rules, each transaction from an account must carry a sequential nonce, so transfers from a single address cannot be bundled into one submission. The researcher said defense systems might have stopped the operation after the third transaction.

With EIP-7702, the attackers allegedly used 50 consecutive nonces in a single type-4 payload — the transaction format EIP-7702 introduced to carry a list of authorizations — converted an externally owned account into a custom proxy, and swept billions of dollars in one block. The post described the operation as “Surgical state-sponsored engineering” and said, “Ethereum core devs built the ultimate getaway car.”

The researcher also shared the following code fragment as an example of the mechanism:

if (bal > 1 ether) {  bal – 1 ether}(“”); }

Reading the reconstructed bytecode of the Binance EIP-7702 sweeper (0x63e8…6fae) is wild. This wasn’t a generic drainer. It was custom-engineered for Binance 14’s architecture:

– Leaves exactly 1 ether behind (bal – 1 ether) when sweeping ETH so Binance’s automated hot wallet queue wouldn’t error on gas and trip alarms.
– Uses raw staticcall + continue loops with custom error codes (SweepItemFailed) so one bricked or blacklisted ERC-20 wouldn’t revert the $6B batch.
– Includes a custom callExecute function to impersonate Binance 14 as controller of an external vault holding $823M in USDC.

They leave a comment: “robberies could be prevented if getaway cars were slower.” You can’t fully blame EIP-7702, but it sped up the attack. Without 7702, draining 64 tokens plus an external $823M vault from a live exchange hot wallet meant fighting moving nonces across 70+ transactions. Defense systems would’ve killed it after tx #3. With 7702, Lazarus sprayed 50 consecutive nonces in one type-4 payload, turned an EOA into a custom proxy, and atomically swept billions in a single block. Ethereum core devs built the ultimate getaway car. Surgical state-sponsored engineering. This could be etched onchain: if (bal > 1 ether) { bal – 1 ether}(“”); }

— CyberSatoshi 𓆙 (@XBToshi), October 30, 2026

X post: https://x.com/XBToshi/status/2116097368705937613?ref_src=twsrc%5Etfw

The analysis further alleged that Binance 14 had information about the external vault and that delegated code could act using an authorization already granted by the wallet. These claims are based on the researcher’s reconstruction and have not been confirmed by Binance. Independent researchers have reportedly observed an EIP-7702 transaction containing 50 authorizations signed by Binance 14.

EIP-7702 Can Accelerate Execution but Cannot Forge Authorization

EIP-7702, which was activated as part of Ethereum’s Pectra upgrade in May 2025, allows an externally owned account, or EOA, to delegate execution to smart-contract code. An authorization includes a chain ID, the delegate’s address, a nonce, and a signature. Ethereum verifies the signature before applying the delegation.

That signature requirement means EIP-7702 does not allow an attacker to arbitrarily take over a Binance wallet and load malicious code without first obtaining valid authorization. CyberSatoshi’s team said the attacker would still need to obtain the relevant private keys or gain access to Binance’s signing systems.

Once delegation has been validly authorized, however, the delegated code can have broad execution capabilities because it runs in the context of the account. This distinction is central to the Binance investigation: EIP-7702 may have increased the speed and volume of the transfers, but it did not independently create the signing authorization.

Ethereum Documentation Warns of Delegation Risks

Ethereum’s official EIP-7702 documentation contains a prominent warning that delegated code can receive full access to an account and should be carefully audited. The specification also notes that poorly designed delegate contracts could allow a malicious party to control the signer’s EOA with few limitations.

Those warnings apply to delegation in general, not only to this incident: any account that signs a valid authorization takes on the risk of whatever its delegate code is built to do.

The Binance incident therefore raises two separate security questions. The first is how the attackers obtained a valid signing key or otherwise gained access to Binance’s signing systems. The second is how the use of delegated code affected the speed and volume of asset transfers after that authorization was obtained.

Hoskinson’s warning focuses primarily on the second issue, while resolving the first remains central to determining the cause of the breach.

Original source: https://www.cryptoninjas.net/news/hoskinson-flags-dangerous-eip-7702-code-after-binances-6-3b-crypto-breach/