Translation: Plain Blockchain

Given the scale of this incident, a large number of analysis articles have emerged since it occurred, and most readers may already have an understanding of the overall process. However, many different narratives are circulating in the market, some of which contain inaccuracies. Therefore, I will start from the beginning and outline the true sequence of events step by step.

1.1 Abnormal Withdrawal Requests

Source: XRPL Explorer

The first abnormal withdrawal attempt came from a wallet on the XRP Ledger belonging to Binance. At 5:04 AM on October 30, the attacker attempted to transfer 42.75 million RLUSD to their own address, but the transaction failed. This was because the mechanism of the XRP Ledger stipulates that: a new account will only be activated when it first receives the network's native token, XRP. Eight seconds later, 185.01 million XRP were credited to the address to activate the account. Subsequently, Binance's five XRP wallets were successively emptied, officially launching the theft.

Source: Etherscan

In the following 20 minutes or so, assets on various chains such as Solana, Optimism, Bitcoin, Tron, Ethereum, Arbitrum, and Avalanche were stolen one after another. Around 8:05 AM, a second round of funds flowed out from Avalanche and Polygon wallets. The total amount of stolen assets reached 6.36 billion USD, with the detailed list as follows.

1.2 Binance's Response and the Ecosystem

After the incident, a series of emergency responses unfolded from Binance itself to the token projects affected and DeFi protocols.

Source: BN

Binance immediately stopped withdrawals after the incident. About five and a half hours later, at 10:36 AM on October 30, Binance announced the suspension of deposits and withdrawals and promised to fully bear all losses. An hour later, Binance released preliminary investigation results: the laptop of a DevOps engineer was suspected to have been compromised, allowing the attacker to access the service container and submit unauthorized withdrawal transactions. The official added that there was no evidence to suggest that the wallet private keys were leaked.

The project-level responses also began accordingly.

Source: Paolo Ardoino

Tether was the quickest to act. At 6:01 AM shortly after the incident, Tether began freezing addresses related to the attack, freezing a total of 1.567 billion USD in USDT, which played a critical role in swiftly controlling the situation. USDT0 also paused cross-chain transfers between Ethereum and Tron for caution.

Source: Spreek

Most notably, Circle froze 823 million USD in USDC around the same time as Tether. This was a rapid and extremely unusual move for Circle, which had long been criticized for refusing to freeze funds regardless of the scale of the hacker attacks. This exceptional action was sufficient to demonstrate the severity of the situation.

Source: Arbitrum

At the public chain level, Arbitrum acted the fastest. KST at 9:08 AM, its security council issued an emergency status update, forcing the stolen ARB and ETH from the attacker's address to an independent custodial address. This was exactly the same method used by Arbitrum to freeze funds during the KelpDAO hack. Optimism also adopted the same method, forcing 44 million OP to be transferred from the attacker's address.

Source: Jack McDonald

Ripple suffered significant losses, with the amount stolen in XRP and RLUSD alone reaching approximately 380 million USD. However, actions regarding the only potentially freezeable asset, RLUSD, were relatively slow to materialize. Of the 88.6 million RLUSD stolen, about 40.5 million was frozen, while the remaining 48 million was exchanged for ETH and transferred out.

Source: Aave

Among DeFi protocols, Aave was the quickest to respond. Unfortunately, before the stolen USDT and USDC were frozen, the hacker deposited about 60 million USDT as collateral into Aave and borrowed ETH. Aave subsequently froze its V3 and V4 markets to prevent further borrowing operations.

Source: Compound Community Forum

Compound Finance also froze its main borrowing markets on Ethereum, Optimism, Arbitrum, and Base out of caution, preventing further losses. The countermeasures taken by other known projects are as follows:

• World Liberty Financial: Frozen approximately 75 million USD in USD1 and WLFI.

• Synthetix: Used admin privileges to forcibly recover 8.41 million SNX and transferred it to the protocolDAO's Safe wallet.

• The Sandbox: The multi-signature wallet managing the token contract forcibly recovered 58.4 million SAND.

• Pundi X: After contacting Binance, froze 3.7 million PUNDIX in the attacker's wallet and transferred it to a Binance address.

• Beam: The multi-signature wallet managing the token contract directly destroyed the 984 million BEAM held in the attacker's wallet.

1.3 The Flow of Stolen Funds

Source: Blockaid

As with most large-scale thefts, the funds stolen from Binance were not washed clean immediately. Instead, most of the funds were exchanged for native tokens that could not be frozen and then dispersed to many addresses. Such assets are typically washed through over-the-counter (OTC) transactions or require long-term laundering, necessitating ongoing tracking. For example, in the early 2025 Bybit hack, about 5% of the funds are still traceable on-chain; while in the Drift hack incident last April, over 98.8% of the funds have not yet been laundered (see LazarusBounty).

Source: SomaXBT

