Table of Contents
Binance was hacked and the hackers employed some strategies to escape with the loot that are worth exploring. Chainalysis says these are strategies they have not seen before. But we have seen these patterns before – in a paper we wrote with some academics which will be presented at an academic conference in a few weeks. That is a coincidence nobody saw coming.
The post-hack laundering serves as a sort of independent validation of our results. Web3 hacks are a bit odd compared to traditional finance in that the public gets most (or all) of the details of hacks and laundering and such in short order after an incident occurs. And because these incidents are so frequent we can study many incidents to develop theories and then test theories against new incidents that were not in the sample set used to develop the theory. The cycles can run tightly in time.
From a scientific standpoint this is fantastic. It is bad for impacted users but the hacks are gonna happen whether or not anybody studies them. And there are glimmers of hope in the ease with which tools can be proposed and tested. If you have a theory about murders or bank robberies or something in a more traditional criminal area: think how long it is going to take to develop and test that theory. So we are going to use the Binance hack as an opportunity to test a theory developed in 2025 and first published as a draft in early 2026.
The Paper
Our paper is built around a pair of connected results. The first is that retrospective blacklisting does not capture most of the funds stolen in hacks. This is not exactly shocking as a backward-looking process does not sound like the kind of thing that will stop everyone upfront. But it was important to establish the details. Specifically we found that:
- The vast majority of value escapes blacklisting.
- Addresses holding non-blacklistable tokens continue to transact in non-blacklistable tokens after sanctions designations are published.
- These features are robust across type of hacker and attack.
Addresses continuing to transact post-designation tells us there are still myriad service providers that will accept funds from designated sources. As we will see it is perfectly plausible those services were not aware of the provenance of the incoming funds when they accepted them. Of course it is also possible some or all of those services knew exactly what they were doing. The empirical results are not about intent or knowledge, they are merely about observed behavior. The paper summarizes this as:
adversaries drain wallets before blacklist announcements, and enforcement remains incomplete after official designation. Improving investigation speed alone cannot improve operational effectiveness: platform-level implementation failures create independent evasion windows across the fragmented crypto ecosystem.
And this is where the second connected result comes in. We develop a simple evasion model that provides straightforward strategies which allow an attacker to effectively outrun tracing efforts. We do not mean the attacker can escape forever – we mean merely that an attacker can run up the computational requirements for tracing sufficiently that they can still send tainted funds to services that are trying to comply but face impossible time bounds in doing so. Our model shows that natural in-built features of certain kinds of payment networks asymmetrically advantage attackers and make retrospective blacklisting a poor overall strategy.
The logic here is simple. If you are able to route stolen funds through a network complex enough that an exchange requires an hour (or a day or whatever interval of time) to complete tracing and identify the source this presents the exchange with two choices: hold funds for long enough for any conceivable evasion strategy to be untangled or do not hold funds and risk accepting tainted deposits.
If your evasion strategy requires 5 seconds to untangle this is not much of a constraint. Our contribution is to show how simple strategies can run up the scoreboard such that exchanges face a real dilemma they cannot settle by just spending more on compliance. And as long as some exchanges come down on the "we do not want to impose very long delays on incoming deposits" side of the line then hackers can escape with a good fraction of their loot. Hacking thus remains a profitable enterprise. The model shows how evasion is both straightforward and reliable without employing any especially fancy techniques. Notably these are the techniques we see employed in the laundering of the Binance hack proceeds.
Our strategy exploits a key asymmetry in systems based on public key cryptography: there is no limit to the rate at which you can create addresses offline. An attacker can prepare arbitrarily many fresh addresses in advance. And an attacker can prepare networks of addresses to pay transaction fees all in advance. All without giving away any sign an attack is incoming.
The key asymmetry is that blacklisting is constrained by network bandwidth while address generation is not. We then use this observation to develop simple strategies that reliably outrun blacklisting and associated tracing efforts.
Thus an attacker can prepare keypairs, gas and automated tools to make tracing as difficult as possible. If the attacker is smart and well-prepared this will manifest as something like:
As Chainalysis investigators continue to trace funds stolen from Binance, we are observing laundering patterns we have not seen before. Thousands of transactions in a short period suggest that the attackers are using automation to obscure the trail of funds. Rather than simply moving funds onward, they repeatedly circulate them among addresses, often sending funds back to addresses involved earlier in the sequence.
Many addresses follow a consistent pattern: they receive exactly 1 TRX, then receive additional funds, then forward funds to other addresses. This repeated sequence suggests a programmatic process for moving and redistributing the stolen funds.
III.B of our paper is entitled "Forwarder Node Strategy" and describes exactly the second part of the quoted comment.
Just to be clear: the paper was not written to educate or instruct or otherwise assist attackers. But attackers obviously have a huge incentive to think about how to launder their loot. As we do not rely on any particularly deep or complex analysis, competent hackers will figure this out either through careful planning or as a response to foiled laundering efforts. As is so often the case the insight comes from assembling the pieces and looking at what results and not from designing new tools from whole cloth.
The Hack
Intrusion
While we do not yet know exactly what happened, there is some information available which matches the usual pattern. Binance said the incident may involve a compromised laptop and that it found additional points of breach. Should that laptop have had access to private keys securing funds? Of course not. Is this a movie we have seen many times before? Pretty much yes.
Binance also says the attacker used EIP-7702 in the exploit. The whole smart wallet thing has long been a glaring attack vector and a massive security hole. 7702 replaced EIP-3074, an earlier proposal, and was pitched as a safer, improved alternative. Not only did we never buy that, we talked about this all being a bad idea years ago and those comments were even quoted in coverage about this that we only just found while searching for our own original comments. It is as unsurprising this functionality was used in the Binance attack as it was to find that a majority of EIP-7702 authorizations are linked to attacks of one sort or another.
EIP-7702 makes it easy for an address to pass control to an arbitrary block of code and have that code run so quickly and irreversibly that nobody can stop it in time to interdict a hack. When you say it that way it becomes clear how an attacker might leverage such a feature. Just RTFM as they say.
So we are only slightly interested in the exact details. It seems this was a fairly standard social engineering attack of the fake-interview-with-malware variety. We are quite interested in the details if, somehow, there turns out to be a novel twist. But we do not expect anything interesting here. Only time will tell.
Laundering
This bit, however, absolutely is interesting. The attacker is doing two things at scale which should help launder the money and which match the model in our paper.
First up is the large scale use of forwarders. The basic idea here is to set up addresses with off-chain automation or simple contracts which do nothing but send along whatever they receive to somewhere else. Exchange deposit addresses are a specific type of forwarder. For a deposit address the thing exists to help do user account accounting. But there are plenty of other reasons to use this kind of functionality.
And by far the simplest and most straightforward reason to employ forwarders is to create distance. Imagine a simpleminded service that will not accept deposits directly from sanctioned addresses. You can evade that rule simply by interposing a forwarder between a sanctioned address and the service. Yes proper tracing done later will figure this out. But you do not care if you have already withdrawn your funds from the service. Think like an adversary here. We are not trying to convince regulators the compliance works – we are trying to break it.
More generally, adding more distance and more addresses and transactions will slow down tracing. Tracing is just applied graph theory and we know the computational limits for all the major relevant and important questions in graph theory that relate to tracing.
It is here we connect to the second interesting feature of the laundering effort. Many in tracing refer to long stacks of forwarders that feed into each other as "peel chains." This is an industry term for a simple structure that adds many addresses and makes manual tracing difficult or impossible but does not actually introduce any obfuscation. If you take funds from a hack and run them down a chain of thousands of addresses which do nothing but forward funds on down the line then a properly configured computer can figure things out easily. Yes, you will not be able to manually click through all the transactions. And yes, you can also split the funds up and then reassemble them in ways which leave no ambiguity around what is happening but are still too messy for manual or simpleminded analysis.
You are best off thinking of peel chains as long lines. Yes this makes life marginally more difficult for a computer because tracing down a line of 100 links is 10x harder than one of 10 links. But computers are fast and blockchain transactions are limited to the blockchain's bandwidth. So maybe you can keep up. Just buy a faster computer maybe.
The Binance attacker is doing something smarter. Rather than using lines they are building dense webs of overlapping flows as "they repeatedly circulate them among addresses, often sending funds back to addresses involved earlier in the sequence."
Here things are much harder. If you build a chain of N nodes the time required to trace down that chain is N. If you are building that chain at the maximum rate the blockchain can process transactions then tracing can keep up so long as the tracing computer is, in some sense, at least as fast as the blockchain. We say "in some sense" because these are not identical operations. But there is a linkage and both things grow at the same rate.
Not so if you create dense networks. Now the tracing grows as N^2. 10x the size is 100x harder. 1000x the size is 1 million times harder. The intuition here is that when you recycle through addresses the number of possible traces grows far more quickly than the blockchain because funds can go many places. Once you connect all the laundering addresses with inflows and outflows the tracing system needs to be much faster than the blockchain. Re-looping and passing funds around in circles are both ways to increase density and explode the number of possible traces.
The important feature here is the squaring on N^2. For every doubling in the attackers work the tracing gets four times harder. If you can run that advantage out for hours or days you will be way ahead of the tracing.
Now all the services are stuck either holding up client deposits or trusting shorter, approximate, tracing. Binance itself as the target is obviously going to suspend withdrawals in these situations. But no other exchange or bridge or service wants to do that. One could even argue that an exchange which announces it will hold up deposits to wait for proper screening is then on the hook for any mistakes it makes. Nobody wants to do that.
Lessons
This is not the first large hack where blacklisting and tracing failed to secure most of the lost value. It will not be the last. Our paper works through some attacks and subsequent fund escapes in some detail. The tools are not fit for purpose and will continue to fail when they are needed most. This is just life.
But that is not to say blacklisting is uninteresting. Circle has long said it freezes funds only when required by law or at the direction of law enforcement or the courts, and only this year began allowing freezes on urgent law-enforcement requests pending a court order. Yet Circle froze funds here so rapidly it is hard to believe any sort of judicial warrant was produced. Tether too froze quickly. Tether has a longstanding policy of accepting casual requests when Tether deems the request is sufficiently credible so this is a bit different. But questions around the threshold these companies apply to freeze, and the quality of the information they are getting, are both reasonable and prudent.
At a high level: this is an insane regime and the insanity is now on full display. Is security supposed to depend on the whims and good will of random private companies operating within the grey areas of their own terms of service? Further note that any kind of rapid-response tracing is by construction error prone. We are talking about work done under intense time pressure, with limited information, and where the people involved believe they are trying to help a massive collection of innocent victims. That is not the kind of environment that produces carefully considered, cross-checked, well reasoned work with low error rates. Everyone knows this. The well-intentioned make mistakes too. People under time pressure tend to make more mistakes than they would in more relaxed circumstances. This is not controversial.
What we find more interesting, and what is surely a more impactful lesson here, is the clear and irrefutable demonstration that tracing is not the solution to these problems. Once you understand how an attacker can prepare and evade it is clear that tracing efforts always start the race from well behind and they are incapable of running as quickly as their target. They are going to lose.
Now that does not mean 100% of the funds escape 100% of the time. But the structural situation is that attackers have a built-in advantage. As attackers improve the tracing will necessarily become, relatively, worse and worse.
Similarly, as calls increase for issuers like Circle and Tether to freeze assets based on casual requests made under extreme time pressure we are going to see more and more freezing errors. This is inevitable. Errant freezes made in response to a good faith effort to manage a large hack, or for any other reason, can also cause damage.
The long term dynamic is then as follows. Attackers will become relatively more adept than tracers. And freezers will accept relatively weaker claims as the basis to freeze. Bad freezing will eventually do more damage than the value recovered by correct freezes. Our prediction is that the current manifestly ineffective and bad system will continue to be employed until the amount of damage starts to approach the amount of value recovered. At that point web3 will sit on the precipice of an era in which compliance efforts inflict more pain than they recover in value for victims. Some day soon the absurdity of it all will become too obvious to ignore.
