Hoskinson Shares Binance Sweeper Analysis Citing 50 EIP-7702 Signatures

Hoskinson's Sweeper Warning

Cardano founder Charles Hoskinson has waded into a dispute over Ethereum's (ETH) EIP-7702 delegation feature, sharing an analysis that blames the feature for helping an attacker rapidly empty a Binance hot wallet and warning of “seriously dangerous code.” The Ethereum specification takes a different view: it states that delegation cannot be attached to an account without a valid cryptographic signature, and it does not explain how any signing credentials were obtained. In an X post on Friday, Hoskinson wrote, “Careful, there is some seriously dangerous code out there,” above a breakdown from the pseudonymous analyst CyberSatoshi. The post reconstructs bytecode for an alleged EIP-7702 sweeper and argues the contract was built specifically for Binance's wallet infrastructure. Hoskinson's message stopped short of naming a specific flaw and did not say which part of the analysis he endorsed. CyberSatoshi's reconstruction is more granular. The alleged sweeper left exactly 1 ETH in the wallet when it swept the native balance, a choice the poster said would keep Binance's automated hot-wallet queue from failing over insufficient gas and raising alarms. A token-processing loop used low-level calls to check balances and kept running when individual transfers failed, letting the contract move assets even where a blacklisted token blocked one operation. The analysis's widest claim concerns reach: a custom execution function allegedly let the compromised wallet, identified as Binance 14, call an external vault holding $823 million in USDC, effectively reaching funds in the exchange's Ethereum treasury beyond its own balance. Our related coverage records an Aave oracle gap after the Binance hack that netted one arbitrageur $3.47 million; Binance hot wallets separately drew attention when they moved $2 billion in crypto to a Tornado Cash-funded address. The poster characterized the contract as purpose-built for Binance's architecture; its account of internal alerts and treasury defenses remains its own explanation. No rebuttal from Ethereum developers or from Binance appears in the material published so far.

50 Authorizations and Nonce Rules

Under EIP-7702, an externally owned account, which normally operates through signatures from its private key, can delegate execution to code deployed at another address. The design supports batching several operations into one transaction and letting another account pay fees, patterns used by wallet providers and layer 2 networks. 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 bar, saying the alleged attack needed either the raw private key or unrestricted signing access to Binance 14's security infrastructure. Wallets that permit blind signing, approving data without seeing its full contents, sit inside that audit exposure. The claimed batch rests on nonce arithmetic: 50 pre-signed authorizations covered consecutive nonces, letting the attacker catch Binance 14 while its transaction count was changing. The specification processes authorizations in order, moves on when one fails a check, and increments the account's nonce on each valid entry, so successive authorizations can become valid as that nonce advances; where several exist, the last valid delegation sets the code address used. CyberSatoshi argued that delegation compressed the asset transfers into a single operation, shrinking the window for intervention, and that exchange defenses would otherwise have stopped the theft after three transactions, a counterfactual the poster presents as its own assessment. The specification's security section is direct: authorized code gets unrestricted access to the account and must be closely audited by the wallet, with protections including replay prevention and signatures covering value, gas, destination and call data. Delegation persists beyond the transaction that installs it, failed executions do not undo delegation indicators that were already processed, and only a valid authorization pointing to the zero address clears it. The breakdown and the on-chain authorization trail can be checked directly; our guide to reading the Ethereum blockchain like a pro walks through it.

The record leaves two readings standing. Hoskinson's post treats the delegation feature as the dangerous element, while the specification's own text shows the feature cannot be attached to an account without a valid signature, and CyberSatoshi's account concedes that point. What would settle the matter is disclosure of how signing access to Binance 14 was obtained, a fact neither the EIP document nor the reconstructed analysis establishes. Until that is confirmed, the argument between the warning and the specification stands unresolved, and neither side's summary closes it.