The asset transfer path on the Tron chain was particularly complex. After the attack, funds were rapidly dispersed through various channels such as Relay, THORChain, Chainflip, Symbiosis, USDT0, and Across to Ethereum, Bitcoin, and Arbitrum. Some funds even flowed through channels difficult to trace back to withdrawal addresses, such as cross-chain bridges and Bridgers of Bitget wallets.

Source: ZachXBT

Some assets laundered through THORChain converged with funds from September's Bitget hack, which has been attributed to the North Korean cybercrime group TraderTraitor. This actually confirms that the behind-the-scenes force is also North Korean.

Particularly noteworthy is the stance of various protocols on laundering of the stolen funds. Previously, Circle, which had been most passive about freezing stolen funds, responded the quickest this time; conversely, THORChain openly stated that, due to the decentralized nature of the network, it is practically impossible to forcibly stop transfers.

THORChain has consistently maintained this position on the issue of moving stolen funds, which has always sparked massive controversy. In the February 2025 Bybit hack, Lazarus used THORChain as the primary channel to exchange stolen ETH for BTC. During that time, some node operators attempted to pause Ethereum transactions but were quickly overruled by other nodes. In the April of this year’s KelpDAO incident, most of the funds that were not frozen on Arbitrum were also exchanged for BTC via THORChain. In September's Bitget incident, Bitget publicly requested THORChain to block the attacker's address, but was refused, stating that it lacked the mechanism to intercept a single transaction and could only choose to shut down all network or specific chain transactions.

Interestingly, THORChain's response speed is entirely different when its own funds are threatened. On May 15 of this year, THORChain's Asgard treasury suffered a theft of approximately 10.7 million USD due to a malicious node operator leaking key information during the signing process. Node operators quickly reached an agreement on Discord and then paused transactions across the entire network through on-chain voting, resulting in about a five-week halt. This starkly contrasts with their response to external hacker attacks—when faced with external incidents, gathering agreements from at least two-thirds of the nodes is usually very time-consuming, and oftentimes the final decision is to refrain from intervention.

Source: FBI

In a statement based on preliminary investigations, the FBI officially named TraderTraitor as the true culprit behind the scenes. As part of the response measures, the FBI named THORChain node operators and sought cooperation. A co-founder of THORChain responded that the core message is that every transaction passing through THORChain is traceable. Ultimately, THORChain did not take specific action regarding this incident. Ironically, on October 31, Ethereum experienced a block reorganization (Reorg), causing THORChain to encounter a failure and temporarily pause all network transactions, which objectively interrupted the attackers' laundering process.

For a long time, how to deal with assets stolen by hackers has been a focal point of debate. After the hack of Cetus last year, Sui immediately froze the stolen funds through emergency upgrades. At that time, public opinion was sharply divided, with one side accusing Sui of being too centralized, while the other insisted that recovering victims’ losses trumped all else. In this incident, stablecoin issuers, public chains, and project teams implemented asset freezes in various ways at multiple levels, yet few criticisms directed at centralization emerged.

I feel very mixed about this. Rapidly freezing to curb the spread of losses is clearly positive and commendable; but at the same time, I also feel a sense of unease: the attackers among the spectators now fully understand which assets can be frozen and which cannot. In the next attack, they will process freezeable assets at a faster speed, leaving even less time for defenders to react. As the assets and paths allowing for admin intervention become increasingly clear, the stolen funds will increasingly concentrate towards channels like THORChain, which are unlikely to actively intervene, tightening the difficulty and window of tracking these funds.

2. Root Cause Analysis

On November 3, Binance disclosed the specific details of the attack in a preliminary report for the first time. The report points out that, in order to prevent further exploitation in future attacks, some technical details will be kept confidential. Even so, the content that has been disclosed has confirmed most of the facts previously deduced from on-chain data. This section combines on-chain records and official reports to outline the complete invasion path.

Source: BN

Binance's preliminary report indicates that the attack was not a chance infiltration initiated from a single laptop, but rather a multi-stage, meticulously planned operation that lasted for months, utilizing fake job interviews, malware, and internal AI tools in alternating progression. Combining the report with on-chain records, the timeline is as follows:

• June: Wallet DevOps engineer A searched for and installed a popular AI code assistance tool, during which they downloaded a tampered Homebrew installation package. Binance's security team detected abnormalities, replaced the device, and rotated all associated credentials. However, during this process, the perpetrator had learned the specific information about A's position and other colleagues on the wallet infrastructure team.

• September: Software engineer B was contacted by a person posing as a project director on a legitimate job recruitment platform. In the first round of interviews, the attacker's impersonation as HR established trust through a presentation full of personal photos and videos on social media accounts. At the end of the second interview, B was asked to download an “assessment task” on the office computer. The hidden malware in this task replaced legitimate development tools with malicious versions, and the security protection tools deployed at the time failed to detect this anomaly.

