The $6.3 Billion Binance Hack: A Valid Signature Is Not an Authorized Transaction

 The Binance breach is the clearest example yet. The key take-away: A transaction can be cryptographically valid and still be completely unauthorized by the legitimate owner of the asset.

On 29 October 2026, roughly $6.3 billion left Binance’s hot wallets across ten blockchains, most of it in about 20 minutes. By Binance’s own account, the transfers were produced through its internal wallet signing service, which the attackers had gained unauthorized access to. The network saw valid instructions from a system it had every reason to trust. The legitimate owner never intended any of them.

That is the uncomfortable lesson, and it reaches well beyond crypto. The industry has spent two decades getting better at protecting credentials and keys. It has spent far less time asking what happens when the system that holds the key can be steered into using it for someone else’s purpose.

This is not a post-mortem. Binance has said its investigation is ongoing, and some of what follows may be refined by its final report. To be clear about scope: nothing in the public record suggests that AI-generated voice, voice impersonation or a telephone-based attack played a part. The argument here is broader, and it does not depend on any of them.

What is publicly known, and what is not

Binance’s initial incident report, published on 3 November, puts the impact at about $6.34 billion in digital assets, with about $2.85 billion frozen or intercepted. The exchange says it has absorbed the loss rather than passing it to users. It describes the attack as a sophisticated, multi-stage campaign, not a single breach or a simple phishing incident.

As summarized by CNBC TV18, the sequence Binance describes runs as follows.

The final step used Ethereum’s EIP-7702 mechanism, which lets an account delegate execution right to a smart contract. Binance says the attackers submitted 50 signing transactions to set up malicious delegations over a hot wallet. Those delegations operated independently of its normal withdrawal process, so pausing withdrawals did not stop them. The wallet used multi-party computation (MPC), which spreads signing across components, so there was no single key to use for revocation. Binance had to develop a specialized procedure and cleared the delegation at 00:10 UTC on 30 October.

The FBI has attributed the attack to TraderTraitor, a North Korea-sponsored group; North Korea denies involvement. Some questions remain open. Binance says it has found no evidence that a private key leaked, while the security firm Blockaid counted  hot wallet . Only the full post-mortem can reconcile the two. Binance has also engaged independent firms to validate its findings.

A signature proves which key signed, not what was intended

A valid digital signature answers one question: did the holder of this key, or a system acting on its behalf, produce this message? It says nothing about whether the owner wanted the message produced, or whether the signer was entitled to produce it.

In most systems those two questions are quietly treated as one. If the request arrives from inside the trusted environment and the signature verifies, the action proceeds. That assumption holds until an attacker gets control of whatever sits upstream of the signature. According to Blockaid’s analysis, the first malicious delegation was signed by Binance’s own signing infrastructure while under the attacker’s control. The cryptography worked exactly as designed. It was asked to certify the wrong thing.

Three details in Binance’s account sharpen the point.

• Delegation is itself a transaction. A delegation creates future authority, and once it exists on chain it can act without asking again. The most dangerous instruction is often not the transfer but the grant that makes later transfers possible.
• Protecting key material is a different job from governing its use. MPC is a real control. It makes keys harder to steal. It does not decide whether an instruction to sign is legitimate, and Binance says it is now reviewing signing policy coverage and hot wallet controls.
• Containment was slow because revocation was hard. Revoking authority needed additional on-chain transactions and a purpose-built procedure. How quickly authority can be withdrawn is part of the design, not an afterthought.

This is also a pattern. TRM Labs describes the attackers as having effectively instructed Binance’s wallets to send funds to addresses they controlled, the same approach seen in the 2025 Bybit theft, which the FBI also attributed to TraderTraitor. The two largest crypto thefts on record appear to share a common approach: the weak point was less the keys than the process that decides when they are used.

Three questions that must be answered separately

The incident shows why one check cannot stand in for three. Any high-value action, whether it comes from a person, a service or an AI agent, needs a separate answer to each.

