After Binance attack, Lazarus theft estimate reaches $11.87 billion: how to read the recovery ledger

What the $11.87 billion estimate actually measures

Odaily published its account at 16:42 SGT on November 1. The report attributes the cumulative total to Darkfost and says the latest Binance attack was included in that estimate. It also reports that some funds were lost during subsequent laundering. The figure therefore needs its subject and attribution attached whenever it is repeated: an analyst's estimate of cumulative theft associated with Lazarus Group. Read the reported estimate.

PANews carries the same $11.87 billion figure and attributes it to the same analyst. That is useful for checking how the claim was reported, but counting the two publications as two independently constructed loss estimates would exaggerate the evidence. The underlying estimate remains Darkfost's. PANews' account identifies the analyst.

ChainCatcher also attributes the cumulative amount to Darkfost and mentions losses during laundering. Its account supplies another readable report of the claim. It does not provide a separate incident-by-incident calculation that would let a reader reproduce the total. We have no basis here to present the three reports as three independent measurements. ChainCatcher reports the same attribution.

A cumulative theft figure and a present balance require different questions. To turn the estimate into a current holdings calculation, a reader would need evidence identifying which assets remain under the attacker's control, what has been spent or exchanged, and the valuation time. The opened reports do not supply that reconciliation. We consequently leave current holdings out of the calculation rather than subtracting guessed expenses from the headline total.

The same restraint applies to an amount supposedly available for seizure. A historical total does not identify an address, custodian or legal action. Treating the estimate as recoverable cash would require another set of records. When reviewing a new report, look for the evidence that changes control over a named asset, rather than assuming that a larger historical tally creates a larger available recovery pool.

Keep separate entries for theft, backing and returned assets

CNBC describes a Binance theft of around $6.3 billion and reports the exchange's statement that about 90% of affected assets had been covered. It says the company tapped its Secure Asset Fund for Users, part of its Futures insurance fund and its corporate treasury. These are reported sources of replacement assets. They explain how backing can improve without an equal amount returning from the attacker. CNBC details the funding sources.

For your own reading notes, keep an entry for the reported theft, another for replacement backing, and a separate entry for any specifically documented return of stolen assets. Add the source and the asset beside each entry. This is an editorial method for comparing updates, not a new estimate of what Binance owns or owes. It prevents a company-funded replacement from being entered a second time as an attacker-funded recovery.

Do not add the $11.87 billion cumulative estimate to the Binance loss figure. The Darkfost reports describe the Binance event as included in the cumulative tally. Adding that incident again would count it twice. The useful comparison is the scope of each number: one reported total across attacks, and one reported loss for a particular incident. Odaily explains the inclusion of the Binance attack.

Nor should the reported coverage percentage be applied to the cumulative Lazarus estimate. CNBC's coverage discussion concerns Binance's affected assets. It does not provide a recovery percentage for all thefts attributed to the group. Multiplying numbers from these different categories would produce a result with no matching subject in either source. CNBC describes the Binance-specific coverage.

Asset units deserve their own column. CNBC reports that Binance named BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD and ZEC as fully backed, while describing the outstanding portion as less-liquid tokens outside its top ten. That reported distinction is more useful to a holder of an affected token than applying an overall percentage equally to every balance. CNBC lists the named assets.

Read that list as a dated company statement carried by CNBC. Before using it to make a transfer decision, compare the asset you hold with the current information in your account. The article's list supplies no individual withdrawal receipt. A balance, a service reopening and a completed payment should occupy separate lines in your notes, because each answers a different reader question.

Attribution and accounting need different evidence

CNBC reports that the FBI determined North Korea was responsible for the Binance theft. The report also describes the agency's account that stolen assets were converted into Ethereum. Those are reported attribution and movement claims concerning this attack. They do not independently verify every incident or dollar included in Darkfost's cumulative estimate. CNBC covers the FBI determination.

A reader can accept that the FBI determination is being reported while still asking how the historical total was assembled. These questions concern different evidence. Attribution asks who carried out an attack. A cumulative calculation asks which incidents were included, how their losses were valued, and whether later revisions were incorporated. A single attribution statement cannot fill all of those fields.

The opened reports do not expose a complete incident ledger for the $11.87 billion calculation. We therefore do not break it into annual totals, calculate a Binance share, or estimate what the group retained after laundering. Such arithmetic could look precise while silently mixing valuation dates or asset categories. A reproducible table with incident dates, loss definitions and adjustments would be the evidence needed for that next step.

Keep the language equally precise when passing the story on. “Darkfost's reported cumulative theft estimate” preserves the status of the number. “Lazarus has $11.87 billion” changes the subject to a present balance that these sources have not measured. A reader deciding what to do with an exchange account should not have to discover that change after opening the article.

The record to check for your own transfer

Start with your existing withdrawal record. Note the asset, selected network, destination, requested amount and the status shown by the account. If a transaction reference is displayed, compare it with the receiving record. This is a proposed checking sequence for a particular payment; it does not claim that any named account currently has a withdrawal option or that a transfer will finish within a specified time.

Use the company-wide report as context for that check. CNBC reports that withdrawals resumed in phases, first on the Bitcoin network, with Ethereum and BNB Smart Chain subsequently restored. A phased reopening is a service update. To establish the result of your own payment, you still need the record associated with that payment and the receiving side. CNBC reports the phased reopening.

If those records disagree, preserve the reference and the exact status wording before contacting support through the account interface you already use. Ask about the named asset and selected network. A support inquiry about a pending transfer should identify that transfer; the group's cumulative theft estimate supplies no transaction identifier and cannot resolve the inquiry.

Reject any message asking you to connect a wallet or send a payment to claim a share of the $11.87 billion. The reports opened for this article describe an analyst's theft estimate and Binance's asset backing. They establish no public distribution programme tied to that cumulative figure. Open your existing account directly to review its notices rather than following a compensation link sent in an unsolicited message.

A useful support question is narrow enough to check against a record: ask whether the displayed request has been processed on the selected network and what the current status means. Preserve the answer beside the request instead of using it as a statement about all customers. If you later compare two updates, keep their timestamps as well. A newer report about one asset does not rewrite an older record about another asset, and a missing update should remain an unanswered question in your notes.

What would change this assessment

A published incident ledger behind the Darkfost estimate would allow a closer examination of its scope. A documented recovery would need the asset, amount and evidence of its return. An individual withdrawal result would need the corresponding payment record. Each could improve the reader's understanding, but each would change a different entry.

For the next update, write down the sentence's subject before copying its number: the group's historical thefts, Binance's replacement backing, recovered assets, or your transfer. Then attach the source and time. Leave a field blank when the evidence does not answer it. That gives you a usable record as the incident develops without turning a cumulative estimate into money that has arrived.

Quick answers

Is $11.87 billion the attacker’s current balance?

The opened reports attribute a cumulative theft estimate to Darkfost. They do not provide a current holdings reconciliation.

Can Binance’s incident loss be added to the cumulative total?

The analyst’s reported tally already includes the Binance attack. Adding the incident again would duplicate it. Odaily’s description of the estimate.

What would establish that a customer received a transfer?

Use the withdrawal record and the matching receiving record for the selected asset and network. The historical theft estimate cannot supply either one.