Withdrawal recovery at Binance leaves networks pending

Binance withdrawals have resumed in phases after the $6.3 billion hack. Not every route is back. An asset being available does not mean it can move over every network, and a service moving funds through the exchange still depends on the specific route it uses. The initial phase covered 15 networks and assets; the rest were still being tested.

The FBI attributed the attack to North Korean hackers and identified the operation as TraderTraitor, according to CNBC. That answers the attribution question. It does not answer the immediate integration question: which transfer routes have actually returned, and which remain unavailable while testing continues?

Which Binance withdrawals have resumed?

Binance started restoring withdrawals at 06:00 UTC on November 1, 2026. By 12:36 UTC, all 15 networks and assets in the initial phase had Binance withdrawals back. That phase was complete. Testing for the remaining networks and assets was not, so the completed phase did not mark the end of restoration.

BTC, ETH, USDT, USDC, BNB, SOL and XRP were included in the first phase. Binance said it would share details of the next phase as soon as possible. There was no completion deadline for the testing still underway. For routes outside the completed phase, the updates therefore give no stated date to plan against.

A completed phase is not a completed restoration. An application that depends on Binance withdrawals needs confirmation for the asset and network it actually uses, not just confirmation that the exchange has reopened withdrawals. The broad announcement cannot stand in for that check. Recovery is specific to the route the application needs.

Withdrawal totals measure asset flows, not customer retention

Binance reported about $3.64 billion in net outflows between 06:00 and 15:30 UTC on November 1. The two reports give different withdrawal totals for that same window. Keep both figures visible. Silently picking one would discard a reported figure without resolving the difference between the reports.

Withdrawal volumes had declined and were stabilizing after the initial spike, Binance said. Deposits remained substantial. Both statements describe aggregate activity at the exchange; neither measures whether a particular application's transfers are succeeding. Overall withdrawal volume can settle down without answering whether the route that application needs is working.

Founder and former CEO Changpeng Zhao wrote, “98% choose to stay!” I'd avoid reading the reported 2.1% asset-flow figure as customer retention. Look at the denominator: assets, not users. The figure describes asset flows relative to assets, not the number of customers who chose to remain with the exchange.

Checking a service that depends on Binance transfers

For a service using Binance withdrawals, I'd restore transfer paths one at a time, requiring a successful check on each path before releasing the work that depends on it. Check first, then release. This is an operational recommendation, not a documented Binance API migration, and it does not describe any new configuration requirement.

1. Match each required asset and network to confirmed availability. Use the specific route your application needs as the recovery gate. Confirmation must cover that asset and that network; an exchange-wide announcement that withdrawals have reopened does not replace it.
2. Exercise a confirmed route through your existing transfer workflow. Run the workflow and check that it reaches its normal completed state. Availability confirmation is only that: confirmation of availability. It is not evidence of a successful run through your application's transfer workflow.
3. Reconcile the result with your application's records. Where the service records transfer state, verify that its view agrees with the completed transfer. Do not stop at the transfer completing. Finish the records check before releasing queued work that depends on that route.
4. Re-enable dependent work only after that check passes. A failed check means the path stays paused. Do not reopen every route together. Routes still awaiting confirmation stay outside the rollout, rather than returning with the routes that have passed their checks.

The updates identify no application-side change for services that do not depend on Binance transfers. This work is dependency recovery. It is not a web-server security patch, and it is not a CI/CD secret-exposure investigation. Those problems require different evidence and different remediation. Neither describes the work called for by these withdrawal updates: checking the transfer paths a service depends on before restoring dependent work.

Frozen USDC does not establish completed repayment

Circle freezing funds and Binance replacing impacted funds are separate recovery measures. Neither amount proves that every withdrawal route is operational. For an application waiting to transfer funds, the question remains the same: is its route available? A recovery amount, by itself, does not answer that question.

Circle told CNBC it had coordinated with law enforcement to freeze more than $1.1 billion in USDC associated with the incident. The investigation remained ongoing. The amount updates an earlier statement from Circle CEO Jeremy Allaire, who had said more than $800 million was frozen. It is an updated freeze figure, not a completed investigation.

Binance said it would absorb the financial impact rather than pass losses to users. It reported covering around 95% of the impacted amount, up from 90%. The remaining 5% was less liquid tokens. Binance said sourcing those tokens in the required quantities would take longer; that part of the coverage was still outstanding.

I'd assess those less liquid assets separately before promising a downstream completion time. The constraint Binance described was sourcing the required quantities, and it said that would take longer. There was no deadline for resolving it. A coverage percentage tells you how much has been covered; it does not provide a schedule for completing the rest.

The November 2 reserve report remains an expected publication

An updated proof-of-reserves report was expected on November 2, 2026. Publication is not confirmed in these updates. Binance said it had taken a new snapshot at 00:00 UTC on October 31 and begun computing the zero-knowledge proof. Those are reported steps toward the report, not confirmation that the report itself has been published.

The $171 billion comparison still rests on the older October 28 reserve data. The expected report would give a fresher view of reserves and how user balances are backed, but it would still be a snapshot. One point in time cannot establish continuous withdrawal availability for the routes an application needs, even with fresher reserve data.

I'd check the snapshot timestamp before using a reserve report to decide how balances are backed. As of November 2, 2026, that day's date remains the expected publication date, not proof that publication has happened. Before relying on the report, check that it has actually appeared.