Hoskinson flags Binance sweeper code as EIP-7702 debate grows

Cardano founder Charles Hoskinson has warned about “seriously dangerous code” while sharing an analysis that blames Ethereum’s EIP-7702 delegation feature for helping attackers rapidly empty a Binance hot wallet.

In his X post, Hoskinson wrote, “Careful, there is some seriously dangerous code out there,” above a breakdown published by CyberSatoshi.

The post he shared described reconstructed bytecode for an alleged Binance EIP-7702 sweeper, arguing that the contract was tailored to the exchange’s operations. Hoskinson’s accompanying message did not identify a specific protocol flaw or explain which part of the analysis he endorsed.

CyberSatoshi’s account places two security questions alongside each other. One concerns how an attacker obtained permission to act for the wallet. The other concerns what Ethereum’s delegation feature allowed the attacker to do after obtaining that permission.

Binance sweeper allegedly worked around wallet safeguards

According to CyberSatoshi’s breakdown, the reconstructed contract left exactly 1 ETH in the wallet when sweeping its native balance. The poster argued that this prevented Binance’s automated hot-wallet queue from failing over insufficient gas and raising alarms.

The analysis described a token-processing loop that checked balances through low-level calls and continued when individual operations failed. CyberSatoshi said this allowed the sweeper to keep processing assets even if a blacklisted or otherwise unresponsive token could not be transferred.

A custom execution function allegedly let the compromised wallet call an external vault holding $823 million in USDC. In the poster’s explanation, the vault recognized Binance 14 as its controller, allowing calls made through that wallet to reach funds outside its immediate balance.

CyberSatoshi characterized the contract as purpose-built for Binance’s architecture. The claims about its effect on internal alerts and treasury systems remain the poster’s explanation of how the operation worked.

EIP-7702 requires signed permission to delegate

Ethereum’s EIP-7702 specification describes a transaction type that lets an externally owned account delegate execution to code deployed at another address.

An externally owned account normally operates through signatures from its private key. Delegation lets it execute smart-contract logic in its own account context, supporting features such as batching several operations into one transaction and allowing another account to pay transaction fees.

Each authorization identifies a chain, a delegate address, and a nonce, together with a cryptographic signature. The protocol recovers the authorizing account from that signature and checks its nonce before applying the delegation.

CyberSatoshi acknowledged this requirement, saying the alleged attack needed either the raw private key or unrestricted signing access to Binance 14’s security infrastructure.

The specification does not establish how any Binance signing credentials were obtained. Its signature requirement does establish that delegation cannot simply be assigned to an arbitrary victim account without valid authorization.

Ethereum’s nonce rules explain the alleged batch

CyberSatoshi claimed the attacker submitted 50 pre-signed authorizations covering consecutive nonces to catch Binance 14 while its transaction count was changing.

The specification processes authorizations in order. When an authorization fails a check, processing continues with the next entry. A valid entry sets the delegation and increments the authorizing account’s nonce.

Successive authorizations for the same account can therefore become valid as that nonce advances. Where several valid entries exist, the last valid delegation determines the code address used.

This is more specific than a batch in which only one authorization can take effect. The rules permit multiple consecutive entries to succeed, depending on the account’s starting nonce and the signatures supplied.

CyberSatoshi argued that delegation compressed the asset transfers into a single operation, reducing the time available for intervention. The separate assertion that exchange defenses would otherwise have stopped the theft after three transactions is the poster’s counterfactual assessment.

Ethereum’s design document spells out delegation risks

The EIP’s authors explicitly warn that authorized code has unrestricted access to the account and must be closely audited by the wallet.

Its security section lists protections delegate contracts need, including replay prevention and signatures covering transaction value, gas, destination, and call data. Poorly implemented delegation can leave an attacker with nearly complete control over the signing account.

Delegation persists beyond the transaction that installs it. The specification further states that an execution failure does not roll back delegation indicators already processed.

To remove delegation, the protocol permits a valid authorization pointing to the zero address, which clears the account’s delegation code.