Binance Hack 2026: What the $6.3B Theft Teaches Every Exchange About Signing
The attackers behind the $6.3 billion Binance incident may not have needed to steal a private key. Instead, TRM Labs' investigation points to a compromise of Binance's hot wallet signing infrastructure, which let the attackers obtain valid signatures for transactions Binance never meant to send.
If that assessment holds, the weak point was not the cryptography. It was the path to the signer: who could ask for a signature, and what the signer checked before it said yes. That is the core of good crypto custody security, and it is where this post focuses.
Key takeaways
- On October 29, 2026, attackers drained Binance hot wallets across ten blockchains, mostly within about 20 minutes, according to TRM Labs.
- Binance says it has found no evidence that private keys were leaked. TRM's assessment is that the attackers took control of the hot wallet signing infrastructure.
- Stablecoin issuers and the Arbitrum Security Council froze about $2.7 billion of the stolen assets.
- We call the core problem the Signing Gap: the checks that sit between a request to move money and the signature that moves it.
What Happened in the Binance Hack?
On October 29, 2026, Binance hot wallets on ten blockchains, including Ethereum, Bitcoin, TRON, XRP Ledger and Solana, were drained. According to TRM Labs, most of the outflows happened in about 20 minutes starting at 20:05 UTC, worth about $6.36 billion at the time of transfer. TRM calls it the largest crypto theft on record, about four times the size of the 2025 Bybit hack. Binance paused withdrawals the same day.
TRM attributes the attack with high confidence to TraderTraitor, a North Korean hacking unit, and found preparation that began at least 36 hours before the theft. TRM also notes that Binance has not yet published a full root cause.
How Did the Attackers Get Binance to Sign?
TRM's assessment is that the attackers gained control of Binance's hot wallet signing infrastructure and used it to sign transactions they chose. Binance, as reported by The Hacker News, says it has found no evidence of a private key leak. Those are two different statements, and the difference matters: one is an analyst's reading of on-chain and incident data, the other is what Binance has confirmed.
On how the attackers got in, Binance co-CEO Richard Teng said the initial investigation found the incident "may have started with a compromised DevOps engineer's laptop". Binance later said it had "uncovered additional points of breach" and that the attack "was not a single 'one-click' action".
On Ethereum, TRM describes a newer technique. The attackers used EIP-7702, a feature added in the Pectra upgrade that lets a regular wallet run smart contract code. They submitted 50 pre-signed authorizations, one for each possible transaction number, so that one would be valid at the moment of execution. The authorization pointed Binance's hot wallet at a contract only the attackers controlled. On the other nine chains, funds left through ordinary signed transfers.
The Signing Gap
The Signing Gap is the set of checks between "send this money" and a valid signature. When those checks are weak, an attacker does not need your keys. They only need to reach something that is allowed to ask.
It helps to split signing security into three layers, because each one answers a different question.
Layer 1: Key security.
Where does the key live? MPC splits the key into shares on separate machines, so the complete private key never has to exist in one place.
Layer 2: Authorization.
Who can ask for a signature? Which services, applications and people are allowed to send a request to the signer?
Layer 3: Transaction policy.
What is the signer allowed to approve? Amount limits, permitted destinations, how much can leave per hour, and which kinds of payloads it may sign at all.
MPC protects the key. Policy controls what the key is allowed to sign. The two are related, but one cannot replace the other.
A simple example shows why. Imagine a withdrawal service is compromised, and the attacker sends the signer a transaction that is perfectly valid on the blockchain. MPC works as designed. The key shares stay protected. But if the signer only checks that the request came from an authorized service, it signs. The attacker never touched the key and still moved the money. This is an illustrative model, not a description of Binance's internal setup, but it is why authorization and transaction policy need to be enforced independently of the app in front of the signer.
This pattern is not new. In February 2025, attackers took about $1.5 billion from Bybit after compromising a developer machine at its multisig provider and injecting code into the signing interface, as BleepingComputer reported. Signers approved a disguised transaction. No key was stolen there either.
| Question | Bybit (February 2025) | Binance (October 2026) |
| Amount | About $1.5 billion | About $6.3 billion |
| Where it started | A developer machine at the multisig provider | Reportedly a DevOps engineer's laptop, plus other points of breach |
| What the attacker did | Showed signers a disguised transaction in the signing interface | Obtained valid signatures from the hot wallet signing infrastructure, according to TRM |
| Were private keys stolen? | No | Binance says it has found no evidence of a key leak |
| What limited the loss | Few freezes; most funds were laundered | About $2.7 billion frozen by stablecoin issuers and the Arbitrum Security Council |
Both incidents highlight the risks of compromised developer environments and the systems connected to transaction signing. We have seen attempts at this kind of access ourselves: we once caught a malicious GitHub repo disguised as a job opportunity.
Why Hot Wallet Signing Is the Weak Point
Hot wallets exist because exchanges must pay out fast, often automatically, with no person approving each transfer. That speed is the risk. The service that asks for signatures runs on machines people log into every day, so layers 2 and 3 have to hold even when that service is compromised.
How much sits in the hot wallet, and how fast it can leave, then sets the size of the worst day. We break down how funds move between hot, warm and cold wallets in how money moves inside a centralized exchange.
What Limited the Damage
Two things worked in Binance's favour, and both are worth copying.
Freezes happened fast. Tether began freezing within about an hour of the first outflows, and Circle shortly after, according to TRM. In total, TRM counts about $2.67 billion in frozen stablecoins plus about $30 million in ETH and ARB frozen by the Arbitrum Security Council, roughly $2.7 billion. Assets that can be frozen behaved like a recovery tool, not only a payment rail.
Binance kept customers informed. It paused withdrawals the same day, pledged to cover all losses, said deposits were unaffected and gave a target for resuming withdrawals, then kept publishing updates as the investigation moved. Clear, frequent updates are part of security. They decide whether users wait or run.
What Exchanges and Payment Teams Should Check Now
Take your largest hot wallet and follow one withdrawal from request to signature. Then ask five questions.
- Who can request a signature? List every service and person. If a laptop can reach one of them, assume it can be compromised.
- What does the signer check by itself? Amount, destination, how new the address is, how much left in the last hour. These rules should run at the signer, in code.
- Which payload types can it sign? Deny anything a payout wallet does not need, such as delegation authorizations or arbitrary messages.
- How much can leave in one hour? Set an outflow limit that matches normal operations, so a 20-minute drain is impossible by design.
- Who do you call first? Keep contacts at stablecoin issuers and analytics firms ready, and a customer update template written before you need it.
Teams that run many automated payouts can turn these checks into policy rules that run before signing.
Where Fystack Fits
Fystack is self-hosted custody infrastructure, built around closing the Signing Gap. It approaches the problem at two levels.
Its policy engine lets teams define transaction rules before anything is signed: withdrawal amounts, destination addresses, address age, outflow velocity and time of day. It can also deny message-signing requests entirely, so a payout wallet signs only the payloads it actually needs.
Its self-hosted Cosigner adds a second, independent check. The Cosigner holds one MPC key share inside your own environment. Before it joins a signing session, it sends the signing request to an approval server your team controls. Your server can inspect the transaction against your own rules and reject anything that does not fit. If it rejects the request or does not answer, the Cosigner does not take part, and in a setup where the threshold needs its share, nothing gets signed.
Signing runs on mpcium, an open-source MPC engine your team can read. Fystack is ISO/IEC 27001 certified, and its backend was independently audited by Adevar Labs.
Our guide to self-hosted MPC wallet infrastructure explains the setup.
No single control stops every attack. The goal is that no single compromised machine can move funds alone.
If you are reviewing your own signing setup, see how Fystack's policy engine works.
About Fystack: Fystack is a self-hosted custody platform for fintech teams. Its core signing infrastructure, mpcium, is open-source on GitHub. Fystack supports Ethereum, Base, Solana, Polygon, BNB Chain, Bitcoin, TRON, Stellar and more.
FAQ
How much was stolen in the Binance hack?
About $6.3 billion across ten blockchains on October 29, 2026, according to TRM Labs and Binance. About $2.7 billion was later frozen by stablecoin issuers and the Arbitrum Security Council.
Were Binance's private keys stolen?
Binance says it has found no evidence of a private key leak. TRM Labs assesses that the attackers took control of Binance's hot wallet signing infrastructure and used it to sign their own transactions.
What is the Signing Gap?
The Signing Gap is the set of checks between a request to move funds and the signature that moves them: who is allowed to ask, and what the signer is allowed to approve. If those checks are weak, attackers can move funds without stealing a key.
What is EIP-7702 and how was it used?
EIP-7702 lets a regular Ethereum wallet run smart contract code. According to TRM, the attackers used pre-signed authorizations to point a Binance hot wallet at a contract they controlled, then drained it.