1. Who is requesting the action? Identity must be authenticated independently, at the point of the request. It cannot be inferred from the fact that the request came from inside a trusted network, a trusted container or a valid session. In the Binance sequence, the attackers reached the signing layer by inheriting trust, one compromised person and one trusted system at a time.
2. Is the requester authorized to perform it? Access to a trusted system must not automatically confer unlimited transaction authority. Being able to reach a signing service should not mean being able to sign any amount to any destination. Authority should be scoped by role, value, destination and rate, and checked separately from access.
3. Is the transaction the intended and approved outcome? Approval should be bound to the specific parameters of the action: what, how much, by whom, to whom, to where and by when. For a delegation, it should be bound to its scope and duration. It should come with limits, delegation controls and an audit trail showing who approved what, when, where and why

Many security architectures answer the first question well and the second in part. Few, if any, bind identity and approval to the individual transaction, which is what matters when everything upstream has already been compromised.

Why autonomous agents raise the stakes

Today, a human often sits somewhere in the chain of approval. That person is a pause, a moment in which something can look wrong. Autonomous AI agents that can initiate payments, trades and system changes remove that pause. They act at machine speed, on delegated authority, and in volume.

The Binance gap is the gap that agents widen. An agent’s calls will carry valid credentials and valid signatures. Those prove which agent acted. They do not prove that the person it represents delegated this particular action, within these limits, for this purpose. An agent does not need to be malicious to cause damage. It only needs to be steerable, through compromised tooling, a stolen token or manipulated input, while still looking entirely legitimate to every system downstream.

Binance’s account includes an internal AI tool: it says the attackers exploited one on 20 October to reach other employees’ systems, and that the first step of the campaign involved an AI coding tool installation. How the tool was exploited and what access it held have not been detailed publicly, so it would be wrong to draw conclusions from them. But the general point stands. Any AI tool with reach into systems and people’s machines is part of the trust and security fabric of an organization, and therefore part of its attack surface.

None of this is a new category of problem. It is the same question of who is acting, with what authority and to what end, asked at a faster tempo and with fewer people in the loop.

From protecting keys to binding outcomes

Protecting keys remains vital, but the lesson here is that it is no longer sufficient. The next layer is to make sure a signature can only certify what a verified authority approved. That is the idea behind cryptographic transaction binding, and it rests on a few design principles.

• Bind approval to the transaction. The approval is a cryptographic artefact tied to the exact parameters: asset, amount, destination and expiry. Change any of them and the approval no longer holds. What the approver verifies must be what is bound.
• Separate approving from signing. The system that produces signatures should enforce decisions, not make them. Compromising the signer should not be enough to create an approval.
• Treat delegation as a first-class action. Every grant of authority, to a person, a service or an AI agent, should have a defined scope, a value limit, a duration and a revocation path that works quickly under pressure.
• Set limits that hold even for valid approvals. Caps on value and rate do not make stolen authority harmless. They shrink the blast radius and buy time to respond, which matters when funds can move across ten blockchains in about 20 minutes.
• Keep evidence that survives the incident. An immutable audit record of who approved what, under which delegation and bound to which parameters turn an investigation from reconstruction into verification.

None of these is new, and none replaces strong authentication. They sit on top of it, and they answer the question that authentication alone cannot: was this the outcome the legitimate authority intended?

Five questions for security leaders

Whatever the final Binance report concludes, the incident is a useful test for any organization that lets systems, or agents, act on its behalf.

1. If an attacker took control of the system that produces signatures or approvals, what could it authorize, how large, and how fast?
2. Does reaching a trusted service confer transaction authority, or is authority scoped, limited and checked separately?
3. Is approval bound to specific transaction parameters, and can the approver see exactly what they are approving?
4. How do we grant, constrain and revoke delegation to people, services and AI agents, and how quickly can we revoke it?
5. Afterwards, can we prove who approved what, and under whose authority?

Real Human, Right Human, Right Agent, Right Outcome

These questions follow a sequence, and it is the one ValidSoft’s Voice Intelligence Platform VIP® architecture is built around. Is a real human present? Is it the right human, the person who holds the authority? Is any agent acting for them the right agent, under a defined delegation? And is the result the right outcome: the specific transaction that person approved, bound to it cryptographically so that a valid signature alone is never enough?

The Binance investigation will add detail, and some of today’s picture will change. But the principle will not, a signature tells you which key acted. Whether the action was intended, delegated and approved is a separate fact, and it needs its own proof.