When a chain rewrites itself: Ravencoin's consensus bug and what a confirmation is really worth
Most crypto incidents are about keys. Someone phishes a seed phrase, a contract has a reentrancy bug, an exchange loses its hot wallet. The ledger stays honest; a particular set of coins changes hands against their owner's wishes.
August's Ravencoin incident was a different category, and a rarer one. Nobody's keys were touched. The ledger itself came apart.
What happened
On 7 August 2026 at 15:44 UTC, at block height 4,487,776, a block that should have been impossible was accepted by the network. Then more of them. In one examined stretch of 2,089 blocks, 96 were invalid. The flaw was demonstrated publicly on 11 August, four days after the first exploited block — which means the chain had been quietly producing counterfeit blocks for the better part of a week before anyone announced it.
RVN fell roughly 20% to around $0.0027. Upbit and Bitget suspended deposits and withdrawals. The Ravencoin project told exchanges, explorers and node operators to upgrade immediately, and flagged every transaction confirmed after block 4,487,775 as potentially reversible.
That last sentence is the one worth sitting with. Not "some transactions were reversed." Every transaction, for three days, was provisional.
The bug: a number nobody checked
Ravencoin mines with KAWPOW, a memory-hard proof-of-work algorithm derived from ProgPoW. Memory-hard is the whole point: the work depends on a large dataset that has to be held in RAM, which is what makes ASICs uneconomical and keeps mining accessible to GPUs. That dataset is regenerated periodically, and which dataset you need is derived from the block's height.
The block header carries a field, nHeight, declaring where in the chain the block sits. Nodes validated the proof of work against the height the block claimed. They never checked that claim against the block's actual position in the chain.
So you could lie. Declare a height from early in the chain's life, get a small dataset, do a fraction of the work, and produce a block that a vulnerable node would happily accept as valid. The memory-hardness that makes Ravencoin mining expensive was optional if you simply said you were mining a different block than you were. Invalid blocks became, in the project's own framing, dramatically cheaper to produce than legitimate ones.
This is about as fundamental as a consensus bug gets. Proof of work is the mechanism by which a blockchain converts electricity into finality. If the proof can be forged cheaply, there is no finality — only the appearance of it.
The fix was the reorg
Here is the part that looks alarming from outside and is actually correct.
2Miners and RavenMiner, between them holding a majority of the network's hash rate, announced they were mining a chain that excludes the exploited branch from 4,487,776 onward. Patched node software (2Miners shipped 4.6.1.1-hf1) rejects blocks whose declared height doesn't match their real one, and hard-codes block 4,487,775 as a checkpoint — a line past which the old, poisoned history cannot be re-accepted.
The result was a chain reorganization roughly three days deep. Three days of blocks discarded and replaced.
A deep reorg is normally a symptom of an attack. Here it was the remedy. The exploited branch was not a legitimate history that someone rewrote; it was already invalid, and the network was choosing to stop pretending otherwise.
You can still see the seam in the chain today. Block 4,487,775 was mined at 15:43:57 UTC on 7 August. Block 4,487,776 — the honest one, on the recovered chain — is stamped 14:09:42 UTC on 10 August. Two days, twenty-two hours and twenty-six minutes between consecutive blocks on a chain that targets one minute. That gap is the scar tissue.
What this meant if you held RVN
If your coins sat in a wallet you control and you didn't transact during those days, nothing happened to you. Keys were never the issue. Balances that predate 4,487,775 were never in question.
If you did transact in that window, your transaction had to be re-mined into the recovered chain to survive. Ordinary payments generally were — they were valid transactions that simply lived in blocks that got discarded, and they returned to the mempool to be confirmed again. What doesn't survive a reorg is anything that depended on the discarded history being permanent. The classic case is a deposit to an exchange: coins arrive, get credited, get traded or withdrawn, and then the deposit un-happens. That is exactly why suspending deposits and withdrawals was the right call, and why the exchanges that did it quickly were protecting themselves and their users rather than panicking. Halting is a failure mode exchanges can and should absorb when the alternative is crediting money that later evaporates.
What a confirmation actually promises
Most wallets, including ours, show you a confirmation count and let you infer safety from it. It is worth being precise about what that number means, because incidents like this are where the imprecision bites.
A confirmation is not a guarantee. It is an economic statement: rewriting history from this point would require redoing this much proof of work, and that would cost more than the payment is worth. Six confirmations on Bitcoin is a rule of thumb about cost, not a cryptographic proof of permanence.
That statement has a hidden assumption baked into it — that producing blocks is expensive. Ravencoin's bug removed the assumption. When invalid blocks cost almost nothing, "this many confirmations" stops measuring anything at all. The number on your screen kept incrementing; what it counted had quietly become meaningless.
The honest conclusion is not "confirmations are useless." It's that a confirmation count is a claim about the health of a chain's consensus rules, and it inherits every weakness those rules have. Scale your patience to the value at stake, and treat an active consensus incident as a reason to stop transacting entirely rather than to wait for a bigger number.
Where SSP stood
We run our own Ravencoin infrastructure rather than reading balances from someone else's API, which means the question "is SSP on the right chain?" has a checkable answer instead of a reassuring one.
Our node runs Ravencoin 4.8.0 — well past the hard fork — and as of writing sits at height 4,522,205 on the recovered chain. Both sides of the seam match the reference chain exactly:
- 4,487,775 →
000000000002d64509e06e76ddbbe418c725291687ec62b41ecfc40386a091fd - 4,487,776 →
0000000000042bb50281ebb2f68d3f9143980b041178849015d95b067d52a841
Same hashes as the official Ravencoin explorer, same three-day gap. Nothing was required of SSP users, and Ravencoin in SSP works exactly as it did before.
The honest limits
We write these pieces to explain what our architecture protects against, so it matters to be clear about what it doesn't.
Two-of-two multisig protects the signing side. It means no single compromised device can move your coins, that every payment is approved twice on two independent pieces of hardware, and that a thief with your laptop has nothing. Those properties held throughout this incident, and they are the properties that matter for the overwhelming majority of ways people lose crypto.
None of them help against a chain reorganizing. Neither does a hardware wallet, an air-gapped signer, a passphrase, or a multisig quorum of any size. Consensus failures are underneath all of it — they are a property of the network, not of your custody. Anyone claiming their wallet protects you from a bad block is selling something.
What a wallet can honestly offer is this: run real node infrastructure, keep it patched, and be transparent about which chain it follows. That is a maintenance commitment, not a cryptographic guarantee, and it is the correct size of claim to make.
The other thing worth taking from August is a reminder about where risk actually lives. Ravencoin's bug had been in the code for years before anyone exploited it, sitting in the least glamorous place imaginable: a field in a header that everybody assumed someone else was checking. The Coldcard entropy failure was the same shape of problem — a small, boring, unexamined line of code, invisible from the outside, holding up everything above it.
Those are the bugs that hurt. Not the exotic cryptographic attacks, but the assumption nobody wrote a test for.