• October 20: Using B's computer as a jump-off point, the attacker penetrated and controlled A's and another wallet software engineer C's computers using an internal AI tool. Subsequently, the attacker found a token (Token) with container deployment permissions on A's computer.

• From October 28 to 1:47 AM on October 30: The attacker withdrew funds from Tornado Cash, deployed a sweeper contract, and conducted a practice attack.

• From 2:15 AM to 4:56 AM on October 30: The attacker logged into C's computer, deployed service containers using credentials stolen from A, and ran the attack script.

• At 5:04 AM: The first abnormal withdrawal request was triggered.

This sequence of operations follows the classic hacker methodology for infiltrating platform infrastructure, reminiscent of the 2023 hack incident involving CoinsPaid. In that case, the attacker masqueraded as a recruiter from Crypto.com and struck through LinkedIn, reportedly spending a full six months studying CoinsPaid's organizational structure and role permissions. The method of implanting malware was similarly alike: after several rounds of interviews, the target was induced to run malware disguised as test code locally during the last round of coding tests. The core difference between the two incidents is that the earlier oversight of a DevOps engineer in this incident drastically shortened the time the attacker needed to understand Binance's wallet team details.

If there is anything unusual about this case, it is the repeated use of AI tools throughout the entire attack path. In June, a popular AI programming tool became a phishing bait; in October, the internal AI tool served as a bridge for lateral movement, infiltrating other engineers’ computers. An AI tool that can directly execute commands on developers' computers and can span multiple systems is essentially equivalent to an internal personnel with extensive permissions. In the future, the scope of permissions assigned to internal AI tools will surely become a key item on security self-assessment checklists for major trading platforms.

2.2 EIP-7702 and the Sweeper Contract

In the Ethereum network, the target of the attack was a hot wallet marked as BN 14 (0x28C6...1d60). Unusually, the attacker cleverly exploited EIP-7702.

EIP-7702 is a new feature introduced in Ethereum's Pectra upgrade in May 2025. When an externally owned account (EOA) signs an authorization delegation, this feature allows for specific smart contract code to be mounted onto that EOA address. Thereafter, all calls to that address will execute according to the mounted code logic. This delegation authorization will remain effective until a new authorization is signed by the same address to override it. In personal wallet scenarios, this feature is often used for bundling batch transactions or paying Gas fees. However, it conversely means that as long as someone can induce a wallet to sign a delegation to a designated malicious contract, anyone can completely take over that wallet; from that moment on, all assets within it can be entirely dictated by their code. This was precisely the goal the attacker aimed for.

The attacker made extensive preparations for this. The attacker's operational address (0x7C86...5CA0) first received funding at 4:39 PM on October 28, withdrawing 0.1 ETH from Tornado Cash. The next morning, at 11:28 AM, this address deployed the first version of the sweeper contract, consisting of core functions that could transfer all designated tokens and ETH at once. Subsequently, from 10:51 PM on the 29th to 1:47 AM on the 30th, the attacker repeatedly tested using the three wallets they controlled, testing the entire process (from delegation authorization to asset transfer), with test amounts ranging from 2 to 6 USD.

Source: Blockaid KST

At 5:24 AM, just three minutes after the authorization took effect, the operational address invoked the sweep function. In a single transaction, over 60 assets, including 167,464 ETH and 1.615 billion USDT (total value approximately 2.53 billion USD), were all funneled into the receiving address (0x5227...2f8c).

The larger issue was that the authorization remained valid after the first plunder, leading to secondary losses. Since BN 14 had execution permissions for a certain smart account under Binance, the attacker used the generic execute function to withdraw another 823 million USDC from that account. Additionally, Binance's deposit aggregation system continued to funnel new funds into BN 14, allowing the attacker to implement a second harvesting of newly incoming assets. In the two hours following the initial sweep, the attacker continued to harvest newly deposited funds, and the state of the malicious delegation remained for over three hours before being revoked.

As EIP-7702 was misused in this attack, the feature itself has come under intense scrutiny. Those who believe EIP-7702 should be held responsible for the incident put forth the following arguments:

• If it weren't for the delegation function, the attacker would have to send more than 60 separate transactions to transfer over 60 different tokens. These transactions would inevitably compete with Binance's normal withdrawal queue for Nonce, resulting in many transactions likely failing. The authorization delegation allowed the attacker to siphon 2.53 billion USD through a single call.

• In the past, even if the signing system was compromised, the attacker would still need to obtain independent signatures for each transaction. As long as access was cut off, it could halt the outflow of funds; whereas delegation authorization hands over control of the entire account at once, completely erasing the time gap for the defenders to detect and respond. In fact, during the more than two hours following the initial raid, the attacker continued to transfer newly deposited assets without requiring any new signatures from BN 14. The limits and frequency restrictions of withdrawal transactions are fundamental security defenses aimed at gaining processing time, but the delegation mechanism breaks this defense.

