Reflections on the Binance Exploit

Key Takeaways

• Starting at 5:04 a.m. on October 30, 2026, $6.36B in assets was stolen from Binance hot wallets on 10 chains, the largest theft of its kind on record. Most of it was drained within about 20 minutes. The FBI named North Korea's TraderTraitor as the group behind the attack. As in the group's other recent exchange hacks, what was compromised was the internal signing infrastructure, not simply a private key.
• Tether and Circle froze about $2.4B in stablecoins within an hour of the incident. With the Arbitrum Security Council and several token projects also stepping in with admin powers, more than $2.8B of the stolen assets has been frozen or recovered. Binance, for its part, raised $6.34B without outside borrowing to cover the losses. Backed by Proof of Reserves and a phased reopening of withdrawals from November 1, it kept first-day net outflows to about 2.1% of total assets, by Binance's own count. That said, this outcome was possible largely because the exchange involved was Binance. Had an exchange with fewer financial resources suffered an incident of the same size, a bank run would have been hard to avoid.
• About 90% of the funds that left Binance after withdrawals reopened went somewhere other than the top 10 exchanges, pointing to growing demand for self-custody. However, as the tampered Ledger devices and the malicious Trust Wallet update show, personal wallets are not a safe haven either. The more often such incidents occur, the more demand there will be for open-source wallets whose design and internals users can check for themselves.

1. Incident Overview

Given the scale of this incident, a large number of analyses have appeared since it first broke, and most readers probably already know the general course of events. However, many different accounts are now circulating, and some of them are inaccurate. I will therefore begin by going through what happened, step by step, from the start.

1.1 Abnormal Withdrawal Requests

Source: XRPL Explorer

The first abnormal withdrawal attempt came from Binance's wallet on the XRP Ledger. At 5:04 a.m. KST on October 30, the attacker tried to send 42.75M RLUSD to their own address, but the transaction failed. This is because the XRP Ledger is designed so that a new account is activated only when it first receives XRP, the network's native token. Eight seconds later, 185.01M XRP was deposited to the same address, which created the account. Five Binance XRP wallets were then drained, and the theft began in earnest.

Source: Etherscan

Over the next 20 minutes or so, assets were stolen on Solana, Optimism, Bitcoin, Tron, Ethereum, Arbitrum, Avalanche, and other chains. At around 8:05 a.m., a second outflow occurred from wallets on Avalanche and Polygon. The stolen assets totaled $6.36B, as listed below.

1.2 How Binance and the Ecosystem Responded

Right after the incident, a series of responses followed, starting with Binance itself and extending to the projects whose tokens were stolen and to DeFi protocols.

Source: Binance

Binance halted withdrawals immediately after the incident. About five and a half hours later, at 10:36 a.m. on October 30, it announced a temporary suspension of deposits and withdrawals and pledged to cover all losses in full. An hour after that, Binance shared its initial findings. It said a DevOps engineer's laptop appeared to have been compromised, allowing the attacker to access a service container and submit unauthorized withdrawal transactions. It added that there was no evidence that wallet private keys had been leaked.

Responses also followed at the project level.

Source: Paolo Ardoino

Tether was the fastest to act. At 6:01 a.m., shortly after the incident, it began freezing addresses linked to the attack. It froze $1.567B in USDT, which went a long way toward bringing the situation under control quickly. USDT0 also paused transfers between Ethereum and Tron as a precaution.

Source: Spreek

What stood out most was Circle, which froze $823M in USDC at around the same time as Tether. This was a fast and highly unusual step for Circle, which had long been criticized for not freezing funds in previous hacks, however large. It is a sign of how serious the situation was.

Source: Arbitrum

At the chain level, Arbitrum moved the fastest. At 9:08 a.m. KST, its Security Council issued an emergency state update that moved the stolen ARB and ETH from the attacker’s address to a separate holding address. This is the same method Arbitrum used to freeze funds during the KelpDAO hack. Optimism used the same approach to forcibly move 44M OP out of the attacker’s address.

Source: Jack McDonald

