Key takeaway

The available evidence points towards a compromise of Binance's internal transaction-signing infrastructure rather than a demonstrated breach of the underlying blockchains. The difference between the two blockchain investigations' network counts and their financial snapshots also shows why transferred, frozen, recovered and attacker-held assets should not be treated as interchangeable figures.

Binance estimated the financial impact of its 29 October 2026 security incident at approximately $6.3 billion. TRM Labs traced $6.36 billion in transfers across 10 blockchain networks, while Bitquery identified approximately $6.3 billion leaving 17 Binance hot wallets across nine networks. Bitquery's later snapshot showed about $2.7 billion frozen or rescued and $3.2 billion still held by the attacker at 06:43 UTC on 30 October. Binance says it will cover all losses and is investigating how its internal withdrawal systems were compromised.

Binance's $6.3 billion security incident has exposed a security weakness that extends beyond the cryptocurrency exchange's initial explanation of a potentially compromised employee laptop. Blockchain investigations suggest that attackers gained the ability to make Binance's own hot-wallet infrastructure authorise transactions across multiple networks, allowing cryptocurrency to leave exchange-controlled wallets without evidence that the underlying blockchain protocols were compromised.

The scale of the incident is substantial, but the figures circulating about it require closer examination. TRM Labs traced approximately $6.36 billion in cryptocurrency transfers across 10 blockchain networks, while Bitquery identified approximately $6.3 billion leaving 17 Binance hot wallets across nine networks. Their published investigations also use different reporting snapshots for frozen assets and the cryptocurrency still held by the attacker.

TechView Africa's comparison of the two investigations reveals an important reporting gap: although they broadly agree on the financial scale, their published network inventories and recovery figures do not constitute one reconciled account of the incident.

How the attacker gained access to Binance's withdrawal infrastructure

Binance's initial investigation suggests that a DevOps engineer's compromised laptop may have allowed an attacker to access a service container and submit unauthorised withdrawal transactions. The exchange subsequently described the incident as involving multiple factors and said its investigation was still tracing the full attack path.

Binance has reported no evidence that wallet private keys were leaked. It has also said it will publish a technical post-mortem once the investigation is complete.

The blockchain evidence provides a possible explanation for how the withdrawals were authorised. TRM Labs identified the use of Ethereum's EIP-7702 authorisation mechanism, which allows an externally owned wallet to delegate certain transaction behaviour to smart-contract code through a signed authorisation.

In Binance's case, TRM found that an attacker prepared 50 authorisations for the exchange's hot wallet. One valid authorisation allowed an attacker-controlled contract to execute transactions from the wallet. The arrangement also enabled subsequent transfers as additional funds entered the compromised wallet.

However, the Ethereum activity was only part of the incident. TRM identified transfers from Binance wallets using ordinary signed transactions on other networks, including Bitcoin, Tron, Solana, the XRP Ledger, Arbitrum, Avalanche, Optimism, Base and Polygon.

Because these networks use different transaction and signing mechanisms, TRM concluded that the most likely explanation was access to a shared part of Binance's hot-wallet signing infrastructure.

This is a significant technical distinction. The available evidence does not establish that attackers broke the cryptographic security of Bitcoin, Ethereum or the other networks. Instead, it suggests that Binance's internal systems were manipulated into producing transactions that the networks accepted as validly signed.

The investigation therefore needs to establish how the attacker obtained sufficient authority to initiate those transactions, whether existing approval controls were bypassed and why the activity continued across different wallets before the affected authorisation was revoked.

Why blockchain investigations report different numbers of affected networks

The two major blockchain investigations broadly agree on the value of the transfers but do not publish identical network counts.

Reporting sourceEstimated transfersNetwork coverageRecovery snapshot
BinanceApproximately $6.3bn impactNo comparable network inventory publishedApproximately $3bn frozen on-chain in its 30 October update
TRM Labs$6.36bn10 networksApproximately $2.7bn frozen as of 00:30 UTC
BitqueryApproximately $6.3bn9 networks and 17 hot walletsApproximately $2.7bn frozen or rescued; $3.2bn held by the attacker at 06:43 UTC