• Standard accounts created before the Pectra upgrade never actively opted into this function. Unilaterally lowering the security of existing users and then requiring insecure users to change wallets afterwards is highly unreasonable. For addresses that do not require a delegation function (like hot wallets), Ethereum should have provided a registration mechanism to permanently refuse such features.

• The only way to revoke a delegation is for the same wallet to sign a new authorization to the zero address (0x0). Since the private key is still bound to the address even after rotating the delegation state, to remove the delegation, one must use the already compromised old key to sign again.

Conversely, those who believe EIP-7702 should not be blamed for the incident countered:

• The delegation authorization itself was legitimately signed using BN 14's private key, and the blockchain network merely executed the established design faithfully. The core issue lies in the uncontrolled abuse of the signing infrastructure, not a flaw in the underlying protocol itself.

• The attacker able to sign 50 delegation authorizations also has the ability to sign normal transfer transactions. In fact, during the same timeframe, wallets on BN 16 and 9 other public chains did not utilize EIP-7702 and were emptied using only normal signatures.

• Smart contract wallets with accompanying access control strategies have long existed and been widely applied; this was purely Binance’s choice not to adopt.

• If a delegation blacklist mechanism were to be introduced, each delegation transaction would require additional state queries, and that blacklist must be permanently maintained by the network. It is unreasonable to make all ordinary users bear the performance and storage costs for the special demands of a few trading platforms.

Personally, I believe that EIP-7702 itself is not the culprit.

How a function is used is the responsibility of the user; moreover, EIP-7702 is not a mandatory function. Under no circumstances, unless the wallet key actively signed the delegation, could such actions spontaneously trigger. Moreover, normal withdrawal operations on trading platforms never require the signing of any delegation authorization. The fact that Binance's signing system was able to generate 50 delegation authorizations in one go points to a significant failure in the logic of the signing strategy.

Additionally, Binance once had a response window: at the moment the delegation took effect, malicious contract code had already been attached to the BN 14 address. There was a gap of 3 minutes and 24 seconds before the sweep function was triggered, making this change in blockchain state completely open and visible to everyone. In my view, with Binance's technical scale, they should have sufficient preparations in place: a monitoring mechanism could be built so that as soon as a hot wallet unintentionally mounts code through EIP-7702, it would immediately trigger an alarm, and pre-signed revocation transactions could be ready for immediate blocking.

2.3 The Core of the Leak is "Signing Permissions"

In recent years, major attacks on mainstream trading platforms, especially those with associations to North Korea, have showcased a highly consistent pattern: attackers no longer directly strive to steal hot wallet private keys but instead infiltrate internal infrastructure, hijacking signing permissions or tampering with the transaction payloads awaiting signature.

• In May 2024, DMM Bitcoin: Approximately 4,502.9 BTC were stolen. The FBI indicated that TraderTraitor masqueraded as a recruiter, infiltrating the computer of an employee from the wallet software supplier Ginco, which allowed the attacker to tamper with legitimate transaction requests from DMM employees.

• In July 2024, WazirX: Approximately 235 million USD were stolen. The signers of the multi-signature wallet approved transactions that appeared normal on the custody interface, but the underlying signatures directly authorized malicious transactions that relinquished control of the wallet.

• In February 2025, Bybit: The attacker tampered with the signature confirmation screen through a developer's computer at Safe. The signers signed what they thought was a normal transaction but essentially relinquished management rights of the cold wallet.

• In September 2026, Bitget: The attacker hacked into the backend of the wallet infrastructure and forged transaction data. Bitget later confirmed that the attacker neither obtained private keys nor forged user withdrawal requests.

From this perspective, the most unusual aspect of this incident was the delegation authorization itself. Delegation authorization is fundamentally not a routine withdrawal transaction; even if normal business flows of a trading platform never require such transactions, Binance's signing system managed to issue 50 of them. Assuming the signing system lacked syntax parsing and whitelist constraints on the signed content, or if the attacker directly bypassed the verification layer, then the system would be unable to discern whether a request was for a normal withdrawal, delegation authorization, or some other dangerous operation.

This type of attack cannot be prevented by relying solely on multi-party computation (MPC) or hardware security modules (HSM), even though traditional finance and cryptocurrency institutions often consider them the only gateway to key security. The core function of these tools is merely to prevent private keys from leaking across physical or system boundaries; they cannot verify what these private keys were used to sign. Unless signing executors can semantically parse the data to be signed and independently verify it based on preset policies, this structural shortcoming will remain exposed to attackers.

3. Reflections and Insights

3.1 The Urgent Need for Rigorous Information Verification

During the handling of this entire incident, what worried me most was the incredible speed of the spread of false information.