Ripple suffered heavy losses, with about $380M stolen in XRP and RLUSD alone. Yet action on RLUSD, the asset that could be frozen, came relatively late. Of the 88.6M RLUSD stolen, about 40.5M was frozen, while 48M was swapped into ETH and moved out.

Source: Aave

Among protocols, Aave was the first to respond. Unfortunately, before the stolen USDT and USDC were frozen, the hacker had already deposited about 60M USDT into Aave as collateral and borrowed ETH against it. Aave then froze its V3 and V4 markets as a precaution against further borrowing.

Source: Compound Community Forum

Compound Finance also froze its main lending markets on Ethereum, Optimism, Arbitrum, and Base as a precaution, which kept the damage from spreading further.

The known actions taken by individual projects are as follows.

• World Liberty Financial: Froze about $75M in USD1 and WLFI.
• Synthetix: Used admin privileges to forcibly recover 8.41M SNX and move it to the protocolDAO's Safe wallet.
• The Sandbox: The multisig that administers the token contract forcibly recovered 58.4M SAND.
• Pundi X: After contacting Binance, froze 3.7M PUNDIX in the attacker's wallet and moved it to a Binance address.
• Beam: The multisig that administers the token contract directly burned 984M BEAM held in the attacker's wallet.

As a result, more than $2.8B of the stolen assets was frozen or recovered.

1.3 How the Stolen Funds Moved

Source: Blockaid

As with most large-scale thefts, the funds stolen from Binance were not laundered right away. Instead, most of the capital was swapped into native tokens that cannot be frozen and then spread across many addresses. Assets like these are traded over the counter or laundered over a long period, so they need to be tracked continuously. For example, about 5% of the funds from the $1.4B Bybit hack in early 2025 can still be traced onchain. In the Drift hack this April, more than 98.8% of the funds have yet to be laundered (see LazarusBounty).

Source: SomaXBT

The Tron-based assets moved in especially complex ways. Right after the attack, they were spread across Ethereum, Bitcoin, and Arbitrum through a range of routes, including Relay, THORChain, Chainflip, Symbiosis, USDT0, and Across. Some of them reportedly left through routes where withdrawal addresses are relatively hard to identify, such as the Bitget Wallet bridge and Bridgers.

Source: ZachXBT

Some of the assets laundered through THORChain were also merged with funds from the September Bitget hack, which had been attributed to the North Korean cybercrime group TraderTraitor. This effectively confirmed that North Korea was behind this incident as well.

What deserves particular attention here is the stance each protocol took toward the laundering of stolen funds. Circle, which had been among the most reluctant to freeze hacked funds, was among the fastest to act this time. THORChain, on the other hand, said that forcibly halting transfers was practically impossible because the network is decentralized.

THORChain has consistently held this position on the movement of stolen funds, and it has drawn controversy every time. During the Bybit hack in February 2025, Lazarus used THORChain as its main route for converting stolen ETH into BTC. Some node operators tried to pause Ethereum trading, but other nodes quickly reversed the move. In the KelpDAO incident this April, most of the funds that had not been frozen on Arbitrum were also converted into BTC through THORChain. In the Bitget case in September, Bitget publicly asked THORChain to block the attacker's addresses. THORChain refused, saying it had no mechanism to block individual swaps and could only halt trading across the whole network or on a specific chain.

Interestingly, THORChain moved at a completely different speed when its own funds were at stake. On May 15 this year, about $10.7M was stolen from one of THORChain's Asgard vaults. The cause was a malicious node operator who leaked key information during the signing process. Node operators quickly reached agreement on Discord and then halted trading across the entire network through an on-chain vote. The halt lasted about five weeks. This stands in contrast to external hacks, where gathering consent from at least two-thirds of the nodes took time and the answer was usually not to intervene.

Source: FBI

In a statement based on its initial investigation, the FBI formally named TraderTraitor as the perpetrator. As part of its response, it singled out THORChain node operators and asked for their cooperation. A THORChain co-founder replied, in essence, that every transaction passing through THORChain can be traced. In the end, THORChain took no specific action over this incident. Ironically, however, a block reorg on Ethereum on October 31 caused an error in THORChain, and trading on the network was temporarily halted. This also put the attacker's laundering on hold.

