$6.34 billion in assets were impacted.
But after reading Binance’s report on the October 29 attack, I don’t think the number itself is the scariest part.
The scariest part is this:
The attackers may not have needed the private key at all.
They only needed control over the system that was allowed to use it.
This attack didn’t happen overnight.
The attackers reportedly used social engineering, fake recruitment interviews, malware, compromised employee devices, stolen credentials, internal AI tooling, and deployment permissions…
until they eventually reached the wallet signing service.
From there, they were able to initiate transactions outside the normal withdrawal flow.
XRP, SOL, OP, BTC, and ETH were moved from Binance hot wallets.
Total assets impacted: ~$6.34B
Binance says around $2.85B was frozen or intercepted, while 98% of the impacted token assets had been replenished.
But there’s an important distinction:
98% replenished ≠ 98% recovered from the attackers.
Replenishment means Binance used its own resources to restore the missing assets.
What caught my attention most, though, was EIP-7702.
The attackers created on-chain authorization for a smart contract they controlled.
That meant even after Binance paused withdrawals, some unauthorized asset movements could not be stopped immediately.
The hot wallet also used MPC, so there wasn’t one single private key that could simply be used to revoke the malicious authorization instantly.
This incident changed the way I think about wallet security.
The old question was:
“Is the private key safe?”
Maybe the better question is:
Who can make the system sign?
Who can deploy code?
Which credentials can reach the signer?
How far can one compromised employee device escalate?
The private key may still be sitting exactly where it should be.
But if an attacker can make the infrastructure sign on their behalf…
is that really any different from having the key?
But after reading Binance’s report on the October 29 attack, I don’t think the number itself is the scariest part.
The scariest part is this:
The attackers may not have needed the private key at all.
They only needed control over the system that was allowed to use it.
This attack didn’t happen overnight.
The attackers reportedly used social engineering, fake recruitment interviews, malware, compromised employee devices, stolen credentials, internal AI tooling, and deployment permissions…
until they eventually reached the wallet signing service.
From there, they were able to initiate transactions outside the normal withdrawal flow.
XRP, SOL, OP, BTC, and ETH were moved from Binance hot wallets.
Total assets impacted: ~$6.34B
Binance says around $2.85B was frozen or intercepted, while 98% of the impacted token assets had been replenished.
But there’s an important distinction:
98% replenished ≠ 98% recovered from the attackers.
Replenishment means Binance used its own resources to restore the missing assets.
What caught my attention most, though, was EIP-7702.
The attackers created on-chain authorization for a smart contract they controlled.
That meant even after Binance paused withdrawals, some unauthorized asset movements could not be stopped immediately.
The hot wallet also used MPC, so there wasn’t one single private key that could simply be used to revoke the malicious authorization instantly.
This incident changed the way I think about wallet security.
The old question was:
“Is the private key safe?”
Maybe the better question is:
Who can make the system sign?
Who can deploy code?
Which credentials can reach the signer?
How far can one compromised employee device escalate?
The private key may still be sitting exactly where it should be.
But if an attacker can make the infrastructure sign on their behalf…
is that really any different from having the key?