At the onset of the incident, there were rampant rumors within the community claiming it was a self-directed performance by Binance to maliciously wash their assets. However, within just a few hours, external third parties like Tether and Circle had successively frozen about 3 billion USD in assets; some stolen funds were also mixed with funds that were hacked via THORChain and Bitget. If this had been a self-directed performance by Binance, these undeniable facts could not hold up at all. Some statements denying North Korea’s involvement further exacerbated such baseless suspicions; however, the FBI has officially named them, and a considerable amount of on-chain and intelligence physical evidence has substantiated the facts of TraderTraitor’s actions.

Source: X

On November 1, the X account @doomerfied, known for spreading false news, slandered a certain DevOps engineer from Binance, claiming that the engineer was caught in a romance scam involving a North Korean female spy and casually left their office computer unattended on the day of the incident. Subsequently, a media official account indiscriminately retweeted this rumor, causing it to quickly ferment on X and even split and spread in South Korean Telegram communities, with many people still believing in this “honey trap” story. Such false news is of no help in managing aftermaths when a major hacking incident triggers extreme panic and chaos among the public.

In an age of information overload, media with public opinion influence must fulfill stricter verification responsibilities before publishing content.

3.2 Where Should Individuals Store Their Assets?

The reason this incident could be effectively contained is largely due to the fact that the victim was Binance. Binance completely relied on its own reserves to marshal 6.34 billion USD without borrowing a penny from the outside. According to Binance's data, the net outflow on the first day of resuming withdrawals accounted for only about 2.1% of its total assets. Reflecting on 2025, Bybit had to borrow ETH from other institutions and trading platforms to get through after being attacked. This indicates that if a disaster of similar scale were to occur at any other trading platform, a run leading to bankruptcy would be unavoidable. Moreover, the intervals between attacks on leading trading platforms are shortening sharply—from Upbit in November last year to Bitget in September this year, and now to Binance.

However, the dilemma is: there are no absolutely reliable places for funds withdrawn from centralized trading platforms, and personal self-custody wallets are also disaster-prone targets for hackers.

In October, it was revealed that devices sold by Southeast Asian Ledger authorized dealer CryptoBilis were implanted with unknown malicious hardware components. According to Ledger's security team, the component could sniff the display content of hardware screens, quietly reading the 24 words during the mnemonic phrase generation interface, and transmitting them back to the attacker through its built-in LTE module. The losses caused by backdoored Ledger devices are estimated to exceed 90 million USD. Reports indicate that Trezor hardware wallets (another leading manufacturer like Ledger) that were also sold by the same dealer similarly faced issues of tampering and swapping.

Software wallets are also hard to escape, as evidenced by Trust Wallet, which lost about 7 million USD due to a malicious update of a browser extension last December. This year, attacks on various crypto wallet open source libraries have been rampant, causing users to be on edge. Yet, users continue to flock en masse to self-custody. Third-party data reports show that out of the 4.5 billion USD withdrawn in the 24 hours after Binance resumed withdrawals, only about 368 million USD flowed to other top ten trading platforms; meaning that 90% of the fleeing funds did not choose to exchange for another centralized platform but were directly withdrawn to external personal addresses.

Source: Ambire

In this broader context, wallets built on completely open-source software and hardware may become an effective sanctuary for individual users. Coincidentally, Ambire released the open-source hardware wallet Ice on the same day Binance was attacked. Ambire disclosed the hardware architecture design, PCB circuit diagram files, and the complete firmware of the wallet, allowing anyone with the necessary tools to replicate and assemble it themselves; its mass-produced sales version also deliberately adopted a completely transparent casing for easy internal component verification by users.

Indeed, open-source does not equate to absolute security; in reality, very few ordinary users will check each piece of hardware against circuit diagrams. Nevertheless, I firmly believe that with the frequency of security incidents rising, people will inevitably tend to choose transparent tools that are logically verifiable and constructively checkable, and the market demand for completely open-source self-custody wallets will suffer an irreversible surge.

3.3 Binance and the Crypto Ecosystem's Rapid Response as a Model of Emergency Handling

Binance's handling during this crisis is commendable: on the day of the incident, it committed to covering all losses in full and swiftly marshaled 6.34 billion USD in special funds from its reserves; regarding users’ primary concern of solvency issues, it promptly revealed proof of reserves.

Resuming withdrawals progressed remarkably quickly: starting from 3 PM on November 1, it was reopened in batches, initially covering 15 mainstream networks and assets such as BTC, ETH, USDT, USDC, BNB, SOL, and XRP. By 9:36 PM that evening, all currencies in the first stage had returned to stable operation.

According to disclosures from Binance, within about 9.5 hours of the withdrawal channel being opened, the total withdrawal amount was 4.649 billion USD, the total deposit amount was 1.01 billion USD, and the net outflow was 3.64 billion USD, comprising only 2.1% of its 171 billion USD total assets. In DefiLlama monitoring, the net outflow peaked at about 7 billion USD within 24 hours but then quickly halved back.