How to handle assets stolen in hacks has also been debated for a long time. Last year, Sui froze stolen funds through an emergency upgrade right after the Cetus hack. Back then, opinion was sharply divided between those who criticized Sui as a centralized chain and those who argued that making victims whole should come first. In this incident, funds were frozen at many levels and in different ways, by stablecoin issuers, chains, and projects alike. Even so, such criticism has been hard to find.

I have mixed feelings about this. The quick freezes that stopped the damage from spreading are clearly impressive and positive. At the same time, I feel a certain unease. Attackers who watched this incident now know what can be frozen and what cannot. In the next attack, they will dispose of freezable assets even faster, which will leave less time to respond. As it becomes clearer which assets and routes allow admin intervention, stolen funds will increasingly flow to routes like THORChain, where active intervention is unlikely. The chances of tracing those funds will also shrink more quickly.

2. Root Cause Analysis

Binance first disclosed how the attack unfolded in a preliminary report on November 3. It said it was withholding some technical details because they could be exploited in future attacks. Even so, what it did disclose confirms much of what had been inferred from on-chain data early on. This section reviews the intrusion path described in the report alongside the onchain record.

2.1 How the Infrastructure Was Breached

Source: Binance

Binance's initial report stated that the attack was not a one-off breach that began with a single laptop. Instead, it was a multi-stage operation carried out over several months through fake job interviews, malware, and internal AI tools. Combining the report's account with the on-chain record, the timeline is as follows.

• June: Wallet DevOps engineer A searched for and installed a popular AI coding tool, and in the process downloaded a tampered Homebrew installer. Binance's security team detected the anomaly, replaced the device, and rotated all related credentials. In the process, however, A's role and information about colleagues on the wallet infrastructure team were exposed to the attacker.
• September: Software engineer B was contacted on a legitimate job platform by someone posing as a project director. In the first interview, a person posing as an HR representative built trust by showing social media accounts filled with personal photos and videos. Near the end of the second interview, B was asked to download an assignment onto a work computer. Malware hidden in the assignment replaced legitimate development tools with malicious versions during installation, and the security tools in place at the time did not detect it.
• October 20: From B's computer, the attacker used an internal AI tool as a foothold to take over the computers of A and C, another wallet software engineer. On A's computer, the attacker then found a token with container deployment permissions.
• October 28 to 1:47 a.m. on October 30: The attacker sourced funds from Tornado Cash, deployed a sweeper contract, and rehearsed the attack.
• 2:15 a.m. to 4:56 a.m. on October 30: The attacker logged into C's computer, deployed a container using credentials stolen from A, and ran the attack script.
• 5:04 a.m.: The first abnormal withdrawal attempt occurred.

This sequence follows a fairly classic playbook for breaching platform infrastructure, and it recalls the CoinsPaid hack in 2023. In that case, the attacker posed as a Crypto.com recruiter and reached out through LinkedIn messages. The attacker reportedly spent six months studying CoinsPaid's org chart and role-based permissions to find a target. The malware was also delivered the same way as in this incident. After running a hiring process with several rounds, the attacker had the target install malware disguised as an assignment in the final coding test. The main difference is that a DevOps engineer's mistake greatly shortened the time it took the attacker to learn about Binance's wallet infrastructure team.

If anything, what is unusual about this incident is that AI tools appear again and again along the attack path. In June, a popular AI coding tool served as the bait. In October, an internal AI tool became the stepping stone for reaching other engineers' computers. An AI tool that can run commands on a developer's computer and access multiple systems is, in effect, another insider with broad privileges. The permissions given to internal AI tools will become a new item on exchanges' security checklists.

2.2 EIP-7702 and the Sweeper

On Ethereum, the attack targeted the hot wallet labeled Binance 14 (0x28C6...1d60). Unusually, the attacker made use of EIP-7702.

