What was reported
Outlets put the loss at about $6.3 billion, taken in roughly twenty to thirty minutes from hot wallets on about ten chains. Chainalysis said the operation was likely the work of the North Korean group TraderTraitor. Binance said it traced the breach to a compromised engineer laptop and has found additional points of breach, and that it will cover the losses from company funds.
On Ethereum, Binance said the attackers used the delegation feature of EIP-7702 to get around the approval controls on a hot wallet. Blockaid reportedly found that of fifty signed authorizations submitted together, one took effect. Analysts including TRM Labs and an Ethereum Foundation researcher say the exploit was a compromise of Binance's internal signing infrastructure, not a flaw in Ethereum. Figures and details differ between outlets, and a full post-mortem has not been published. The sources are listed at the end of this page.
The pattern matters more than the number. Once the attackers could make the signing path produce the signatures they wanted, each chain executed them as valid transfers. A valid signature was the only thing the chains asked for.
The design question
If an attacker controls a signer, what else has to say yes before value moves? In the JIL Layer-1 design the answer is a second decision made outside the signer. A signature is necessary and is not sufficient. ATCE, the Adaptive Trust, Compliance and Execution Engine, rules on each transfer inside consensus, and a review step can hold an act that the rules would have allowed.
That is a statement about design. The dated, per-capability status of ATCE (what runs on the live chain, what is built and not deployed, what is only designed) is kept on the ATCE status ledger. This page describes the mechanisms and does not restate the ledger.
Each control against this attack path
| Control | What it does against a compromised signer | Status |
|---|---|---|
| Deterministic rules in consensus (ATCE) | The chain rules on the sender and the recipient and denies a transfer that policy forbids, even when the transaction carries a valid signature. The ruling has two outcomes, allow or deny, with a reason code. | As designed. Dated status is on the status ledger. |
| Hold-only review | A review of the specific act can deny it even when every rule passed. A held act is a deny, and a person decides what happens next outside the review. The review cannot release an act the rules denied, and a hostile input cannot override the rules. | As designed. Dated status is on the status ledger. |
| Hybrid Ed25519 and ML-DSA-65 attestation seals | Protects the evidence of what was attested. It does not protect a signing host from compromise. | Live for attestation seals. On chain, only the Ed25519 half is verified today. |
| Post-quantum validator signing | Not relevant to this theft, which used ordinary valid signatures, not a quantum attack. Post-quantum signing protects against a different future threat. | Designed. Validator signing keys are Ed25519 software keys today. |
| Threshold signing where the key is never reconstructed | This is the control that most directly limits a single compromised signing host. The default service key is split 2-of-3, and signing reconstructs it in memory on the server. A protocol where no host ever holds the whole key is on the roadmap. | Designed. Not deployed. This page does not claim a single compromised host cannot sign. |
| Write-once record of each ruling | Preserves the full record under the ruling's SHA-256 commitment so a transfer can be re-read afterward. It records what happened and does not prevent a transfer. | The record writer is Built, not deployed. The record store is Designed. |
What this means for the signing path
The JIL design places a rule engine and a hold-only review between a signature and a settled transfer. If those layers run on a given chain, a stolen signature alone is not enough to move value that policy forbids. That is the part of the design aimed squarely at this incident, and the status ledger is where you check whether it is running.
The design does not remove the signing host as a target. Until threshold signing without key reconstruction ships, a compromised JIL signing service is the same class of risk Binance suffered, with the rule and review layers as the additional barrier. We would rather say that plainly than claim the attack path is closed.
What we do not claim
- That this kind of theft cannot happen on a JIL chain.
- That post-quantum signatures would have prevented it. They would not have.
- That threshold signing without key reconstruction is deployed.
- That the details of the Binance incident are final. They come from public reports and may change.
Sources
- Cointelegraph, recap of the hack
- SiliconANGLE, hackers steal $6.3 billion from Binance
- BleepingComputer, Binance links the theft to a compromised DevOps laptop
This page is informational. It is not security, legal, or investment advice.
Keep reading
The status ledger dates every ATCE capability. The post-quantum page states what the seals cover.