The difference in network coverage is visible in the investigations. TRM includes Avalanche in its 10-network inventory, assigning approximately $28 million in outflows to that network. Bitquery's published nine-network inventory does not include Avalanche.

Neither investigation provides a common wallet-by-wallet reconciliation explaining the difference. It would therefore be premature to present the exact number of affected networks as independently settled by both firms.

The difference does not invalidate the overall estimate, but it shows why blockchain tracing figures should be attributed to the investigators who produced them. Their estimates depend on identified wallet addresses, transaction histories, asset prices and the scope of their analysis.

TRM values each transfer using the asset price at the time it moved, putting its estimate at $6.36 billion. It also calculated that the same assets were worth approximately $6.23 billion at the prices prevailing when it published its findings.

The difference illustrates how cryptocurrency price movements can change the dollar value of an incident without changing the number of coins transferred.

How much cryptocurrency has actually been frozen or recovered?

The recovery figures provide another important reason to distinguish between different measurements.

Binance reported approximately $3 billion in affected assets frozen on-chain in its 30 October update. TRM's earlier investigation counted approximately $2.7 billion frozen by stablecoin issuers and through intervention by Arbitrum's Security Council as of 00:30 UTC.

Bitquery's later investigation also identified approximately $2.7 billion frozen or rescued. However, its 06:43 UTC snapshot showed approximately $3.2 billion still held in attacker-controlled wallets, mainly in Bitcoin and Ethereum.

The Bitquery figures offer a useful indication of the recovery challenge, but they should not be treated as a final financial statement. Its rounded headline figures of $2.7 billion frozen or rescued and $3.2 billion still held add up to $5.9 billion, approximately $400 million below its rounded $6.3 billion transfer estimate. The report uses different measurement points for transfers and subsequent holdings, so the difference cannot responsibly be described as an additional loss or an unrecovered balance without a complete reconciliation.

The stablecoin transactions also reveal how the timing of intervention affected recovery. Bitquery found that approximately $1.76 billion in stolen USDT had been frozen, representing about 71 per cent of the USDT taken. Another $729 million was converted into Ethereum and Tron assets before the relevant freezes took effect.

This demonstrates why freezing cryptocurrency is not equivalent to recovering it. Tether and Circle can restrict the movement of their respective stablecoins, while some blockchain networks have emergency intervention mechanisms. Bitcoin and Ethereum, however, do not have central token issuers that can simply blacklist and immobilise every coin held by an attacker.

Once funds move into assets without an equivalent issuer-controlled freeze mechanism, investigators may still trace the transactions, but tracing alone does not restore control of the assets.

What the incident reveals about cryptocurrency exchange security

The evidence points to three different security stages that exchanges need to protect.

First is access to internal systems. A compromised employee device or service environment can expose operational tools and permissions that should not be available to an unauthorised party.

Second is transaction authorisation. Even where wallet private keys remain protected, an attacker who can manipulate the systems responsible for requesting or approving signatures may be able to initiate valid transactions. The Binance investigation makes this a particularly important area for scrutiny.

Third is intervention after funds leave the exchange. Stablecoin issuers and some blockchain governance bodies can restrict assets under particular conditions, but their powers do not extend uniformly across every cryptocurrency.

The incident demonstrates that exchange security cannot depend on private-key protection alone. Access controls, separation of duties, transaction limits, independent approvals, unusual-withdrawal detection and rapid suspension mechanisms all contribute to protecting assets.

Binance's promised technical post-mortem will need to explain how these controls operated during the incident, which safeguards failed and what has changed before normal withdrawal operations resume.

What Binance's response means for customers in Nigeria and Africa

