Circle/Tether froze stablecoins worth about $1.7 billion, which accounts for a large portion of the affected funds. CZ suggested that the SAFU fund could fill this gap.
The largest assets were approximately:
• 1.615 billion USDT
• 62.6 million RLUSD
• 29,934 wBETH
• 11,372 XAUt
• 6.19 million UNI
• 198.4 million ENA
• 7.175 trillion PEPE
• 27.8 million USD1
• 2.26 million LINK
• 127,853 AAVE
Based on browser prices, that’s about $2.5 billion.
1. At 15:59 UTC, the attacker deployed a delegation contract from a relayer, 0x63e842b0...73e9c6fAe.
2. About four hours later, the relayer submitted an EIP-7702 authorization transaction.
The transaction installed malicious 7702 delegation code on Binance 14.
3. The relayer then called Binance 14 to execute the delegation code and transfer Binance 14’s ETH and token balances.
4. The call data was labeled sweep(address, address[]). The second parameter was a list of identifiable token contract addresses, plus the zero address (eth).
5. The same relayer later used the same delegation to transfer 780 million USDC from Binance hot wallet 34 into the same pool.
• The relayer 0x7C... was funded two days earlier through three 0.1 ETH withdrawals from Tornado Cash.
• The same pool received 28,005.6 ETH from Binance 16, 24 seconds after the main sweep.
• The pool then forwarded 195,460 ETH to a new, unlabeled EOA.
• That EOA has only one transaction and currently holds 195,460 ETH.
What’s a little unclear is why a relayer was needed in the first place. If they had the private keys to the Binance wallet, they could have sent the assets directly in an atomic bundle and skipped the relayer entirely.
So it seems likely they didn’t have the private keys, but somehow obtained the 7702 authorization signatures through phishing.
I think we can just assume it was the DPRK.
An interesting detail about the Binance hack: the drain transaction submitted 50 EIP-7702 authorizations, each with a sequential nonce.
Only one had the correct, valid nonce for the transaction.
The attacker likely collected all 50 authorizations over a period of time, not knowing which nonce would be correct at execution time, and then submitted them all at once. Ethereum only accepts the valid one; the invalid ones are discarded. $BNB
The largest assets were approximately:
• 1.615 billion USDT
• 62.6 million RLUSD
• 29,934 wBETH
• 11,372 XAUt
• 6.19 million UNI
• 198.4 million ENA
• 7.175 trillion PEPE
• 27.8 million USD1
• 2.26 million LINK
• 127,853 AAVE
Based on browser prices, that’s about $2.5 billion.
1. At 15:59 UTC, the attacker deployed a delegation contract from a relayer, 0x63e842b0...73e9c6fAe.
2. About four hours later, the relayer submitted an EIP-7702 authorization transaction.
The transaction installed malicious 7702 delegation code on Binance 14.
3. The relayer then called Binance 14 to execute the delegation code and transfer Binance 14’s ETH and token balances.
4. The call data was labeled sweep(address, address[]). The second parameter was a list of identifiable token contract addresses, plus the zero address (eth).
5. The same relayer later used the same delegation to transfer 780 million USDC from Binance hot wallet 34 into the same pool.
• The relayer 0x7C... was funded two days earlier through three 0.1 ETH withdrawals from Tornado Cash.
• The same pool received 28,005.6 ETH from Binance 16, 24 seconds after the main sweep.
• The pool then forwarded 195,460 ETH to a new, unlabeled EOA.
• That EOA has only one transaction and currently holds 195,460 ETH.
What’s a little unclear is why a relayer was needed in the first place. If they had the private keys to the Binance wallet, they could have sent the assets directly in an atomic bundle and skipped the relayer entirely.
So it seems likely they didn’t have the private keys, but somehow obtained the 7702 authorization signatures through phishing.
I think we can just assume it was the DPRK.
An interesting detail about the Binance hack: the drain transaction submitted 50 EIP-7702 authorizations, each with a sequential nonce.
Only one had the correct, valid nonce for the transaction.
The attacker likely collected all 50 authorizations over a period of time, not knowing which nonce would be correct at execution time, and then submitted them all at once. Ethereum only accepts the valid one; the invalid ones are discarded. $BNB
