Blockaid: EIP-7702 Didn't Cause Binance's $6.3B Hack but Amplified It

Binance's $6.3 billion hack was enabled by compromised signing systems, not by Ethereum's EIP-7702 upgrade — but the upgrade may have let attackers sweep funds past withdrawal safeguards in a single stroke. That is the assessment of blockchain security firm Blockaid, whose co-founder and CEO Ido Ben-Natan told Cointelegraph on Friday that attackers could have stolen the money without EIP-7702 at all.

"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. Without it, he explained, the attackers would have needed multiple transactions to move the same value out of the exchange's wallets.

What actually happened at Binance?

Binance confirmed on Friday that it had suffered a $6.3 billion breach — the largest hack in crypto history — and pledged to cover all losses. The exchange initially suspected a compromised laptop belonging to one of its engineers. It has since uncovered additional points of breach, widening the scope of the incident beyond a single device.

Binance CEO Richard Teng said investigators had found no evidence that wallet private keys had leaked. That detail matters. If the keys stayed intact, the attackers had to convince Binance's own signing infrastructure to approve malicious transactions.

Ben-Natan sketched how that could work. Attackers may have used a compromised developer's computer to reach Binance's wallet-signing stack. "Eventually they got to a position where they could propose transactions to what is most likely a very secure signer that has custody of one of Binance's hot wallets," he said. "The takeaway is that ultimately the signer signed a transaction that they shouldn't have."

What does this change for exchanges? It shifts attention from key custody to transaction approval — the human and procedural layer that decides whether a request is legitimate before a signer executes it.

Why EIP-7702 is under scrutiny

Ethereum introduced EIP-7702 in May 2025 as part of the Pectra upgrade. The proposal lets ordinary wallets use smart-contract features such as bundled transactions and sponsored gas fees.

Security concerns surfaced within weeks. In May 2025, crypto trading firm Wintermute reported that most early EIP-7702 delegations pointed to malicious contracts designed to automatically drain compromised wallets. The risks resurfaced in September 2025, when holders of World Liberty Financial (WLFI) tokens reported losses linked to malicious EIP-7702 delegations.

Ethereum community member VEER cited security warnings raised during EIP-7702 discussions back in 2024. After the Binance attack, VEER said the incident appeared broader than a single malicious signature — but that EIP-7702 gave attackers "a handy sweep button on Ethereum."

Could the hack have happened anyway?

Ivo Georgiev, co-founder and CEO of Ethereum wallet provider Ambire, thinks so. He said EIP-7702 made little difference to the attack because the hackers already had the ability to authorize transactions, and could have drained the funds through other methods.

His concern is more specific: exchange engineers might overlook the need to revoke a malicious EIP-7702 delegation after regaining control of their systems. A cleaned-up signing stack with a live delegation still leaves a door open.

"This is a problem with EIP 7702, it's just very very poorly understood," Georgiev said.

What comes next

Ben-Natan warned that similar signing-system attacks threaten other exchanges, not just Binance. He pointed to transaction simulation as a practical defense — simulating requests before approval could catch malicious transactions before a signer executes them.

The operational lesson cuts across the industry. Key custody was not the failure point here. Approval workflows were. Exchanges that treat their signers as untouchable because private keys never left cold storage may still be one compromised engineer laptop away from the same outcome, and with EIP-7702 delegations now live on mainnet, incident-response playbooks need a revocation step that most teams have never rehearsed.