EIP-7702 was introduced in Ethereum's Pectra upgrade in May 2025. When an externally owned account (EOA) signs a delegation authorization, the feature attaches the code of a specific smart contract to that address. From then on, every call to the address runs according to the attached code. The delegation stays in place until the same address signs a new authorization that overwrites it. In personal wallets, the feature is often used to bundle several transactions together or to let someone else pay the gas fees. Turned around, the same feature means that anyone who can get a wallet to sign a delegation to their own contract can take over the wallet. From that moment on, every asset in it can be moved by their code. This is exactly what the attacker was after.

The attacker spent a good deal of time preparing for this. The attacker's operating address (0x7C86...5CA0) received its first funding at 4:39 p.m. on October 28, withdrawing 0.1 ETH from Tornado Cash. At 11:28 a.m. the next day, it deployed the first version of a sweeper contract with a function that moves all specified tokens and ETH at once. Then, from 10:51 p.m. on the 29th to 1:47 a.m. on the 30th, the attacker ran rehearsals using three wallets under their control. Each run covered the entire process, from delegation to asset transfer, with amounts between $2 and $6.

Source: Blockaid

At 5:24 KST, three minutes after the delegation took effect, the operating address called the sweep function. In a single transaction, more than 60 types of assets worth about $2.53B, including 167,464 ETH and 1.615B USDT, were moved to the receiving address (0x5227...2f8c).

The problem was that the delegated authority remained in place after the first theft, which led to further losses. Binance 14 had execution rights over a smart account owned by Binance, and the attacker used a general-purpose execute function to drain 823M USDC from that account. Binance's deposit consolidation system also kept collecting deposits into Binance 14, so the attacker swept the newly arrived assets again. The attacker kept taking new assets for more than two hours after the first sweep, and the delegation remained active for more than three hours.

Because EIP-7702 was used in this attack, the feature itself came under scrutiny. Those who argue that EIP-7702 bears responsibility make the following points.

• Without delegation, the attacker would have had to send a separate transaction for each token to move more than 60 assets. Those transactions would have competed with Binance's normal withdrawals for nonces, and many would have failed. Delegation let the attacker move $2.53B with a single call.
• In the past, even if a signing system was breached, the attacker had to obtain a new signature for every transaction, and cutting off access stopped the outflow. Delegation hands over the entire account at once and removes the time needed to detect and respond. In fact, the attacker kept taking new deposits for more than two hours after the first sweep without any signature from Binance 14. Withdrawal limits and rate limits are security basics because they buy time to respond, and delegation takes that time away.
• Ordinary accounts that existed before Pectra never agreed to this feature. It is unreasonable to lower the security of existing users and then tell them to use a different wallet if they feel unsafe. Addresses that have no need for delegation, such as hot wallets, should have a way to register that they will never use it.
• The only way to remove a delegation is for the same wallet to sign a new authorization pointing to the zero address. Since the delegation stays with the address even if the key is replaced, removing it means signing again with the very key that was compromised.

On the other side, those who argue that EIP-7702 is not to blame make the following points.

• The delegation authorizations were validly signed with Binance 14's key, and the chain applied them as designed. The problem lies not in a protocol flaw but in the misuse of the signing infrastructure.
• An attacker able to sign 50 delegation authorizations could just as easily have signed ordinary transfers. In fact, at the same time, Binance 16 and wallets on nine other chains were drained with ordinary signatures alone, without EIP-7702.
• Smart contract wallets with access policies already exist, and Binance simply chose not to use them.
• A delegation blocklist would require an extra state lookup for every delegation transaction, and the list would have to be maintained forever. That would make all users bear the cost of a fix meant for a handful of exchanges.

I agree that EIP-7702 itself is not the problem.

Responsibility for how a feature is used lies with whoever uses it, and EIP-7702 is not mandatory. Delegation cannot happen under any circumstances unless the wallet's key directly signs a delegation authorization. An exchange's withdrawal operations never require signing one. The fact that Binance's signing system produced 50 delegation authorizations is, in itself, a failure of signing policy.

