A valid signature is not yet a safe decision. What I learn from the Binance incident.

So, one thing at a time: on the evening of 29 October, billions flowed out of a Binance wallet within minutes. The headlines tumbled over each other, the numbers changed by the hour, and the next day the total stood at over six billion dollars, a large part of it frozen by now. What interests me is not the sum. It is the sentence that appears in every analysis: no stolen key, no broken cryptography. A valid signature. For an operation nobody should have signed. That is not a crypto problem. That is an architecture problem, and I know it from banks, from cloud platforms, and for a year now from our own agents.

What happened, as far as known

According to the analyses so far, the wallet "Binance 14" delegated its execution to a foreign smart contract on 29 October at around 20:20 UTC, via the Ethereum function EIP-7702. Four minutes later the outflow began: ETH and stablecoins, around two and a half billion from this one wallet alone. One analysis firm describes the attacker packing fifty authorisations into a single transaction, one of which had the matching nonce. More on that shortly. As the entry point, reports referring to Binance name an engineer's compromised laptop, through which an attacker is said to have reached a service container. A blockchain forensics firm attributes the attack with high confidence to a North Korean group.

All of it is preliminary. Moved, frozen and finally lost amounts have to be distinguished, and nobody outside knows Binance's internal architecture. But the direction is clear enough to learn from.

Why this interests me

Whoever knows me knows that incidents like this have always occupied me. Not because of the headline. Because of the question of what is behind it: how could it happen, which decisions enabled it, which boundary held and which did not. When a complex system fails, I want to know why. Not just where the error was, but which dependencies and trust relationships led to it. You learn more about architecture from that than from any book.

How we investigate this today

Such an investigation used to mean: gather and compare articles, specifications, statements by hand. Today we do it with our agents, split up. One follows the official statements and how they change over the hours. One reads the technical specification and possible attack techniques. One compares the statements of security researchers and looks specifically for contradictions. Then we merge and check which statement is really carried by several independent sources.

That does not make the results automatically right. Several agents can adopt the same error, read the same original report, build a plausible and wrong explanation. That is why every important statement has to be traceable to its evidence. The same principle as with everything we build: evidence instead of claims. The agents do not take the thinking off me. They get me to the right questions faster.

Three levels you must not mix

What EIP-7702 does, in three paragraphs

Ethereum knows two kinds of accounts: those controlled by a private key, and those consisting of code. Since the Pectra upgrade a normal account can delegate its execution to existing smart contract code. That enables useful things, bundled transactions, flexible fees, programmable wallets. But it changes what a signature means.

Such an authorisation contains the chain ID, the contract's address, a nonce, and the signature. With it the account holder does not confirm a single transfer. He confirms: from now on this account may execute the code at this address. The delegation stays until it is replaced or removed. That is a fundamentally different weight from a transfer. Control over the account now depends on the contract's logic, and if the contract belongs to the attacker, so does the account.

And a detail that gets lost in the reporting: one transaction may contain several such authorisations, each is checked individually, invalid ones are skipped. Hence the fifty entries, of which one fit. That does not mean someone guessed signatures, that is impossible with ECDSA. It means someone had a valid signature and did not know the nonce for certain. So the question is not whether the cryptography held. It did. The question is how that signature came about.

The possible attack path

As a hypothesis, not as a reconstruction of Binance's infrastructure, which none of us knows:

The decisive step is the fourth. A container has no financial rights unless the infrastructure gives them to it. If a signing service only checks whether the caller may sign in principle, and not what it is having signed, then the attacker does not need the key. He only needs a service that is allowed to use it. Whether it was like that at Binance is open. That it can work like that is certain.

Why an HSM does not solve it

The reflex after such an incident is: key into the hardware module, then nothing can happen. The module makes sure the key never comes out. Good and right. But if a service sends the module a payload and the module signs what it gets, then the key is protected and the authorisation is abused anyway. Is the payload a transfer? A permission change? A delegation that gives the attacker permanent control of the account? The module does not know, if nobody checks. Protecting the key is not enough. You have to check the meaning of the operation the key authorises.

How I would secure something like this

Finding bugs has become easy

And now the part why I write this in the workshop and not only as an analysis. What happened here used to be specialist work: understand a new protocol feature, hold its semantics against the assumptions of a signing infrastructure, find the gap in between, build the contract, cover the nonce with fifty attempts. That needed people who had months. Today it needs an agent you give the specification and a goal. A week ago I wrote about reverse engineering for everyone: the protection was the cost, and the cost is gone. The same applies to exploits. The attackers have the tools we have, and they need no acceptance.

Why this concerns banks and AI agents

This is not a blockchain topic. Banks have central signing services and payment approvals. Cloud platforms run on service identities and tokens. And AI agents get access to tools, databases and business-critical processes. Everywhere the same question: what happens when a technically authorised component executes an action that is not permitted by the business? An agent can have a valid token and still execute the dangerous command. It can act within its permissions and have effects far beyond its task. I experienced that two weeks ago when our own agent overwrote 169 files: valid permissions, wrong operation, nobody in between.

No better prompt solves that. It needs independent checking, clear boundaries, traceable decisions and mechanisms that hold even when the agent itself is compromised. The executing component must not be the last instance deciding on the permissibility of its own action. No agent signs off on its own work, and no wallet either.

And that applies to the research agents just the same. One that collects sources must not decide that something is true. One that analyses connections must not present a hypothesis as a confirmed attack. One that summarises has to show whether ten articles are independent or one report. Source attribution and the separation of observation and interpretation are not journalistic requirements. They are agent architecture.

What we know and what is open

A big incident justifies no unproven conclusions. A technology is not insecure because it appeared in an attack. And from the scale of a loss it does not automatically follow which control was missing.

What comes next

Next we go with the agents onto the blockchain itself: which wallets, which authorisations actually took place, which contracts ran afterwards, in which order. Transaction hashes, timestamps, nonces, contract code against the reports. The blockchain shows what was executed. It does not show whether a laptop was compromised or a signing service abused. That takes forensics we do not have. The goal is not to confirm the theory. The goal is to know which part of the path can be proven and which remains open. That comes in a second article.

And so it is clear why we invest these hours although nobody pays us for them: we do this to learn. Not out of curiosity about someone else's misfortune, but because I am convinced that security in the system is the only way into the future. Not as a layer on top, not as a check afterwards, but built into the relationships between the components, so that a single failure does not cost everything. Every incident you really understand makes your own architecture a bit better. That applies to wallets, to banks, and to the agents we build. And whoever knows me knows: this simply interests me. Since the first system I saw tip over.

One more thing, so nobody takes this for more than it is: this is my opinion and my research, as of today. It can look completely different in a week, if the on-chain data shows something other than the reports. Then that will be here too. We will follow this over the next week, and whatever changes will not be corrected quietly, but visibly.

What stays

A key can be protected. An HSM can work correctly. A signature can be valid. And still the system permits an operation that should never have happened. Whether it was exactly like that at Binance, the investigation will show. The architecture question remains either way: security does not arise from secure components, but from controlled relationships between them. Who trusts whom, with which permissions, and what happens when one of them falls. It is not enough to make attacks improbable. You have to build systems so that a single failure does not cost everything.

Sources