b14g reports 97 million CORE taken: what the 9 million freeze establishes
The short answer
About 97 million CORE staked through b14g was withdrawn without authorization and transferred to attacker-controlled addresses, according to PANews reporting b14g's security update on November 1. The report says about 68 million CORE remains on the Core chain and partner trading platforms have frozen about 9 million CORE associated with the attacker. These figures describe different statuses; neither the on-chain balance nor the freeze establishes that affected users have received their tokens back. PANews's incident report.
For a user with CORE staked through b14g, the immediate task is to preserve the original staking records and look for a recovery update that explains where the tokens are, who controls them and how any return would reach the affected position. A CORE holder outside that staking route should first establish whether their holding falls within the reported scope, rather than assume every CORE balance is affected.
Show less
What the reports actually establish
Odaily also reports the unauthorized withdrawal of approximately 97 million CORE. Its account says b14g paused the affected contracts after discovering the incident and was working with the Core team, security partners and exchanges to trace funds and coordinate freezing and recovery. Odaily published the item at 11:59 SGT on November 1. The two articles both attribute the incident information to b14g; agreement between them does not provide an independent reconstruction of the transactions. Odaily's account.
The distinction matters when reading a rapidly circulating loss figure. The reported 97 million is a token quantity. It is not a verified dollar loss, a count of affected users or an estimate of the eventual amount returned. The reports give no dollar valuation. A conversion would require a price and a clearly specified valuation time.
PANews says b14g identified the affected assets as CORE staked through b14g. That is the reported boundary of this incident. It does not supply a full balance-sheet assessment of the protocol, a statement about every asset on Core or a finding that all wallets holding CORE were compromised. Readers should retain the scope of the statement when deciding which records to review. PANews on the affected staking assets.
The incident clock time in the reports has no explicit time zone. The publication time above is in SGT; it is not the time of the unauthorized transfers.
Read the balances as statuses, not a completed recovery
The three reported quantities answer separate questions. Approximately 97 million CORE describes the unauthorized withdrawal. Approximately 68 million CORE describes tokens reported as remaining on the Core chain. Approximately 9 million CORE describes tokens associated with the attacker that partner trading platforms reportedly froze. Odaily's reported quantities.
Article table: scroll horizontally, or focus the table area and use the arrow keys.
| Reported amount | Status in the report | Question still unanswered |
|---|---|---|
| About 97 million CORE | Withdrawn without authorization | How much will ultimately be returned to affected positions? |
| About 68 million CORE | Remains on the Core chain | Who currently controls the specific balances? |
| About 9 million CORE | Frozen by partner trading platforms | What steps, if any, have been completed toward a return? |
The table follows the reported wording. It is not a reconciliation of separate, non-overlapping pools. Neither account supplies the address list, a platform-by-platform freeze ledger or an explicit statement explaining whether the categories overlap. Adding the chain balance to the frozen balance would therefore produce a total that the sources themselves do not establish.
For the same reason, subtracting the frozen figure from the unauthorized-withdrawal figure should not be presented as the final loss. The freeze describes one reported intervention. A final loss would require a completed account of assets returned and assets still unavailable, with an explanation of the measurement period and the treatment of each balance.
Our reading of the update is narrower: it reports tracing and a freeze while recovery coordination continues. The information needed to identify a completed recovery would be a subsequent statement or transaction evidence showing a return to an identified recovery destination, followed by an explanation of the affected users' access to it. The current articles do not establish that sequence.
A contract pause answers an operational question
Both reports say the affected contracts were paused. They describe that pause as the team's response after identifying the incident. Neither says the cause has been fixed, the contracts have reopened or previously staked funds can now be withdrawn normally. PANews on the response.
For an affected user, a pause and a recovery process create different questions. The pause concerns the ability to use the affected contracts. Recovery concerns the location and return of the assets already taken. A future announcement that operations have resumed would need to be read alongside any separate explanation of the missing funds; reopening alone would not answer the return question.
Before attempting a new interaction, record the specific contract or staking position you previously used. Compare that with the scope named in a subsequent b14g update. If the update does not identify your route or explain the permitted action, keep the question attached to your actual transaction rather than assume an instruction for another contract applies to it.
Do not test a recovery claim by approving an unexplained transaction. Ask what the requested action changes, which asset it concerns and which official update authorizes that procedure. Those are checks for a proposed action, not assertions that a particular recovery portal or claim process currently exists. No such process is established by the two reports.
If you staked CORE through b14g: check your position first
Start with the evidence of your own position: the wallet address used, staking transaction reference, amount and any position record you already have. Retain the original records before relying on a changing interface. If you contact support, use those references to ask whether that exact staking position is included in the affected set.
Keep the token unit attached to every amount. A record of CORE staked is different from a displayed dollar valuation. If a later recovery statement uses a different unit or a different balance date, ask for the conversion or accounting explanation before comparing the two. This is particularly relevant here because the public reports supply token quantities without a dollar valuation.
Separate your own completed transfers from pending requests in your notes. For each disputed action, preserve the transaction reference or the application's status as it appeared when you checked it. A later account of the incident should be compared with those records, rather than with a remembered portfolio total.
If your CORE is on a centralized exchange, review that platform's status for your specific deposit or withdrawal request. The reports do not identify all the trading platforms involved in the freeze, and they do not establish the transfer status of every venue offering CORE. There is no basis in these sources to name a platform as currently available, unavailable or holding part of the frozen amount.
Readers can use NexuAlpha's whale activity page to explore separately reported wallet activity. It should not be used to fill the missing address map in this case: an unrelated large transfer does not establish a link to b14g's affected staking positions.
Which next update would change the assessment?
An address-level account would help establish what the reported chain balance represents. It would need to identify the relevant addresses, the balance time and their role in the incident. That would allow readers to distinguish a balance still observed in an attacker-associated address from a balance moved to a documented recovery destination.
A more detailed freeze statement could answer another question: which platforms froze which assets, and whether the freeze remains in effect. If the same tokens appear in more than one summary category, a reconciliation should explain that relationship. Without that explanation, readers should keep the reported categories separate in their notes.
For affected stakers, a return statement would need more than a headline amount. Look for the destination of the returned tokens, which positions are included and the procedure by which users regain access. These are the details needed to connect a protocol-level recovery figure with an individual balance. The reports do not yet provide them.
An incident report describing the unauthorized withdrawal would also help assess the cause. The reports do not establish a specific exploit mechanism, key compromise or attacker identity. A proposed explanation should remain an allegation until supported by evidence addressing this incident. There is no reason to infer a cause from the fact that a contract was paused.
Quick answers
Has b14g recovered 9 million CORE?
The reports say partner trading platforms froze approximately 9 million CORE associated with the attacker. They do not say that this quantity has been returned to affected users. The next useful evidence would explain the transfer or release status and the destination. Odaily on the freeze.
Does 68 million CORE on-chain mean it is safe to withdraw?
The reported chain location does not establish user access. Neither report says that the approximately 68 million CORE is available for affected stakers to withdraw. Check for a statement about your specific staking position and the permitted procedure before attempting an interaction.
Does the incident affect every CORE holder?
b14g's reported statement limits the affected assets to CORE staked through b14g. The reports do not establish an incident affecting every CORE holding. Identify how you hold the asset before treating the update as an account-specific finding. PANews on scope.
What remains unconfirmed?
The reports do not provide a final recovered amount, a complete address reconciliation, a user repayment procedure or a verified cause. The practical next check is a b14g update that ties a recovery destination and return process to the affected staking positions.