Binance also had a window to respond, because the moment the delegation took effect, code was attached to Binance 14. For the 3 minutes and 24 seconds before the sweep, this state change was visible on-chain to anyone. In my view, an exchange of Binance's size could reasonably have prepared for this. It could have built a system that immediately flags anomalies such as code being attached to a hot wallet through EIP-7702, and kept a pre-approved revocation transaction on hand.

2.3 What Leaked Was Signing Authority

Major exchange hacks in recent years, especially those attributed to North Korea-linked groups, have followed a recurring pattern. Rather than stealing hot wallet private keys directly, attackers breach internal infrastructure to hijack signing authority or swap out the data to be signed.

• May 2024, DMM Bitcoin: About 4,502.9 BTC was stolen. According to the FBI, TraderTraitor posed as a recruiter and compromised the computer of an employee at Ginco, a wallet software provider. Through that access, the group manipulated a legitimate transaction request from a DMM employee.
• July 2024, WazirX: About $235M was stolen. The multisig wallet's signers approved what the custody provider's interface showed as a normal transaction. What they actually signed was a transaction that handed over control of the wallet.
• February 2025, Bybit: The attacker went through a Safe developer's computer to manipulate the signing screen. The signers approved what they believed was a normal transaction, but it actually handed over control of the cold wallet.
• September 2026, Bitget: The attacker broke into the backend of the wallet infrastructure and forged transaction data. Bitget stated that the attacker neither obtained private keys nor forged users' withdrawal requests.

Seen in this light, the most unusual aspect of this incident is the delegation authorization itself. A delegation authorization is not a withdrawal transaction. Even though an exchange's withdrawal operations never require one, Binance's signing system produced 50 of them. Suppose the signing system did not interpret what it was signing, or the attack bypassed it completely. In that case, it would have had no way to tell whether a request was a withdrawal, a delegation authorization, or something else entirely.

Attacks of this kind cannot be stopped by multi-party computation (MPC) or hardware security modules (HSMs) alone, though financial services commonly adopt both to protect keys. These tools only keep keys from leaking out, and they do not control what those keys are used to sign. Unless the signer interprets what it is about to sign and independently checks it against policy, this area will remain open to attack.

3. Implications

3.1 Information Needs Closer Verification

What concerned me most while the incident was being contained was how fast false information spread.

Right after the incident, claims spread through the community that Binance had staged the hack to shake the market. Within hours, however, third parties such as Tether and Circle had frozen about $3B. Part of the stolen funds had also passed through THORChain and mixed with funds from the Bitget hack. These facts would be hard to explain if Binance had staged the attack. Claims denying that North Korea was behind the incident have fueled these suspicions further. However, the FBI has already named North Korea, and the circumstantial evidence so far makes it hard to deny that TraderTraitor carried out the attack.

Source: X

On November 1, @doomerfied, an account known for posting fake news, made a post about a Binance DevOps engineer. It claimed the engineer had been romantically involved with a North Korean agent and had left a laptop unattended on the day of the incident. A media outlet's account then reposted the claim, and it spread quickly on X. The post also spread fast through Korean Telegram communities, and many people still believe the romance scam story is true.

When the public is deeply confused by a major hack, fake news like this does nothing to help the recovery. At a time when the flow of information is overwhelming, influential media outlets need to verify what they publish far more rigorously.

3.2 Where Should Individuals Keep Their Assets?

This incident was fortunately well contained, but that outcome owed much to the fact that the victim was Binance. Binance raised $6.34B from its own resources without outside borrowing. Net outflows on the first day of reopened withdrawals were only about 2.1% of total assets, according to Binance. In 2025, Bybit had to borrow ETH from other exchanges and institutions to cover its losses. With that in mind, I believe a bank run would be unavoidable if an incident of this scale hit any other exchange. The intervals between attacks on major exchanges are also getting shorter, from Upbit last November to Bitget in September and now Binance.

The problem is that funds leaving exchanges have few good places to go. Personal wallets are just as much a target.