Most notably, the proof of reserves mechanism finally exhibited its effectiveness in this operation. Although Binance faced heavy criticism for introducing this mechanism in response to the FTX collapse in November 2022, due to its “failure to provide transparency on liabilities” (a criticism that still persists), under the extreme pressure of billions of USD instantly fleeing, Binance's performance in terms of its resilience and payouts proved to be remarkably efficient.

Outside of Binance, the ecosystem collaboration was similarly noteworthy: as mentioned earlier, Tether and Circle initiated fund freezes within an hour after the incident; the Arbitrum security council and various token projects decisively employed admin backdoor methods to forcibly reclaim or lock assets; Aave and Compound quickly hit the brakes to prevent bad debts from deepening within DeFi. At least in this incident, the entire cryptocurrency industry prioritized countering hackers over commercial competition. However, as mentioned earlier, this high efficiency largely relies on the existence of centralized intervention powers in the hands of all parties, which simultaneously pressures the entire industry to run even faster during the next crisis.

4. Various Perspectives

4.1 Juno, Head of ChainLight

Unlike the focus on tracing the stolen funds on-chain, my work lies in a more upstream link—focusing on the security architecture of the underlying crypto infrastructure itself.

Each time a security breach occurs and forensic reviews are conducted, I always ask the same question over and over: “Were there really no warning signs before this?” Looking back, there are often many more early warning signs than people expect. Indeed, no one can precisely predict every attack; but ‘predicting attacks’ and ‘detecting abnormal states’ are entirely different logical realms.

Even in this incident, there remained a valuable window of approximately 3 minutes. From the perspective of internal controls in trading platforms, the initiation of an EIP-7702 delegation transaction from one’s own hot wallet is, in itself, extremely unusual. Even if you were completely unaware of which attack methods hackers would adopt beforehand, you could easily define that ‘this situation should never occur’ in advance. Therefore, I believe that the purpose of security is not just to discover as many vulnerabilities as possible; the essence of security’s responsibility lies in clearly defining ‘what constitutes abnormality’, verifying whether systems can truly capture these abnormalities in reality, and ensuring that the alert-triggering blockage plans can be smoothly executed through regular training exercises. Of course, listing all possible abnormal scenarios is extremely challenging, and some might think this is fundamentally unrealistic. I agree that achieving 100% coverage is not feasible, but that is no excuse to give up on defenses. Ultimately, the only recourse for defenders is to continuously reflect on the attacker’s perspective, gradually filling the cognitive and defensive gaps one by one.

However, there is also a deeper core contradiction: no matter how thorough detection and response are, if the entire system is riddled with holes from the outset of its design architecture, certain attacks are impossible to prevent. This is also what shocked me most about this incident. When I initially learned that the hacker utilized EIP-7702 and that multiple chains were emptied simultaneously, my first intuition was that the private key itself was stolen, not that there were issues with the signature system mechanism. Because in my view, a signature system should contain only the most streamlined code and the minimal verification logic, and it must be highly isolated to ensure it cannot be directly accessed from production environments or ordinary access paths. Network communication must be extremely tightened, and identity authentication and access permissions must be rigorously controlled.

Given Binance's immense scale, I had thought that even while handling the aggregation or splitting of individual transactions, they would have already established comprehensive depth defenses: the signing machine should only receive extremely limited necessary information inputs, and the legitimacy of each request should be strictly verified in a completely independent environment. For instance, the signing mechanism should only take the target recipient address and transfer amount as input parameters, assembling the underlying transaction instructions itself; only when supplementary offline multi-signature confirmations are added should final signatures be permitted for any hash values. Realizing this architecture perfectly is indeed a major technical challenge, but for an industry giant like Binance, sufficient resources should be invested in this field to secure it.

That said, my focus isn’t to judge whether a specific code implementation is right or wrong, but rather whether our final line of defense has blindly trusted the directive judgments from upper systems to what degree. Some structural risks cannot be resolved merely by patching or adding detection rules; the only solution is to completely reconstruct the system architecture. In practical work, when you continuously draft response plans and rehearse them repeatedly, you often experience a moment of epiphany—you realize, ‘this system architecture fundamentally cannot defend against such attacks.’ I actually view this moment as an extremely valuable breakthrough. Because it’s at that moment that you finally start stepping outside of patching local issues and begin to seriously re-examine security at the system design level, which is truly practicing Secure by Design.

In addition to technical architecture, there is another equally vital dimension: operational security (OPSEC). A casual search for Binance on LinkedIn will uncover a wealth of detailed profiles about who is in which technical group and what specific responsibilities they hold. Finance is a critical infrastructure for society, and how well the core personnel who hold decisive power over key systems are actually managed in terms of OPSEC norms is a crucial consideration.

