There is a certain irony in pulling the emergency brake, only to discover that the machinery you're trying to stop is operating beyond your reach. Binance encountered a rather expensive version of that problem on 29th October. Attackers compromised its wallet signing infrastructure and obtained authority to move cryptocurrency through mechanisms that did not depend on the exchange's ordinary withdrawal process. Suspending withdrawals could interrupt that process. It could do considerably less about permissions already established on Ethereum. By the time the attack was contained, approximately $6.3 billion had been stolen and Binance's engineers had developed a specialised procedure to revoke malicious on-chain authority. The exchange could shut down affected services, but Ethereum would continue recognising the delegation until it was explicitly cleared. Brian Cubellis, Chief Strategy Officer at Bitcoin custody platform Onramp, offered his two cents to AMBCrypto, Pausing withdrawals turns off the exchange's own software, but it does nothing about permissions the attacker has already written to the blockchain The distinction is an uncomfortable one for an institution entrusted with billions in customer assets. Binance subsequently coordinated freezes of stolen funds and began replenishing the affected holdings, reporting approximately 98% replenishment by 4th November. Its financial response was substantial. However, it still is worth questioning what remained possible while its emergency controls were taking effect. The permission that wouldn't disappear By the way, for those unaware, the attack began well before 29th October and nowhere near a blockchain. According to Binance's 3rd November incident report, an engineer downloaded a tampered installation package for an AI coding tool in June. The exchange detected the anomaly and replaced the device, but the attackers had already gathered intelligence about its employees and infrastructure. Well into September, another engineer was approached through a fictitious recruitment process involving interviews and a malicious coding assignment. By 20th October, the attackers had used compromised employee systems and internal AI tooling to access additional machines. In doing so, they ultimately obtained credentials that opened the way to Binance's wallet signing infrastructure. It all paid off on the 29th. Between 20:05 and 20:09 UTC, hot wallets transferred approximately 223.46 million XRP, 970,500 SOL and 44.2 million OP to attacker controlled addresses. Bitcoin and other assets followed. Chainalysis subsequently estimated the overall theft at approximately $6.4 billion. What was the most consequential part of this intrusion though? The attackers gained access to Binance's signing infrastructure, the very machinery responsible for authorizing transactions. And, they used that trust against it. On Ethereum, the attackers exploited EIP-7702, a mechanism that allows an externally owned account to delegate execution to smart-contract code. Ordinarily, that flexibility expands what a wallet can do. Here, according to Binance, the compromised signing infrastructure was used to grant malicious code execution rights over an Ethereum hot wallet. The exchange described 50 signed transactions involved in manipulating the account's nonce and establishing the delegation. The unsettling part comes next though. Those permissions remained valid on-chain even after Binance suspended withdrawals and shut down its hot-wallet services. The exchange could stop its own systems from processing transactions, but it could not simply switch off the authority the attackers had already established on Ethereum. Then came another complication. Binance's hot wallet used multi-party computation (MPC), which distributes the production of cryptographic signatures across multiple participants or components rather than relying on a single conventional private key. That architecture can reduce certain risks, but it also meant there was no single private key available to revoke the malicious delegation immediately. Binance's engineers had to DEVELOP a specialised revocation procedure while the incident was UNFOLDING. Of course, this took additional time, prolonging the effort to contain unauthorized asset movements. At 23:56 UTC, the final reported unauthorized Ethereum transfer, involving 2,961.9 ETH, was confirmed on-chain. Binance said it had been broadcast earlier and remained pending before confirmation. At 00:10 UTC on 30th October, the exchange cleared the malicious EIP-7702 delegation with a new authorization to the zero address. The distinction between broadcast and confirmation matters. So does the absence of an established total for funds transferred after withdrawals were suspended. Binance acknowledged that suspension alone could not stop every unauthorized movement, but its disclosures do not establish a reconciled post-suspension loss figure. A kill switch... with conditions attached