In October, an unidentified component was found inside devices sold through CryptoBilis, an authorized Ledger reseller in Southeast Asia. According to Ledger's security team, the component read what was displayed on the device screen. When the recovery phrase screen appeared, it decoded the 24 words and sent them out over an LTE connection. Losses from the tampered Ledger devices are estimated at more than $90M. The same reseller also reportedly sold tampered devices from Trezor, which is one of the largest hardware wallet makers along with Ledger.

Software wallets are no different, as Trust Wallet showed last December when a malicious update to its browser extension led to the theft of about $7M. This year, a series of supply chain attacks on various crypto wallet libraries has kept people on edge. Even so, users appear to be leaning toward self-custody. A report citing a data provider's figures says about $4.5B left Binance in the 24 hours after withdrawals resumed. Of that, only about $368M went to the other top-10 exchanges. In other words, 90% of the outflows went not to other exchanges but to addresses outside them.

Source: Ambire

Against this backdrop, wallets built on open software and open hardware could be a good alternative for individuals. As it happens, Ambire unveiled Ice, an open-source hardware wallet, on the same day as the Binance incident. Ambire published the wallet's hardware design, circuit board files, and firmware, so that anyone with the right equipment can build the wallet themselves. It also designed the wallets it sells with a transparent casing so that anyone can see inside.

Of course, open source does not automatically mean safe, and few users will actually check a device against its published design. Still, I expect that as incidents become more frequent, people will move toward tools they can check and verify for themselves. Demand for open-source self-custody wallets will grow accordingly.

3.3 The Fast Response from Binance and the Crypto Ecosystem Deserves to Stand as a Model

Binance clearly responded quickly, promising on the day of the incident to cover all losses in full. On the same day, it said it had set aside $6.34B in company funds. On solvency, the issue users were most likely to worry about, it responded with Proof of Reserves.

Withdrawals also resumed quickly, in phases starting at 3 p.m. on November 1. The first phase covered 15 networks and assets, including BTC, ETH, USDT, USDC, BNB, SOL, and XRP. By 9:36 p.m. the same day, everything in the first phase was back to normal.

According to Binance, $4.649B was withdrawn and $1.01B was deposited in the roughly 9 hours and 30 minutes after withdrawals resumed. Net outflows came to $3.64B, or 2.1% of total assets of $171B. On DefiLlama, 24-hour net outflows briefly climbed to about $7B before falling to less than half that figure.

What I find most notable is that Proof of Reserves finally did its job this time. Binance introduced it right after the collapse of FTX in November 2022. At the time, it was criticized for showing balances only at a single point in time without revealing total liabilities. That criticism remains valid today, but given that billions of dollars were leaving all at once, I think Binance responded quite quickly.

The response outside Binance was also impressive. As noted earlier, Tether and Circle began freezing funds within an hour of the incident. The Arbitrum Security Council and individual token projects used their admin powers to lock up or recover assets. Aave and Compound paused their markets to keep the damage from spreading into DeFi. In this incident at least, the industry as a whole put containment ahead of competition. As discussed above, however, this speed was possible partly because the power to intervene existed in many places. It also leaves the industry under pressure to respond even faster next time.

4. Others’ Opinion

4.1 juno, Lead at ChainLight

Rather than tracing stolen funds, I work further upstream, on the security of crypto infrastructure itself.

Whenever I do forensics or post-incident analysis after a security breach, I always end up asking the same question: “Was there really no way to know this in advance?” Looking back, there are cases where there were more ways to catch warning signs early than one might expect. Of course, not every attack can be predicted. But predicting an attack and detecting an abnormal situation are two different problems.

Even in this incident, there was a window of about three minutes, brief as it was. From an exchange’s point of view, an EIP-7702 transaction coming from its own hot wallet is abnormal in itself. Even without knowing the exact attack technique, it is possible to define in advance that this should never happen. That is why I believe security is not only about finding as many vulnerabilities as possible. The job of security extends to defining what counts as abnormal, verifying that it can actually be detected, and continually running drills to confirm that the response works once something is detected. Of course, finding and listing every abnormal case is extremely difficult, and some would say it is impossible. I do not believe every case can be covered either. But that is no reason to give up. In the end, the only option is to keep thinking from the attacker’s perspective and fill in the gaps one by one.

