Is my money on Binance safe? What the study finding above 63% means

Where the 63% figure comes from

The study, “Revealing the Dark Side of Smart Accounts: An Empirical Study of EIP-7702 Incurred Risks in Blockchain Ecosystem,” appears in the proceedings of the 35th USENIX Security Symposium. The conference record dates it to August 2026. Its authors include researchers from the Hong Kong University of Science and Technology, Nankai University, Sun Yat-sen University and Lingnan University. It therefore predates the suspected Binance incident now being discussed. The conference record includes the authors and publication details.

The researchers describe tools combining large-scale transaction analysis with static analysis across contracts. They applied those tools to seven blockchains supporting EIP-7702 and detected 924 malicious contract accounts. Their abstract says over 63% of EIP-7702 authorization transactions were associated with malicious attacks targeting externally owned accounts. It also says nearly half of the most frequently authorized contracts were controlled by attackers. These are findings about the population and activity studied, with different denominators for transactions and contracts. The original abstract sets out both findings.

A transaction share cannot tell a Binance customer the probability that their own account has been compromised. Repeated attacker activity can appear in a transaction count; an individual wallet, a contract and an exchange customer are different units. The abstract does not supply a current Binance customer-risk percentage. Treating 63% as such a percentage would replace the researchers' actual measurement with a claim they did not make.

There is also a time distinction. Odaily's October 30 item is a fresh report drawing attention to earlier research. Its publication time does not make the underlying study a measurement of today's Binance wallets. The useful contribution is a documented security mechanism and evidence that malicious use has occurred, rather than a newly calculated incident loss. Odaily's item explicitly refers to the USENIX research.

What an EIP-7702 authorization changes

The Ethereum specification describes EIP-7702 as a way for externally owned accounts to set code while preserving their addresses. The account points to code that executes in its context. The proposal supports functions such as batching operations and having another account sponsor transaction costs. Those features explain why a wallet may offer a smart-account upgrade in an otherwise ordinary transaction workflow. The specification explains the mechanism and intended uses.

The security question is which code receives that authority. The specification says code selected by an authorization has unrestricted access to the account and should be closely audited by the wallet. Its security section warns that a poorly implemented delegate can give a malicious actor near-complete control over the signer's account. A familiar address on the wallet screen therefore does not, by itself, establish that its execution behavior is unchanged. Ethereum's specification describes this trust boundary.

This changes how a reader should assess a signature prompt. The text saying what the signature authorizes matters alongside the amount displayed. A request presented as an account upgrade or sponsored transaction still deserves an explanation of the selected delegate and the authority involved. If that explanation is unavailable, pause the request and use the wallet provider's own support route. This is a practical reading of the specification's warning about authorizing code, rather than a claim that every smart-account upgrade is malicious.

The study classifies risks into attacks targeting externally owned accounts, attacks targeting contract accounts and composite attacks. Its findings cover a broader security problem than one exchange address. The authors' categories are useful for keeping the scope of an incident claim precise: identifying a dangerous authorization design does not identify who obtained a signature in a particular case. The study abstract describes its classification.

A failed transaction can leave an authorization in place

One specification detail deserves attention when checking a wallet history. EIP-7702 processes authorization entries before the execution portion of a transaction. It explicitly states that processed delegation indicators are not rolled back when execution fails, including a revert. A transaction marked failed is therefore insufficient evidence, on its own, that no delegation change occurred. See the specification's authorization-processing rules.

For a self-custody user, the next question is whether the wallet can show the account's current delegation state. Save the transaction reference and ask the wallet provider to explain that state through its official support interface. A red failure label and the current code authorization answer different questions. The transaction's displayed outcome should be read together with the authorization information available for the address.

The specification also defines a way to clear an account's code through a valid authorization pointing to the zero address. It separately warns that changing delegation is a security-critical operation and discusses storage compatibility when moving between delegate contracts. These provisions are reasons to use a documented wallet workflow. They do not justify signing a revocation request supplied by an unknown direct message or pasting an unreviewed transaction into a wallet. Ethereum documents clearing and migration considerations.

Which checks belong to the exchange customer

A Binance account balance and a self-custody address should be handled as separate records. An ordinary exchange customer cannot revoke the delegation of an exchange-operated hot wallet from their account settings. A request claiming to let a customer repair Binance's hot-wallet authorization by connecting their own wallet should be treated as a reason to stop and verify the request through the exchange's official channels.

For a pending Binance withdrawal, save the asset, selected network, receiving address and the status shown in your account. Keep any transaction identifier with that record, then ask Binance support about that specific transfer. If the account still shows pending, preserve that status when describing the problem; a public wallet balance cannot establish that your transfer completed.

A reserve screenshot also needs its own timestamp and scope before it can answer a useful question. It should not be substituted for the status of a pending transfer or for evidence about an address's delegation. This follows from the questions being asked: holdings at a stated point in time, transaction processing and code authorization each describe a different part of the problem. A current reserve ratio or solvency conclusion would require additional evidence.

Keep requests about supposed “Binance compensation” out of the transaction workflow. Do not connect a wallet or sign an authorization from a compensation link received in a direct message. Open the exchange through your established app or saved route and check its own notices. That instruction is preventive; it does not assert that a particular compensation program exists or has been verified.

Market pressure does not prove a wallet mechanism

NexuAlpha's liquidation board, updated at 12:37 SGT on October 30, displayed approximately $770 million of observed liquidations over 24 hours across Binance and OKX. Its displayed long and short totals were approximately $649 million and $121 million. The four-hour panel showed $83.7 million. Those figures describe leveraged positions force-closed in the board's coverage, rather than assets removed from an exchange wallet.

The same snapshot showed about $11.1 million in the one-hour panel, including $9.71 million of shorts and $1.44 million of longs. Comparing a one-hour panel with a 24-hour panel requires keeping their windows attached. A short-heavy recent hour can coexist with a long-heavy day; neither split establishes why an authorization was signed. The board provides the timestamp and separate windows.

On the funding-rate board at 12:37 SGT, the displayed ETH rate per period was +0.0012% for Binance and −0.0088% for OKX. Funding describes payments between long and short positions under the contracts' funding mechanism. These two observations can help someone review an existing derivatives position, but they do not identify an attacker, establish exchange reserves or confirm that withdrawals have resumed.

A reader with both an open position and a pending transfer consequently has two tasks. Review the position using its own margin and settlement information, and track the transfer using its own account record. The market boards offer context for the first task. The protocol specification explains what delegation can do. Combining the two into a claim that the incident caused every observed liquidation would go beyond these observations.

Quick answers

Does the study say 63% of Binance users are at risk?

No. Its reported share concerns EIP-7702 authorization transactions in the researchers' dataset. Its abstract does not provide a percentage of compromised Binance accounts or customer balances. The original study defines the measured activity.

Has EIP-7702 been confirmed as the Binance incident's cause?

Odaily's analysis and the underlying protocol and research sources explain why delegation is being discussed, but they do not establish Binance's confirmation of that cause. Describe the outflow as suspected and keep the proposed method attributed to analysts. Odaily presents the connection in its report.

Does a failed transaction prove that delegation was cancelled?

No. EIP-7702 explicitly says processed delegation indicators survive failed execution. For a self-custody address, ask the wallet provider how to inspect the current delegation state before acting on a recovery request. The specification gives the relevant processing rule.

What remains unverified?

The available sources do not establish a final incident loss, a confirmed intrusion path, the current authorization of a Binance wallet, or the outcome of an individual customer's transfer. An exchange statement or a current address-specific record would answer a narrower question than the historical study can. Keep the transfer reference and the wallet authorization question separate when seeking that evidence.