Core DAO is coordinating an emergency hard fork. Cointelegraph reported on 2 September 2026 that a small number of validators claimed more CORE than the protocol intended to issue, that Core has contained it, that “malicious validators” can no longer draw excess rewards, and that the fork will be a forward upgrade which does not roll back the network or reverse any previously confirmed transaction. Core’s status update on Monday said the incident was limited to reward issuance and that user assets remained safe. A technical postmortem is promised.
Read that last part again, because it is the most interesting sentence on the page. User assets are safe. That is completely true. It is also not the same thing as saying nobody lost anything.
TL;DR
- Core DAO validators drew CORE rewards far above intended issuance; Core is fixing forward with a hard fork rather than rolling back the chain.
- “User assets are safe” is true and incomplete: no wallet balance changed, but the total supply did, which quietly shrinks every holder’s share.
- Core has not said how much was issued or whether it circulated, but on a public chain those answers can be reconstructed without waiting for the postmortem.
- Four exchanges gave four different explanations for the same pause, which is what happens when your only view is the venue layer rather than the chain.
- Every raffle has the same structure: your ticket is the numerator, the ticket count is the denominator, and fairness proofs that cover only the random number leave the denominator unverified.
Your balance is the numerator. The thing that moved is the denominator.
Every CORE holder can open a block explorer right now and see a balance that is exactly what it was on Sunday. Nothing was lifted out of any wallet. That is what “user assets remain safe” means, and it is not spin.
But a token balance is a claim on a supply. What you own is a fraction, and only the top half of that fraction lives in your wallet. Validators minting rewards above intended issuance moves the bottom half. No row in the ledger you were checking changed. The number of rows got bigger.
This is the failure mode that is hardest to feel, because there is no moment where you are visibly robbed. No alert, no missing transaction, no hostile signature on anything you own. Just a number you were never watching that is now bigger than it should be. If you only ever check the thing with your name on it, you will never see it happen.
The three numbers Core has not published
Core has not disclosed how much CORE was issued, how long the activity continued, or whether any of the additional tokens entered circulation. It has not explained the vulnerability either. It has promised a postmortem, and I would rather have a correct one late than a fast one that is wrong.
But notice something about those first three questions: they do not actually require Core’s cooperation. Issuance is an on-chain event. Reward claims are transactions. Transfers into exchange deposit addresses are transactions. Independent analysts will have most of this reconstructed before the official document lands, and when it does land, it can be checked against the chain rather than simply believed.
That is the whole argument for putting economically meaningful things on-chain. Not that they cannot go wrong. That when they go wrong, the record of how badly is not in the sole custody of the party with the strongest incentive to round it down.
One event, four explanations
Look at how the venue layer handled this. Coinbase paused sends and receives on the Core network. Bithumb and Coinone suspended deposits and withdrawals citing suspected or confirmed security concerns. Bitget suspended them citing wallet maintenance. LBank paused deposits citing the project’s requirements. Same event, four framings, one of which means nothing at all. Venues narrate; the chain records. If your only window into an incident is your exchange’s notice board, what you understand about it is a function of that exchange’s comms policy rather than of what happened.
Not rolling back is the right call
Core is fixing forward and leaving confirmed transactions alone. Some holders will read that as Core declining to make anyone whole, and depending on the postmortem that is a fair fight to have. But as a principle it is correct.
A chain that reverses settled transactions to correct its own mistakes has told you something permanent about itself: that finality is a policy, policies have exceptions, and the exceptions get decided by whoever is in the room that week. Once you have reorganised the ledger to fix a bug, you can no longer credibly promise you would not reorganise it for a bigger reason. The bug is contained. The precedent would not be.
What this looks like inside a game
A raffle ticket has exactly the same structure as a token balance. What you hold is the numerator. Your odds are set by the denominator, which is the number of tickets that exist in that draw. Your ticket can sit in your wallet, untouched and perfectly verifiable, while the thing that determines what it is worth moves somewhere you were not looking.
So here is the Core question, translated into gaming: can anyone create entries in a draw outside the process you can see? Not steal your ticket. Not tamper with the randomness. Just add tickets.
At most crypto casinos the honest answer is yes, quietly, because the draw does not happen on-chain. Entries live in a database: house accounts, promotional entries, comped tickets, a support tool that adds an entry to settle a complaint. None of those need to be malicious to wreck the odds, all of them are invisible from outside, and every one leaves your ticket completely intact while making it worth less. It is the Core incident with none of the reconstructable parts.
This is why provable fairness has to cover the whole draw and not just the number that comes out of it. Chainlink VRF gives you randomness nobody can predict or manipulate, including us, and that is necessary. It is not sufficient. A perfectly fair random selection from a population you cannot enumerate is still a fair draw over an unverified crowd.
On Satoshie, entry is on-chain. The ticket count is contract state you can read. Every entry is a transaction with a sender and a block number. The VRF callback selects from exactly the set the chain says exists, and not from some larger set assembled off to one side. Numerator and denominator are both public, which means you can count the tickets yourself, before the draw, without asking us for anything.
Being straight about the limits: this does not make bugs impossible. Core’s validators exploited real code written by real engineers, and our code is code too. What on-chain entry changes is who gets to tell you what happened afterwards. If Satoshie ever issued an entry it should not have, that entry would sit in public with a block number attached, whether or not we published a word about it.
The question worth asking
The strongest line in Core’s update was that user assets remain safe. The strongest question about it is the one almost nobody asked underneath: safe measured how, and against what total?
Ask that of every platform holding your stake. Then check whether they can answer it without you having to take their word for it.
📷 Photo by Julia Taubitz (@justmejuliee) on Unsplash