This reminds me of the precedent set by MakerDAO (now rebranded as Sky). MakerDAO once had a strict regulation called “2.6.6 Aligned Delegate Operational Security” (2.6.6对齐代表操作安全). According to this provision, if someone reports violations of operational security norms by an aligned delegate (AD), once verified, that delegate would be directly stripped of their identity, and half of their staked collateral would be rewarded to the whistleblower. Between 2023 and 2024, several ADs were indeed dismissed for violating this provision. In a case in April 2024, the whistleblower directly received a massive bounty of 20.84 MKR, which at the time was worth approximately 7 to 8 million Korean won. This case is impressive because it does not treat operational security as a matter of personal morality or work habits of employees, but as an immutable prerequisite for maintaining the entire system's survival.

The technicians guarding the core infrastructure of crypto essentially hold the keys to an immense vault. Even if direct asset theft does not occur, the leakage of information regarding their understanding of the underlying system design and internal operational logic could be enough to spell disaster for the institution. Their positions carry extremely high-risk responsibilities, and I believe that enterprises should also give equal attention and compensation to these in their daily management and remuneration practices.

Lastly, I foresee that all of this will become increasingly severe in the future, with a significant part of the catalyst coming from AI. Regardless of whether it is fully attributable to AI, the productivity of attackers has qualitatively increased compared to the past. If past hacker defenses were like ‘single-core’ individual combat, today's attackers seem to have 'unlimited core' concurrent computing power. They can encapsulate their hacking experiences into autonomous agents and fully automate infiltration techniques while advancing the cumbersome work that originally required extensive human labor at a high scale. The cost of trial and error for attackers is plummeting, and the attack cycles are continuously shrinking. If defenders continue to stagnate in the old mindset of ‘finding as many vulnerabilities as possible and patching them one by one’, they will eventually be completely overwhelmed by this exponential pace of attacks.

Therefore, I believe that future security strategies will ultimately distill down to three things:

• Detection: Even when faced with previously unseen attack methods, systems must have the capability to accurately capture and label abnormal states.

• Response: Emergency response plans must be repeatedly rehearsed and refined to ensure that, in the moment of detecting an abnormality, it can truly cut the link, curb, or minimize damage.

• Design: For risks in physical spaces that detect and response cannot eliminate, the system must be thoroughly reconstructed from the ground up to make attacks infeasible at the architectural level.

And all of these defense foundations must be built upon watertight operational security (OPSEC).

Ultimately, the most crucial thing has never been to predict every single hacker attack with prophetic precision, but rather to build a resilient system that can withstand even unforeseen attacks and still endure. While discovering vulnerabilities is important, the real frontier of modern cybersecurity should be broadened to include sharply detecting anomalies, responding in seconds, robustly curbing subsequent disasters, and decisively reconstructing system architectures when necessary.

I extend my highest respect to all the guardians fighting on the front lines of the crypto ecology.

4.2 GSS1, Senior Researcher at OtterSec

In large security incidents, the severity of the disaster often does not merely depend on the attack itself, but also on the speed of assessing the scene post-incident and whether the relevant parties can break down barriers to collaborate closely in cutting further losses, which is also a key factor in determining the outcome. This Binance hack incident not only demonstrated hard power in emergency response capabilities but also confirmed the tremendous potential that can be unleashed through deep collaborative efforts across the entire industry. Despite the stolen assets amounting to approximately 6.3 billion USD, thanks to the lightning-fast cooperation of all ecosystem participants like Tether and Circle, approximately 3 billion USD was ultimately intercepted and frozen, which eloquently signifies the irreplaceable nature of rapid collaboration in mitigating the destructive power of major security incidents.

However, this case also ruthlessly pierced through the fragile bottlenecks of the existing defense collaboration system: ChainFlip revealed that some funds involved in the incident, which were intercepted and excluded by their AML (Anti-Money Laundering) screenings, were surprisingly returned to new deposit addresses and were re-deposited, successfully circumventing the risk control measures; Symbiosis also publicly admitted that even though it successfully captured initial abnormal movements of the stolen funds and rapidly reported them to Binance, its existing filtering defense systems still exhibited significant technical limitations in practice.

These painful cases warn us that: even if each protocol operates its own risk control and interception rules in separate battles, they still lack the strength to cope with hackers rapidly splitting and laundering funds across multiple chains and protocols. This incident raises another intriguing question: If a similar devastating disaster befell a mid-sized Web3 project with limited visibility, would the entire industry exhibit the same level of collaborative execution power and speed in rescue?