There is an even more important issue here. No matter how well detection and response are handled, some attacks cannot be stopped if the system was poorly designed to begin with. This was also what surprised me most about this incident. When I first heard that an attack using EIP-7702 had taken place and that other chains had been drained as well, my first thought was that the keys themselves had been stolen, rather than that the signing system had a flaw. That is because I believe a signing system should contain only the minimum code and validation logic, and should be isolated so that it cannot be reached at all from the production environment or through ordinary access paths. Network access should be kept to a minimum, and authentication and access controls should be strict.

At Binance’s scale, I expected mitigations to be in place even for the process of splitting or merging transactions. Under such a setup, the signer would receive only the minimum information it needs, and the validity of each request would be verified in an independent environment. For example, the signer would take only the recipient address and the amount as input and assemble the transaction itself. It would release a signature over an arbitrary hash only when a separate offline multisig signature was added. Implementing this kind of architecture properly is quite difficult. Even so, it seems to me that a company like Binance should have invested enough resources in this area.

That said, my point is not whether a particular implementation was right or wrong. It is about how much the last line of defense is designed to trust the judgment of the systems above it. Some risks cannot be solved simply by adding detection rules, and those risks can only be addressed by changing the architecture. In practice, as you build response playbooks and run drills again and again, you fairly often reach a moment when you realize, “This design cannot structurally prevent this attack.” I actually consider that moment an important discovery. That is the moment to redesign the system and think seriously about security at the design level, in other words, secure by design.

There is one more thing that matters just as much as technical design: operational security, or OPSEC. A search for Binance on LinkedIn turns up a great deal of information about who works on which team and what they do. Finance is also a form of critical infrastructure. How well is the operational security of the people who handle these systems actually managed?

This brings to mind the case of MakerDAO, now known as Sky. MakerDAO had a provision called “2.6.6 Aligned Delegate Operational Security.” Under this provision, if someone reported an operational security violation by an Aligned Delegate (AD), that AD would lose their status, and half of their deposit would be paid to the reporter as a bounty. Several ADs did in fact lose their status under this provision between 2023 and 2024. In one case in April 2024, the reporter received a bounty of 20.84 MKR, worth roughly KRW 70 to 80 million at the time. The reason this case is striking is simple. It treated operational security not as a matter of personal habit, but as an essential condition for keeping the system safe.

The people in charge of core crypto infrastructure are, in effect, the keepers of an enormous vault. Even if nothing is actually stolen, a leak of the knowledge they carry about the system’s design and internal operations can pose a major risk to the company. Their roles demand a correspondingly high level of responsibility, and I believe companies should treat and compensate them accordingly.

Finally, there is a reason I expect all of this to matter even more in the future. Whether due to AI or not, attacker productivity is becoming fundamentally different from what it was in the past. If attackers used to be single-core, today they feel almost like they have unlimited cores. They can turn their own knowledge into agents, automate attack techniques, and run tasks that once required manual work in parallel and at scale. The cost of carrying out attacks is falling, and attack cycles are getting shorter. If defenders remain stuck in a “find as many vulnerabilities as possible and patch them” approach, it will be hard for them to keep up with this pace.

That is why I think security strategy going forward comes down to three things.

1. Detection: Abnormal states should be detectable even when the attack technique is unknown.
2. Response: Playbooks should be built and practiced repeatedly so that, once something is detected, damage can actually be prevented or reduced.
3. Design: For risks that detection and response alone cannot stop, the system should be redesigned so that the attack itself becomes difficult to carry out.

And all of this must rest on rigorous operational security.

Ultimately, what matters is not predicting every attack in advance, but building systems that can withstand attacks no one saw coming. Finding vulnerabilities is of course important, but the scope of security should also include detecting anomalies, responding quickly, limiting damage, and, when necessary, changing the architecture itself.

I want to offer my support to everyone working to protect the crypto ecosystem.

4.2 gss1, Senior Researcher at OtterSec

