Blockchain security firm Blockaid says Binance’s $6.3 billion hack may have been enabled by a compromise of the exchange’s wallet signing systems—potentially allowing attackers to get an otherwise-secure signer to approve transactions it should not. In Blockaid’s view, Ethereum’s EIP-7702 upgrade could also have made the theft easier by helping attackers bypass certain security checks.
Speaking to Cointelegraph, Blockaid co-founder and CEO Ido Ben-Natan argued that while EIP-7702 may have accelerated the attack, the breach likely did not rely on it exclusively. “The 7702 upgrade is a way to do this in one sweep and maybe a way to bypass some sort of checks they may have,” Ben-Natan said, adding that without EIP-7702 attackers might have needed multiple transactions to achieve the same result.
Key takeaways
- Blockaid believes compromised wallet signing infrastructure, rather than exposed private keys alone, may have allowed attackers to authorize unauthorized transfers.
- Ben-Natan suggested EIP-7702’s “one sweep” transaction model could have helped attackers bypass or simplify security checks compared with other approaches.
- Concerns about EIP-7702 were raised soon after its introduction, including reports of malicious delegations that could drain compromised wallets.
- Industry voices highlighted a key operational risk: even if control is regained, teams may overlook the need to revoke harmful EIP-7702 delegations.
- Ben-Natan warned that the same signing-system attack pattern could affect other exchanges, making transaction simulation an important defensive tool.
Why EIP-7702 entered the spotlight after Binance
EIP-7702 was introduced by Ethereum as part of the Pectra upgrade, with the protocol change released in May 2025. The improvement was designed to let ordinary wallets use certain smart-contract capabilities—such as bundling transactions and enabling sponsored gas fees—without requiring users to switch to a more complex contract-based workflow.
However, Blockaid’s analysis of the Binance incident connects those design goals to a new operational reality: if attackers can influence what a wallet authorizes, the “bundled” nature of EIP-7702 may reduce the number of steps needed to complete theft. Ben-Natan’s framing is that even if the signer is secure, the system can still be tricked into approving a transaction that carries malicious intent.
Earlier warnings about malicious EIP-7702 delegations
The Binance hack is not the first time EIP-7702 has been discussed in a security context. Within weeks of the upgrade’s rollout, crypto trading firm Wintermute reported that many early EIP-7702 delegations appeared to be directed toward malicious contracts, including arrangements aimed at automatically draining wallets that were compromised.
Later in 2025, the same concern resurfaced publicly when holders of World Liberty Financial (WLFI) tokens reported losses tied to malicious EIP-7702 delegations, according to earlier coverage from Cointelegraph. Community discussion also pointed to warnings that had been raised during debates around EIP-7702 before the Binance incident, including remarks attributed to Ethereum community member VEER.
While VEER’s commentary suggested the Binance attack looked broader than a single malicious signature, the takeaway highlighted by the community was consistent: EIP-7702 can act like a “sweep button” for attackers if authorization paths are abused.
From compromised systems to a signer approving the wrong thing
Binance has acknowledged the incident and confirmed it suffered a $6.3 billion hack—described as the largest in crypto history—and pledged to cover all losses. The exchange also stated that it identified additional breach points after initially suspecting a compromised laptop belonging to one of its engineers, as reflected in its public communications on X.
Blockaid’s Ben-Natan said the likely point of failure was not simply leaked private keys. Rather, he argued attackers may have reached Binance’s wallet-signing infrastructure through access to a compromised developer machine. In his view, the critical step was what happened at the signing layer: the system that should only sign legitimate transfers ended up signing an unauthorized transaction.
Binance CEO Richard Teng said investigators found no evidence that wallet private keys had leaked. Even so, the Blocakid narrative still fits a different threat model—one where attackers do not steal keys outright, but instead gain the ability to submit or craft transaction requests that a signing system mistakenly treats as valid.
Coinbase? No—another exchange voice in the incident analysis emphasized a related limitation of the debate. Ivo Georgiev, co-founder and CEO of Ethereum wallet provider Ambire, told Cointelegraph that EIP-7702 may not have been decisive because the attackers already had the ability to authorize transactions. But Georgiev warned about a distinct operational trap for exchanges: after engineers regain access, they might fail to revoke a malicious EIP-7702 delegation, leaving an opening for further abuse.
What defenders should watch next
Across the technical perspectives, the most practical theme is not only how attackers may have acted, but how defenders respond. Ben-Natan argued that signing-system compromise tactics threaten other exchanges as well, and he pointed to transaction simulation as a method to identify malicious requests before authorization is granted.
Looking ahead, exchanges and wallet operators may want to treat EIP-7702 delegations as something that requires explicit post-incident hygiene—not just a protocol feature. Readers should watch for more concrete technical disclosures from Binance about the exact breach chain, and for broader industry guidance on how teams should monitor, simulate, and revoke EIP-7702-related authorizations after regaining control.
https://www.cryptobreaking.com/eip-7702-not-a-binance/?utm_source=blogger%20&utm_medium=social_auto&utm_campaign=EIP-7702%20Not%20a%20Binance%20Hack%20Cause,%20Yet%20Could%20Have%20Worsened%20Losses%20
Comments
Post a Comment