The signature is valid, but it does not equal true intent: Looking at the $6.3 billion incident with Binance to see the next step for the cryptocurrency industry
*Author: [Huang Jian](https://mp.weixin.qq.com/s/cUs5SEUFE-VHxqqfkiicWA), Guanyuan Technology*
October 30, 2026, 4:05 AM Beijing Time.
The world's largest cryptocurrency exchange, Binance, began to see large-scale transfers of on-chain assets. In the following 20 minutes, at least 10 hot wallets on various blockchains were sequentially emptied: approximately $3.79 billion in Ethereum, about $1.47 billion in Bitcoin, and around $630 million in Tron.
According to Binance's own figures, the assets involved amount to about $6.3 billion; according to statistics from on-chain analysis company TRM, it is $6.36 billion.
This is the largest recorded theft of cryptocurrency assets, nearly four times the $1.5 billion incident at Bybit in 2025.
A day later, the most discussed topic in the tech community was "the new features of Ethereum being abused." But I am more concerned about a statement in Binance's announcement:
**No evidence of private key leakage has been found.**
The private key was not lost, but the money is gone.
These few words are the key to understanding the entire incident, and I believe this is something the entire cryptocurrency industry should rethink.
### A Theft Where "All Steps Were Correct"
Let's restore the chain of events.
The attack did not start on-chain, but on a laptop. Preliminary investigations point to an engineer responsible for development operations (DevOps); the attacker accessed a service container through this machine and then submitted an unauthorized transaction to the hot wallet system from the container.
Because the request came from an internal source—an authorized machine and an authorized account—all checks along the way were passed. The signing system worked as usual, using the real private key to produce a completely legitimate signature.
On Ethereum, this signature did one thing: it delegated the execution authority of that hot wallet to a piece of contract code that the attacker had previously deployed. In simple terms, it did not sign "transfer some money," but rather "delegate the operational rights of this account to a program written by an outsider."
Once this delegation took effect, it remained valid for the long term. Every cent that entered this wallet afterward would be automatically swept away.
Another detail worth pondering: the attacker did not know exactly which transaction nonce this wallet was at. Security firm Aviatrix's review speculates that the attacker obtained about 50 pre-signed authorizations in a batch based on consecutive nonces, submitting them all at once—49 were useless, but 1 hit, which was enough.
Now let's look at the other half of the timeline. Security company Blockaid's automatic detection flagged an anomaly less than two minutes after the sweep began, completed qualitative analysis within 11 minutes, and within an hour, the attacker's address was marked as malicious across the network, leading to an immediate freeze, ultimately locking up about $3 billion.
On one side, $6.3 billion was moved in 20 minutes; on the other, $3 billion was frozen in 1 hour. The time difference in between is the net loss.
And all of this happened without any errors reported by the cryptographic system.
### Signing is Action, Intent is Content
The only thing that cryptography can prove is:
**This piece of data was indeed signed by the person holding that private key.**
However, it cannot prove a long list of things: whether the signer was sober at the time, whether they were coerced, whether they knew what they were signing, or whether they intended to sign something else.
In this instance, Binance had a real private key, a real signature, a real process, and a functioning cryptographic machine. The only distortion was the intent.
This is the sentence I want to convey—**the signature and the intent behind the signature are two different things.**
The technical accumulation in our industry over the past twenty years has mostly focused on solving "whether the signature is correct." Algorithm strength, key length, cryptographic machine performance, protocol compliance—these are all genuine efforts and have indeed solved problems. But they address "whether this piece of data has been forged," not "whether this operation should have occurred."
There is a whole **signature strategy layer** separating these two matters. And this layer has been the easiest to overlook in the past because it does not yield any evaluative scores.
### The Real Watershed: When the Signer Becomes a Machine
Some may say this is an exchange problem, unrelated to government systems, hospitals, or banks.
The relationship is more significant than it appears. Because the real watershed is not in this incident, but in the next two to three years.
In the past, there was always a person behind the act of signing: they would insert a USB security token, enter a password, and glance at the amount. Humans have judgment about content, even if that judgment is rough. The reason a signature can approximate intent is precisely because the "human" step acted as a semantic verifier.
Now, this step is being removed.
There are two sentences in the "National Informationization 14th Five-Year Plan" that I believe are underrated. One is in the "Cybersecurity Industry Ecosystem Development Project" section: **"Promote mutual trust, interconnection, and interoperability among intelligent agents, accelerate the development of multi-agent systems, etc... develop standards for intelligent agent identity identification."** The other is in the data security section: **"Promote the interoperability and mutual recognition of distributed digital identities."**
The national judgment is clear: machine entities must have identities, must have identifiers, and must be able to recognize each other. This is a necessary step.
But note that "identity identification" answers "who it is." It does not answer "what it is allowed to do at this moment," nor does it answer "whose intent is represented by what it is doing at this moment."
And this is precisely the most critical gap moving forward.
Imagine a very ordinary scenario. A company provides a financial agent with a signing interface, allowing it to process payments under 50,000 yuan. One day, a carefully crafted email convinces this agent that the supplier's account has changed, requiring a supplementary payment of 48,000 yuan. The agent verifies the limit, calls the interface, and signs.
From a cryptographic perspective, this signature is flawless. From a business perspective, this is a standard process within the limit. The only error is the intent—the intent is not that of the company, but of the attacker.
The difference is: a human who is deceived can be stopped by common sense questions like "who is this money going to, and why"; an agent that is deceived will only faithfully execute the context it was constructed to follow.
Thus, when the signer shifts from a human to an agent, the distance between "signature valid" and "intent real" will be infinitely magnified. This is not a model security issue; it is a cryptographic engineering interface design issue—we have solidified "proving identity" but have almost never designed any structure for "expressing intent."
In short: **we have taught machines how to sign, but we have not taught them why to sign.**
### **Nineteen Years of Cryptographic Evaluation, Nine Years of Cryptographic Reform**
At this point, I must say something that may not be pleasant to hear.
First, let's clarify the timeline. This history is earlier than many people think and can better illustrate the issue.
In November 2007, the National Cryptography Administration issued the "Commercial Password Management Measures for Information Security Level Protection"—the official later stated that this was "the beginning and inception of cryptographic evaluation work." In April 2017, seven provinces and five industries launched pilot evaluations; in September of the same year, documents such as the "Management Measures for the Security Evaluation of Commercial Password Applications (Trial)" were issued, and the cryptographic evaluation system framework was initially established; in 2019, the "Cryptography Law" established the status of cryptographic evaluation at the legal level for the first time. By this year, this path has been nearly twenty years long.
The truly large-scale "cryptographic reform" only became substantial after the pilot was expanded in 2017. All told, it has been less than ten years.
**This time difference itself is a judgment: we have practiced "evaluation" for nineteen years, "reform" for nine years, but have practiced "application" very little.**
There is a saying in the industry called "promoting reform through evaluation"—these four words actually clarify the causal relationship: evaluation comes first, reform follows. Reform is driven by evaluation.
In recent years, the main thread of commercial password application has been this evaluation and reform. The achievements are tangible: from the "Cryptography Law" to the "Regulations on the Management of Commercial Passwords," from the cryptographic evaluation management measures to the "Regulations on the Use of Commercial Passwords for Critical Information Infrastructure" effective from August 1, 2025, the institutional framework is already quite complete; cryptographic evaluation has shifted from being recommended to mandatory, with critical information infrastructure required to be evaluated at least once a year after it is built and operational.
This is a significant advancement that cannot be denied.
But we must also acknowledge another side: the focus of evaluation is on "compliance, correctness, and effectiveness." Among these three terms, the first two are verifiable, while the third is the hardest and most easily overlooked.
Regulators actually see more clearly than the industry. In the official interpretation of the "Regulations on the Use of Commercial Passwords for Critical Information Infrastructure," there is a passage that almost explicitly criticizes:
*"Some network and information system constructions have not deeply analyzed the usage needs of commercial passwords and systematically addressed them, mechanically stacking commercial password products, or simply implementing external or patch-style modifications, making it difficult to guarantee the compliance, correctness, and effectiveness of commercial password applications."*
"Mechanical stacking" and "external or patch-style modifications"—these two phrases describe the same ailment: treating passwords as a component to be installed rather than a mechanism to be designed.
This incident at Binance is an extreme example of this ailment. Its cryptographic facilities are complete, its cryptographic machines are professional, and its key management is standardized. The only thing it lacked was someone asking before signing that transaction: what exactly is about to be signed with this key.
Thus, we see an absurd contrast: a cryptographic system that passed all compliance checks signed away all the assets it was supposed to protect in just 20 minutes.
### The National Coordinate System Has Already Been Drawn
It is worth noting the timing: one week before the Binance incident, on October 23, the Central Cybersecurity and Informatization Committee issued the "National Informationization 14th Five-Year Plan."
In this plan, cryptography appears in three places, and the wording is worth reading closely:
Note these verbs: systematize, protect, research. None of them are "deploy products."
Now look at the "Regulations on the Use of Commercial Passwords for Critical Information Infrastructure." The most discussed aspect is "synchronous planning, synchronous construction, synchronous operation." If it is only read as the process requirement of "three synchronizations," it is an underreading. Its essence is that the cryptographic assurance system must be designed together with the business system, rather than being hung on a wall after the business system is built.
Another easily overlooked point—Article 7 requires operators to equip professional personnel to separately assume the responsibilities of **key managers, cryptographic operators, and cryptographic security auditors.**
The separation of these three roles, for the first time at the regulatory level, has singled out "key operations" from "encryption and decryption." This is the institutional landing of the "signature strategy layer" in China.
The third clue comes from the "Cybersecurity Law." On October 28, 2025, the 18th meeting of the Standing Committee of the 14th National People's Congress passed a modification decision, and the new law will take effect on January 1, 2026. One of the key focuses of this amendment is to restructure legal responsibilities: if operators of critical information infrastructure cause particularly serious consequences, the maximum fine will be raised to ten million yuan; the maximum fine for directly responsible supervisors **and other directly responsible personnel** will be raised to one million yuan.
Note the last half of the sentence.
This means that when an incident occurs where "the signature is valid but the intent is distorted," regulators will not only ask, "Did you verify your signature?" but also "Can you prove that this operation was authorized?" If you cannot provide this proof, the signer, the person approving the process, and the person designing the system will all be held accountable.
This is where "intent" shifts from a technical issue to a governance issue. The technical gap is being filled by the burden of proof.
The three clues together point to the same judgment:
**The focus of cryptographic work is shifting from "whether it is installed" to "whether it is used correctly, what to do if it fails, and whether it can be clarified when something goes wrong."**
### **Using Cryptography on "Intent": Five Transformations**
Combining this incident with the institutional background above, I believe that for the cryptography industry to advance, it needs to shift in five areas.
**01** **From protecting data to protecting operations**
Data is static, while operations have consequences. The content of that transaction on Binance was not a transfer; it was an authorization—transfers are one-time actions, while authorizations are long-lasting. The risk nature of these two types of operations is completely different, yet in many systems, they follow the same approval process.
The same applies to cryptographic applications. Key generation, key export, key destruction, and key purpose change—these operations, once invoked, have permanent consequences. They should not share the same authentication and approval process as a regular encryption and decryption. **First, list an "irreversible operation checklist," then design strategies for each item on the checklist separately.**
**02** **From binding identity to binding content**
In many current solutions, the signature covers "who is calling." This is not enough. The signature must cover "what is being called"—method, parameters, amount, time, random number, scope.
Binding only identity without binding content is the mistake made by Binance. This is not a technical detail; it is a design principle: **Cryptography must protect not just "who said what," but also "what was said."**
**03** **From "non-repudiation" to "non-misuse"**
Non-repudiation addresses post-factum denial. However, the issue with Binance was not that someone denied it, but that someone completed a legitimate signature under deception. For this type of risk, what can be done is not to pursue accountability but to ensure that "misuse" becomes ineffective when it occurs: delegation must have a scope, a limit, an expiration time, and can be nailed down by a phrase like "limited to this transaction only."
**04** **From "can authorize" to "can revoke"**
The ability to revoke must be as important as the ability to authorize.
The delegation mechanism of EIP-7702 itself is not wrong; its design is "until revoked." The problem is that revocation requires someone to actively sign a special transaction, and this action is not included in anyone's emergency plan. Actions not included in the emergency manual are not something anyone dares to take at four in the morning.
Therefore: the revocation channel must be preset, must be practiced, and must be able to be completed in minutes. The effectiveness of cryptographic applications is not just about "whether they can work normally," but also about "whether they can be quickly resolved when something goes wrong."
**05** **From "the system takes the blame" to "people take responsibility"**
This point is for the security leaders on the client side. The new "Cybersecurity Law" includes "other directly responsible personnel" in the penalties, and "separation of duties" is included in departmental regulations. This means that cryptography is no longer just a procurement item that is "installed once purchased," but a responsibility chain that can be traced back to individuals.
Conversely, this is also an opportunity: when "intent can be verified" becomes a burden of proof, it shifts from a cost item to an asset item.
### Who Will Fill This Gap
Finally, let's talk about division of labor. This is not something that one company can accomplish alone.
* Chip and cryptographic machine manufacturers: integrate "operational semantics" into the trust root. Current cryptographic machines basically just "sign data"; the next step is to be able to "understand before signing"—support signatures with policy constraints, making "this signature is only allowed for a specific purpose, within a specific limit" a hardware-level attribute, not just an application-level agreement.
* Electronic certification service providers: expand from "proving who you are" to "proving what you authorized." Authorization certificates with purpose, limit, and time constraints are a layer closer to business than identity certificates.
* Application and platform vendors: make signature messages content-rich; do not let users sign a segment of incomprehensible hexadecimal; classify key operations; create revocation entry points and write them into the runbook.
* Evaluation agencies: add verifiable observation points in the "effectiveness" item of cryptographic evaluations—whether signatures are bound to business content, whether irreversible operations have separate strategies, and whether revocation paths exist and have been practiced. **This is where "effectiveness" is transformed from an adjective into a verb.**
* Operators: transform the "three roles of cryptography" from job settings into real permission isolation; establish an irreversible operation checklist; practice "revocation" at least once a year.
If this incident can leave the industry with a specific product direction, I believe it is: **Intent Credential**—it does not replace signatures; it gives signatures meaning.
### Conclusion
Returning to the most fundamental question: what exactly are we protecting with cryptography?
Preventing data theft, preventing identity impersonation, preventing transaction tampering—these are all correct. However, the Binance incident reminds us that there is a more insidious risk: **all protections are functioning normally, but the action being protected is itself wrong.**
Cryptography guarantees that "this piece of data has not been forged." It cannot guarantee that "this operation should occur."
The gap between these two is precisely where the cryptography industry needs to fill next. Filling it does not rely on deploying another batch of products but on transforming cryptography from "a component to be installed" into "a mechanism to be designed"—before each signature occurs, first clarify what intent this signature is meant to express; after each authorization takes effect, first think about how to retract it.
The "National Informationization 14th Five-Year Plan" proposes to "strengthen data security and cryptographic protection," and the "Regulations on the Management of Commercial Cryptography for Critical Information Infrastructure" require "synchronous planning, synchronous construction, and synchronous operation." These two statements actually refer to the same thing:
**Cryptography should not be a patch for the system but the framework of the system.**
Binance used $6.3 billion to validate for the entire industry: when cryptography is reduced to mere "compliance," it cannot protect anything.
But it also validated another thing: cryptography itself is not wrong. The mistake lies in how we use it on "data" but rarely on "decisions."
The proposition for the next generation of cryptographic engineering is not stronger algorithms but clearer intent.
So, I leave you with the final question:
**When was the last time someone seriously asked, "What does this signature really intend to express" in your system?**