Binance Says On-Chain Authorization Defeated Withdrawal Pause

Binance Chief Security Officer Jimmy Su said on Nov. 9 that an on-chain authorization allowed asset transfers to continue during the exchange's Oct. 29 security incident, even after the exchange paused withdrawals. Stopping the outflows required a separate blockchain transaction to revoke the permission, because the authorization lived outside Binance's withdrawal system.

The explanation fills a gap in Binance's previously disclosed security response. Pausing withdrawals, the standard emergency lever for a centralized exchange, had no effect on transfers executed under the attacker's pre-existing on-chain permission. Binance had to broadcast a new transaction to strip that permission before the movement of assets stopped.

Why did containment take hours?

Su attributed the delay to the architecture of Binance's hot wallet. The wallet uses multiparty computation, a key-management scheme that splits signing power so no single private key exists. That design improves day-to-day security but removed the option of a single-key revocation when the incident began.

Instead, the security team had to construct a new process to revoke the authorization under multiparty constraints. Only after that process ran did Binance contain the incident, hours after it began. Su's account makes clear the bottleneck was not detection or the withdrawal pause itself, but the mechanics of unwinding an on-chain permission from a distributed key setup.

What changes at Binance now?

Two follow-on measures are underway:

• Binance is bringing in outside security experts to verify its internal findings from the incident and recommend improvements to its response procedures.
• The exchange is preparing a security research fund in partnership with AI companies and security firms, focused on AI-related threats to blockchain systems.

Su said Binance will also manage its internal AI tools and development environments to critical-infrastructure standards going forward. That commitment covers the tooling the exchange builds and operates itself, not only vendor-supplied systems.

What does the incident expose about exchange security design?

The Oct. 29 event highlights a structural gap between exchange-side controls and on-chain permissions. A withdrawal pause governs Binance's own systems; an on-chain authorization governs the blockchain itself. When an attacker holds the latter, the exchange must respond on-chain, at blockchain speed, with whatever key architecture it has deployed.

Multiparty computation is widely adopted precisely because it removes single points of failure. Su's account shows the trade-off: the same property that prevents one compromised key from draining a wallet also prevents one key holder from instantly cutting off a malicious authorization. Exchanges running MPC wallets now face a documented case where revocation latency, measured in hours, defined the incident's duration.

The episode also signals where Binance sees the next threat surface. By funding research into AI-related threats to blockchain systems with external partners, the exchange is treating machine-learning risks to key management, detection and infrastructure as a forward line of defense rather than a retrospective concern.

The outside review of Binance's internal findings has no published deadline, but its recommendations, together with the research fund's scope, will shape how the exchange revises both its incident-response playbooks and its on-chain authorization hygiene before the next attempted breach.