Binance has pledged to cover all losses through its Secure Asset Fund for Users (SAFU) and company funds. It has also said customer funds are safe and promised to publish updated Proof of Reserves information after remediation.

These commitments are important, but they address different questions. Proof of Reserves can help demonstrate the assets an exchange holds against its reported customer obligations at a particular measurement point. It does not, by itself, establish that employee access, transaction approvals and withdrawal-signing systems are secure against compromise.

For Nigerian and other African customers, the public evidence reviewed does not establish a separate Nigeria-specific attack or customer-loss figure. However, anyone using Binance's custodial services remains subject to the platform's exchange-wide security controls and any resulting withdrawal restrictions.

Customers should follow official Binance service announcements, check the availability of their particular withdrawal network and avoid unsolicited recovery offers. No one needs a customer's password, authentication code or wallet recovery phrase to investigate this incident on their behalf.

As of Binance's 30 October service update, deposits were operating normally while withdrawals remained paused during a security overhaul. The exchange expected to resume withdrawals within 48 hours, but that was a projected timeframe rather than confirmation that services had reopened.

Our Recommendation

The Binance incident should be assessed as a failure requiring investigation at the level of exchange operations and transaction authorisation, not simply as another cryptocurrency theft.

The most important outstanding question is how an attacker could cause multiple exchange-controlled wallets to authorise transactions across different blockchain networks. Binance's final technical report should address the suspected employee-device compromise, service-container access, signing permissions and the safeguards intended to prevent a single compromised environment from affecting multiple wallets.

The recovery figures also require continued scrutiny. Binance's estimated financial impact, the value of assets frozen by industry partners and the balances remaining in attacker-controlled wallets measure different stages of the incident. A complete assessment will require updated wallet-level tracking, an explanation of the remaining discrepancy between published figures and evidence that the exchange has restored its withdrawal controls.

For customers, the lesson is to evaluate an exchange by more than its Proof of Reserves or reimbursement promises. The security of the systems that authorise transactions is equally important, particularly when large amounts of customer assets are held in online wallets.

Binance's investigation and promised technical post-mortem should establish whether the exchange has addressed the operational weaknesses exposed by the attack. Until those findings are available, the final recovery position and the full cause of the incident remain unresolved.

Sources & Verification

Binance — Security Incident and Withdrawal Service Update, 30 October 2026

TRM Labs — North Korea Steals $6.36 Billion From Binance

Bitquery — Binance Hack: $6.3 Billion Drained Across Nine Chains

Frequently asked questions

1. Was Bitcoin or Ethereum hacked in the Binance security incident?

No. The available investigations do not indicate that Bitcoin, Ethereum or the other affected blockchain networks were directly compromised. The evidence instead points to an attacker gaining access to Binance's internal transaction-signing infrastructure and using it to authorise unauthorised withdrawals. The underlying networks processed transactions that appeared validly signed.

2. Why do TRM Labs and Bitquery report different numbers of affected blockchain networks?

TRM Labs identified transfers across 10 blockchain networks, while Bitquery's investigation covered nine networks and 17 Binance hot wallets. The firms used their own wallet identification and transaction-tracing methodologies, and neither published a complete reconciliation explaining the difference. Their findings therefore should be attributed separately rather than presented as identical measurements.

3. Does Binance's Proof of Reserves guarantee that another security breach cannot happen?

No. Proof of Reserves provides information about an exchange's cryptocurrency holdings relative to its reported customer obligations at a particular measurement point. It does not independently establish that employee devices, transaction-signing systems, withdrawal approvals or other operational security controls are protected against cyberattacks. Customers should consider both financial transparency and the security of the systems controlling their assets.

Add TechView Africa To Your Google Newsfeed
Comment
Reader discussion

Leave a comment

Comments cannot be edited or deleted after posting. Please review your comment before submitting.

No comments yet. Start the conversation.

Found an error, outdated step or safety concern? Contact the desk.