Charles Hoskinson has amplified claims that a custom Ethereum EIP-7702 sweeper targeted Binance wallet “Binance 14.” If validly authorized, the reported code could have acted with the wallet’s authority. But the available accounts do not establish how that authorization was obtained or confirm the alleged asset movements.
- CyberSatoshi says the sweeper was tailored to Binance’s wallet infrastructure.
- DigitalToday, citing Blockaid, reported 50 authorization records in one transaction. That does not mean all 50 were accepted.
- The central unknown is how valid signing authority was generated, approved or obtained.
- The allegations alone do not show that EIP-7702 is broken.
Hoskinson, Cardano’s founder, shared CyberSatoshi’s technical analysis on X and warned: “Careful, there is some seriously dangerous code out there.” It is a serious warning about the power delegated code can carry. It does not independently confirm every detail in the analysis or prove a specific flaw in Ethereum.
What the alleged sweeper was designed to do
CyberSatoshi described reconstructed bytecode for an alleged sweeper targeting Binance 14. A sweeper is code designed to move assets out of a wallet. According to the analysis, this code processed tokens in a loop and could continue if an individual operation failed, including when a token was blacklisted or unresponsive. The supplied accounts do not independently verify the code or its behavior.
CyberSatoshi also claimed the code left exactly 1 ETH behind when moving the wallet’s native balance. The stated reason was to avoid a failure in Binance’s automated hot-wallet queue due to insufficient gas. That detail remains an attributed claim, not an established account of Binance’s systems.
The most consequential allegation concerns an external vault. CyberSatoshi said a custom execution function let Binance 14 call a vault holding $823 million in USDC, which allegedly recognized Binance 14 as its controller. The available reporting does not verify the vault’s balance, explain the precise permissions involved or establish that funds moved. The claim should not be read as proof that the entire stated balance was accessible or lost.
The Defiant reported that delegated code on Binance 14 could move the wallet’s assets and exercise ownership of another wallet, while noting that available records did not show how the permission was obtained. DigitalToday, citing on-chain analysis by Blockaid, reported that 50 EIP-7702 authorization records targeting Binance 14 were bundled into a transaction, with one matching the required nonce. That supports a reported delegation event, but does not independently confirm every detail of CyberSatoshi’s reconstruction or the eventual outcome.
What EIP-7702 permits
EIP-7702 lets an externally owned account, or EOA, authorize a delegation to code at another address. An EOA is the familiar kind of Ethereum account normally controlled through private-key signatures. The signed authorization installs the delegation, and the code runs when the account is subsequently called. This can support features such as transaction batching or having another party pay fees, but it also changes what code can do in the account’s context.
The specification warns that delegated code has unrestricted access to the account. In practical terms, the code may be able to act as that account, including moving assets if its logic permits. Not every delegation grants the same powers. The code’s behavior and Ethereum’s execution rules determine what actions it can take.
A delegation requires a valid cryptographic authorization that identifies a chain, a delegate address and a nonce, along with a signature. The protocol checks the authorization before setting the delegation. An outside party cannot simply assign arbitrary code to someone else’s account without valid authorization. So the key question here is not only what the alleged code could do, but how valid signing authority was obtained or approved.
The EIP allows multiple authorizations in one transaction. They are processed in order. Each valid authorization advances the authorizing account’s nonce, and later entries can become valid if their nonces match. The last valid authorization determines the resulting delegate. The transaction sender’s nonce is incremented before the authorization list is processed, so the sender’s relationship to the authorizing account matters when interpreting the sequence.
DigitalToday’s account says one of the reported 50 records matched the required nonce. CyberSatoshi described the sequence as an attempt to catch Binance 14 as its transaction count changed, but that explanation has not been independently established. The reported count should not be mistaken for 50 successful authorizations.
Delegation also persists after the transaction that installs it. Under the specification, a later execution failure does not undo delegation indicators already processed. A valid authorization pointing to the zero address can clear an account’s delegation. These mechanics make the approval process and review of delegated code critical safeguards, not administrative details.
The authorization problem remains unresolved
The available reporting does not establish whether a private key was stolen, a signing system was compromised, an approval process was abused or some other route was involved. DigitalToday reported that Arkham CEO Miguel Morel said there was not enough information to determine whether private-key theft or an infrastructure breach caused the reported activity.
DigitalToday also relayed early possibilities raised by Ben-Natan, including compromised devices or movement within an exchange network. These were possibilities, not confirmed findings. The same report said Blockaid observed preparatory features resembling activity associated with North Korea-linked cyberattack groups, while stressing that this was not definitive attribution. Similarities can inform an investigation, but they do not identify an attacker.
CyberSatoshi’s claim that Binance’s defenses would otherwise have stopped the operation after three transactions is a counterfactual assessment, not a demonstrated fact. The reporting available here does not include a complete forensic account or establish how Binance’s safeguards behaved.
These distinctions matter. If confirmed, a valid authorization would show that delegation was installed. It would not, by itself, prove how the authorization was obtained, what the code ultimately did or how much, if anything, was lost. Nor would it alone demonstrate a protocol vulnerability. The broader security lesson is that systems for creating, reviewing and approving signatures can be as consequential as the keys themselves.
Key questions and answers
-
Can anyone use EIP-7702 to install code on another person’s wallet?
No. A valid signed authorization is required. How the alleged authority in this case was obtained or approved remains unknown.
-
Can delegated code move a wallet’s assets?
It may be able to, depending on the code’s logic and the actions available to it in the account’s context. The scope of the alleged sweeper’s powers has not been independently established.
-
Do the 50 reported authorizations mean 50 approvals succeeded?
No. DigitalToday reported 50 authorization records bundled into one transaction and said one matched the required nonce. The account does not establish that all 50 were valid or processed.
-
Does this prove EIP-7702 is broken?
No. The specification requires valid authorization, and the available information does not identify a protocol flaw. The unresolved issue is how signing authority was allegedly obtained or used.
-
Are the $823 million vault claim and the 1 ETH detail confirmed?
No. Both are claims attributed to CyberSatoshi. The available reporting does not verify the vault balance, the extent of any access or whether funds moved.
EIP-7702 offers useful flexibility, but delegated execution also gives approved code meaningful authority. If the reported activity is confirmed, the clearest lesson will depend on evidence that is still missing: what authorized the delegation, how that authorization passed and what the code actually did. Until then, Hoskinson’s warning is worth heeding, but it is not a verdict on what happened. EIP-7702’s account-abstraction capabilities offer useful flexibility, but do not remove the need for careful authorization.
