简体中文版： 点击阅读
Incident Recap
On October 30, 2026, Binance suffered the largest cryptocurrency theft on record. Hot wallets across 10 major blockchains were systematically drained, with an estimated US$6.36 billion in assets stolen. Based on in-depth technical analysis of on-chain data, transaction sequencing, and attack patterns, together with the information disclosed by Binance, the available evidence points to a compromise and unauthorized use of the exchange’s hot-wallet signing infrastructure, similar to the attack on Bitget in September this year. Binance has stated that it has found no evidence of wallet private-key leakage, while the investigation remains ongoing.
The key technical sequence of the attack can be reconstructed as follows:
1. In this attack, high-frequency anomalous outbound transfers bearing fully valid signatures were observed almost simultaneously across multiple non-EVM chains, including Bitcoin (US$1.47 billion), TRON (US$628 million), XRP (US$296 million), and Solana (US$96 million), within the same time window (approximately 20:05 to 20:22 UTC). The appearance of large volumes of unauthorized but cryptographically valid signatures across multiple public blockchains that rely on different signature schemes strongly suggests, together with Binance's own disclosures, that the attackers illicitly abused the signing authority of Binance's cross-chain hot-wallet system. After bypassing Binance's security controls, the underlying signing service was reduced to an execution tool for malicious blind signing.
2. On Ethereum (with losses of approximately US$3.79 billion), the attackers abused the EIP-7702 mechanism introduced in the Pectra upgrade. They crafted 50 EIP-7702 authorizations with valid signatures and used malicious smart contracts to take over transaction execution for a Binance Ethereum hot wallet and drain its balance in a single transaction.
What matters most in this incident is not whether a particular DevOps employee's computer was compromised, nor the EIP-7702 mechanism itself. The real question is why, despite no evidence of private-key leakage having been found, a transaction that should never have happened was still able to break through Binance's entire security architecture and be executed by the system as a 'legitimate request'.
The "Maginot Line" That Was Bypassed
A transaction initiated by a platform's business system must pass through many stages before it is finally signed and broadcast. At a large exchange such as Binance, that path is certain to be layered with security controls, including risk controls, validation, and multi-step approvals. But this incident shows that if an attacker can bypass all of those upstream controls and obtain direct access to the signing system, everything that came before can become irrelevant.
This is precisely the risk most often overlooked in institutional wallet architecture. In a typical institutional wallet design, the signing system is a passive service module with its own authorization mechanism. Once access to that signing system is illicitly obtained, an attacker can impersonate a 'legitimate' requester and cause the system to sign any malicious transaction. At that point, the many security controls an institution has deployed are reduced to a 'Maginot Line' that has already been bypassed.
Institutional wallet infrastructure therefore needs to evolve from a passive model of deciding 'who is allowed to sign' to an active model of deciding 'what is allowed to be signed' - in other words, to signing that validates the true intent of the transaction.
Intent-Verified Signing
For institutions, true transaction intent is multi-dimensional. It may include risk-control policies defined in advance, such as whitelists; it may also include key transaction parameters explicitly confirmed by approvers, such as the destination address.
To build wallet infrastructure capable of validating true transaction intent, several layers are required:
First, the signing path must include an independent policy enforcement engine, and that policy control must reside in the same trusted execution environment as the signing module. Policy checks must not be bypassable, ensuring that the signing module cannot be invoked without the required policy validation.
Second, the policy enforcement engine must be able to understand and validate the true intent of a transaction. It must determine whether the action is a standard transfer, a smart-contract call, or an authorization action (for example, an EIP-7702 authorization), and then perform fine-grained checks on whether the action matches the true transaction intent - for example, whether it conforms to a pre-defined whitelist, whether the target contract or even the contract method is authorized, and whether it has been reviewed and approved by human approvers. Only transaction or authorization requests whose intent has been validated should proceed to signing.
Third, the system must cross-validate authorized intent coming from multiple systems rather than trusting any single system in isolation. This is essential to prevent a single compromised system from becoming a single point of failure. Pre-defined whitelists and transaction amount limits represent intent defined by the institution in advance. Human approval represents intent expressed by the approver at the authorization step. Valid authorization from other business systems, such as risk-control systems, represents intent expressed through organizational processes. A mature signing system should not allow a transaction simply because one system says it may be signed; it should confirm that these layers of intent are consistent with one another and supported by valid authorizations. This helps prevent a compromise of one component from allowing unauthorized transactions to pass through the entire workflow.
Fourth, independent trusted hardware should be introduced to preserve the approver's intent. In the AI era, attacks against software systems have become far more efficient, and the endpoints used by approvers - laptops and phones - have become prime targets. Once such a device is compromised, the approver can be tricked into authorizing a forged or altered transaction. By bringing independent trusted hardware into the approval process, institutions can better ensure that the approver's real intent is what is actually authorized.
The recent attacks on Bitget and Binance make one point increasingly clear: as attackers become AI-enabled, traditional security architectures are no longer enough to withstand the threats of this new era. As the core infrastructure of digital-asset businesses, wallet systems need to evolve continuously in both design philosophy and security architecture.
RigSec Institutional Wallet Infrastructure
As a digital-asset infrastructure provider deeply rooted in Asia-Pacific and serving a wide range of regulated financial institutions, RigSec has designed its institutional wallet and custody solution around the security principle of ensuring that transactions reflect authorized intent. The solution combines FIPS 140-3 Level 3 certified hardware security modules (HSMs), an integrated policy enforcement engine, and financial-grade personal security devices to provide end-to-end protection for true transaction intent. It ensures 'what you see is what you sign' (WYSIWYS) and effectively defends against transaction forgery and tampering caused by man-in-the-middle attacks. RigSec's solution is deployed on-premises, ensuring that clients retain full control over assets, data, and operational processes.
About RigSec
Since 2018, RigSec has focused on building institutional-grade digital-asset wallet and custody infrastructure for banks, exchanges, custodians, payment service providers, and other market participants.
RigSec has extensive experience deploying infrastructure for regulated clients in six regulated markets - Hong Kong, Japan, Singapore, Indonesia, Taiwan, and the UAE. In Hong Kong, nearly 40%* of virtual asset trading platforms (VATPs) licensed by Hong Kong’s Securities and Futures Commission (SFC) have deployed RigSec wallet and custody infrastructure. Multiple exchanges within the global top 10 use RigSec solutions to safeguard client assets. RigSec production deployments support a wide range of business scenarios, including trading, custody, asset tokenization, stablecoin issuance, and payments.
(*Data as of December 31, 2025)
Looking to enhance the security and resilience of your digital asset custody infrastructure? Get in touch with us at [email protected] to learn more.