I firmly believe we must work towards creating a security emergency mechanism oriented towards the entire ecosystem—allowing every security incident to receive a lightning-fast response regardless of the scale of the victim's funds or power landscape. Although there are decentralized emergency assistance channels like SEAL 911 in the industry, the normalization of defense mechanisms among trading platforms, stablecoin giants, public chain ecosystems, and cross-chain bridges needs to be further solidified. Particularly, if it could promote a standard process for on-chain event reporting and real-time synchronization of verified hacker address databases and money laundering fund topologies among core teams, it would undoubtedly tighten the noose around the outflow of stolen funds more effectively.

Of course, within this framework, extremely rigorous cross-validation logic must also be introduced to completely eliminate malicious false reports and unwarranted freezing of legitimate assets. I sincerely hope that this Binance incident can become a turning point for the entire cryptocurrency industry to reconstruct emergency collaborative paradigms, allowing all participants, regardless of their size, to receive professional, efficient, and equitable security escort during dark times.

4.3 Jinmo123, Co-Founder of QED Audit

AI has undoubtedly ushered hacker defense into an entirely new "Great Hacker Era," but it is necessary to clarify the boundaries cognitively: there should be a strict distinction between ‘hacker attacks initiated autonomously by AI’ and ‘attacks that merely use AI tools as an infiltration path’. This incident involving Binance clearly leans heavily toward the latter. The method of poisoning the Homebrew installation package via fake Google promotion links has been frequently observed since January 2025, while the social engineering phishing based on fake job interviews has been a traditional tactic frequently employed by North Korean hackers. The only truly novel aspect of the entire incident was the attacker's use of internal AI tools as a springboard to complete critical lateral penetration into the permissions of core wallet infrastructure engineers.

Following this line of thought, an industry trend fraught with risks is emerging: many large companies, represented by Coinbase, are inclined to centrally consolidate the use of AI across all business lines into a single centralized LLM gateway (Gateway). This central gateway, located at a pivotal junction, naturally possesses an excellent attack position for tampering with Tool Call outputs, stealthily injecting trojans into internal network developer terminals. Once configuration control of this core gateway shifts ownership, we would fall into a dilemma of ‘who supervises the supervisors’.

That said, wholly rejecting AI is also not a feasible option—when AI has fully empowered the speed of infiltration and lateral movement for attackers, defenders cannot possibly keep pace with the rhythm of attack-defense confrontations without AI assistance. Although in this disaster, the internal AI served as a gateway for hackers to advance, ironically, the first line in Binance's post-disaster defense reconstruction plan explicitly states ‘to fully expand the AI-based anomaly detection system’—this sounds paradoxical, yet it is the only pressing necessity of reality. However, the detection side of defenses has never been straightforward. The zero-day malware used by hackers in September effortlessly evaded detection from traditional EDR (Endpoint Detection and Response); anti-EDR circumvention, which requires high-frequency attempts and fine-tuning tasks, is precisely the battleground where generative AI excels.

Meanwhile, AI can easily produce astronomical levels of discrete anomalies, thoroughly drowning real fatal blows in a vast ocean of background noise. Just this year, Binance has thwarted 57 attacks clearly linked to North Korean hackers; when buried in the masses of daily threat alerts, almost no security team could foresee that: the device casually processed in June, which appeared to have been simply dealt with, would set off an astonishing calamity four months later. This explanation may seem slightly abstract, but the underlying military code of network security remains robust and unchanged: the principle of least privilege, zero trust architecture, and deep endpoint detection must be stringently applied across all AI infrastructure.

Those third-party dependencies and employee off-chain behavior norms long neglected in the blind spots of traditional scrutiny must be unconditionally incorporated into the core attack surface auditing models in the future. In the face of AI's disruptive force, there is currently no universally applicable solution in the realm of security, but glimmers of hope remain visible: the efficiency of AI-driven static source code analysis is widely recognized in the industry, and the agility of various parties in freezing hacker assets stands in stark contrast to the Bybit era; the industry consensus 'code is law, except when it's a hack' is also accelerating in its consolidation.

Even so, the just-passed October has still become the darkest 'Cybersecurity Awareness Month' in crypto history. Hopefully, a year from now at this time, we will be facing an industry that has reinforced its defenses and undergone significant renewal. *Note: As of now, there is insufficient evidence to characterize the Binance incident as an attack fully driven by AI. However, the long-standing frailty of internet infrastructure has long been an open secret; the lack of incidents thus far can simply be attributed to the rarity of top-tier hackers possessing both strong motives and high technical prowess.

Network security is fundamentally a game of arbitrage between ‘attack costs’ (covering cognitive thresholds, intelligence acquisition, and time costs) and ‘asset value’. The arrival of AI is drastically lowering the technical barriers to intrusion across all scenarios. In my view, the recent succession of hacker catastrophes is the inevitable consequence of the explosive growth in the global base of malicious hackers—or, to put it another way, the widespread proliferation of hacking agents (Hacking AIs).

This article link: https://www.hellobtc.com/kp/du/11/6492.html

Source: https://x.com/FourPillarsFP/status/2117848684193095942