In a large-scale security incident, the extent of the damage is not determined by the attack alone. How quickly the situation is assessed after the incident, and whether the relevant organizations can work together to prevent further losses, are also key factors. The Binance hack showed both the importance of incident response capabilities and the potential of industry-wide cooperation. Although about $6.3 billion in assets was stolen, it has been announced that around $3 billion was frozen through the cooperation of Tether, Circle, and other industry participants. This shows that quick cooperation can play a significant role in limiting the damage from a major security incident. However, the incident also exposed the limits of existing response systems. Chainflip said that funds rejected by its AML screening were refunded to new addresses and then deposited again, which allowed some transactions to pass the checks. Symbiosis also acknowledged that its existing screening system had limitations, even though it had identified the movement of stolen funds and contacted Binance. These cases suggest that even when individual services run their own monitoring and blocking systems, there are limits to how well they can stop stolen funds that move quickly across multiple protocols and blockchains.

This incident also raises another question. If the same incident had happened to a relatively small project rather than Binance, would the same level of cooperation and rapid response have been possible? I believe there needs to be an environment in which every security incident can be responded to quickly, regardless of the scale of the damage or the project’s influence. Emergency response channels such as SEAL 911 already exist, but cooperation among exchanges, stablecoin issuers, blockchain projects, and cross-chain bridges needs to be strengthened further. In particular, if incident reporting procedures were standardized and verified attacker addresses and the flow of stolen funds could be shared with the relevant teams in real time, further movement of the funds could be blocked more effectively. Of course, verification procedures must also be put in place to prevent false reports and unjustified asset freezes. I hope this incident becomes an opportunity to improve emergency incident response across the industry, so that anyone, regardless of project size, can receive fast and effective support.

4.3 jinmo123, Co-founder of QED Audit

AI has ushered in a “Great Age of Hacking,” but we should distinguish incidents where AI carried out the hack itself* from those where AI served as a pathway for the attack. The Binance case falls closer to the latter. Fake Homebrew links promoted through Google ads have been reported repeatedly since January 2025, and fake job interviews are a tactic North Korea has used for years. What was new was that the attackers moved through an internal AI tool to reach the engineers who manage the wallet infrastructure.

In the same vein, one concern is that a growing number of companies, like Coinbase, are routing all AI use across the organization through a single LLM gateway. Such a gateway is in a position to alter tool call outputs and slip malware onto users’ PCs. If its configuration access is compromised, there is no way to watch the watcher. That said, staying away from AI is not an option either. Now that AI has sped up attackers’ lateral movement, defenders will also find it hard to keep pace without AI. Although an internal AI tool served as the pathway for the attack, the first item in Binance’s response plan is “expanding AI-based anomaly detection,” which is ironic but necessary.

Detection is no easy task either. The zero-day malware from September went undetected by EDR, and tasks such as EDR evasion, which require repeated trial and error, play directly to AI’s strengths. At the same time, AI churns out large volumes of attempts that fall outside existing patterns, burying the real signal in noise. This year alone, Binance has blocked 57 attack attempts linked to North Korea. With other targeted attempts mixed in among them, few security teams would notice that an infection caught in June was connected to an attack four months later.

It may sound vague, but in the end, the fundamentals still hold. Least privilege, zero trust, and EDR should apply equally to AI systems. Third parties and employee behavior, which have been left out of scope, should also be treated as part of the attack surface. There is no universal answer yet for security in the age of AI, but there are still some encouraging signs. The effectiveness of AI-based code scanning is becoming better known, and asset freezes now happen much faster than they did after the Bybit hack. There is also a growing consensus that “code is law, except when it’s a hack.” Still, this October was the worst Cybersecurity Awareness Month yet. Hopefully, things will look different a year from now.

*There is not enough evidence to regard the Binance case as a hack started by AI. However, it has always been an open secret that almost any part of the internet can be hacked. It was just that few people had both the motive and the ability to do it. Security was a form of arbitrage between the cost of an attack (knowledge, information, and time) and the value of the assets at stake. AI has significantly lowered the cost of attacking across the board. In my view, the recent string of hacks is the result of a growing pool of hackers, or of hacking AIs.