The KAWPOW exploit, explained without the jargon

Ravencoin secures itself with a mining algorithm called KAWPOW. The whole point of KAWPOW is that a valid block has to be expensive to produce: miners burn electricity and a lot of memory bandwidth to find one. On 7 August 2026 at 15:44 UTC a self-described security researcher found a way to skip most of that cost, tested it on mainnet rather than reporting it quietly, and honest nodes accepted the result.

This is not the 2020 incident where extra RVN was minted out of thin air. Nothing here inflated the coin supply. What broke was the network's ability to agree on which chain is real, which, for a payments and asset chain, is arguably worse. Worth noting: this flaw and the asset-transfer overflow fixed alongside it both slipped past professional security audits of the codebase. Former lead developer Tron Black suspects they were surfaced by a frontier AI model reviewing the code.

The damage

What actually went wrong, in plain terms

Mining is meant to be expensive. To add a block, a miner has to burn real electricity solving a puzzle, and Ravencoin's puzzle (KAWPOW) is deliberately memory-hungry so it can't be brute-forced cheaply. Every other node then re-checks that the work was really done before accepting the block.

Two things combined to let someone skip that cost.

• Each block header contains a number saying which height in the chain it belongs to. That number is not just a label: it decides which slice of mining data the puzzle uses. Nodes trusted whatever number was written there, and never checked it matched where the block actually sat in the chain. So an attacker could lie about it.
• To speed up syncing old history, nodes skip the full, expensive work check for blocks at or below the last built-in checkpoint, and only glance at the final hash. Old history is assumed settled, so why re-verify it.

Put together: by writing a fake height into the header, an attacker could make a brand new block look like ancient history to the software, so it went down the cheap, barely-checked path. The block was accepted without any real mining work behind it. The patch notes describe finding such a block as orders of magnitude cheaper than mining honestly.

Cheap blocks mean cheap chain. Anyone who can produce blocks for nearly nothing can build a competing version of recent history and have the network adopt it, which is what undoes confirmed transactions.

The first forged block landed at height 4,487,776 on 7 August 2026 at 15:44 UTC. For most operators the first sign was practical rather than dramatic: a node restarted and refused to load its database, or stopped syncing entirely because the sequence of block heights it was being shown made no sense. In one sampled range, 96 of 2,089 blocks were affected.

The split, and how it was settled

The network did not simply roll back. It split. One branch kept accepting the forged blocks. The other, led by the two largest pools, 2Miners and RavenMiner, which together control most of the hashrate, started mining a clean chain that rejects everything from height 4,487,776 onward and pins 4,487,775 as the last known-good block.

Tron Black, Ravencoin's former lead developer, asked the pools to consider a more recent recovery point so the reorganisation would be shallower, with a code exception for the bad blocks. That request was declined; they took the cleanest possible cut. In a pure proof-of-work system the chain with the most accumulated work wins, so once the majority of honest hashrate refused the tainted history, the tainted history lost.

A handful of long-running nodes are still holding out. Ravencoin has a no-long-reorg rule meant to protect against a surprise 51% attack, and nodes that never restarted, that never technically saw the (flawed) rules broken, and that still have enough peers sharing their view, will keep refusing the new chain. That safeguard is working exactly as designed; it just wasn't built for a validation bug.

The fix that was applied

The emergency patch came from a mining pool operator rather than from upstream: 2miners shipped v4.6.1.1-hf1 on 10 August, superseded by v4.8.0 on 11 August. That matters because the release circulating as v4.7.0 fixed only the asset-transfer issue, not the consensus flaw. Operators were told plainly not to rely on it.

The patch does three things:

• Rejects any block from height 4,487,776 onward whose declared header height doesn't match its real position in the chain. This closes the hole itself.
• Hard-codes a checkpoint at block 4,487,775, the last known-clean block, so nodes pin history there and rebuild their chainstate from a trusted point instead of crashing on corrupt index entries.
• Makes block-index loading tolerant of unverifiable entries and rebuilds the asset databases, so existing nodes recover with a binary swap rather than a manual reindex.

v4.8.0 also bundles the separate asset-transfer overflow fix, which is the one genuine silver lining here: that bug is now fixed and deployed too. Nodes coming from the hotfix restart quickly. Nodes coming from unpatched software have to replay and rebuild, which takes several hours on typical hardware, but no manual reindex is needed.

The pros

• It works and it was fast. Days, not months, from exploitation to a deployable binary.
• Easy to roll out. Operators swap the binary and the node repairs itself; no arcane recovery steps for the average miner.
• It restores sync. Nodes that were permanently wedged could rejoin the network.
• The root cause is genuinely fixed, not papered over. The height check is a real consensus rule now, not just a checkpoint band-aid.
• It was settled by real work. The clean chain won because honest hashrate refused the invalid history, which is the mechanism proof-of-work is supposed to fall back on.

The cons, honestly

• Roughly four days of transactions (7 to 11 August) were orphaned when the clean chain took over. If you were paid, or an exchange credited your deposit, inside that window, that history was rewound.
• Most reverted transactions returned to the mempool and were re-mined, but not all could be. Anything that spent coins from an orphaned block's mining reward, and anything built on top of those, is permanently invalid and cannot come back.
• The rollback depth was decided by two mining pools. 2Miners and RavenMiner together control most of the hashrate, and they declined the request to restart from a later, less destructive point. On a chain this size, a couple of pools can effectively set policy.
• The canonical fix came from a third party. Trusting a pool operator's build is a pragmatic call, not a comfortable one, and it exposes how quiet upstream development had become.
• Checkpoints are a blunt instrument. They restore safety by asserting 'this history is final because we say so', which trades a little decentralisation for a lot of stability.
• Two consensus-level bugs got past paid professional audits. The review that seems to have caught them was an AI one.
• Real-world fallout: exchanges including Bitvavo, Upbit and Bitget suspended RVN deposits and withdrawals, and RVN dropped roughly 17 to 21% to record lows during the incident.

So how much was actually lost?

Two numbers matter here. The attacker spent almost nothing, so the cost side is tiny. The damage side is not.

• Mining rewards: roughly 4,300 to 5,800 orphaned blocks at 625 RVN each means about 2.7 million to 3.6 million RVN of mined income vanished. That is roughly $25,000 to $33,000 of pool rewards that no longer exist on the surviving chain. The pools said they would absorb that cost rather than claw it back from miners.
• Market value: the big one. RVN fell 17 to 21% to an all-time low. Against a market capitalisation in the low hundreds of millions, that drop erased tens of millions of dollars of ordinary holder value. Nobody stole it; it was repriced once the market learned the chain could be rewritten.

Put bluntly: the attack was cheap, the mining income lost was modest, and the trust lost was expensive. Supply stayed intact. No RVN was created out of thin air, and nothing was taken from a wallet that existed before 7 August. What was lost was roughly four days of settlement finality, the work behind several thousand blocks, and a lot of confidence.

What it means if you hold Ravencoin assets

Balances and asset ownership established before 7 August were preserved. The rebuild started from a clean pre-exploit block, so pre-attack state carried over. The pools stated that miners would not go negative and that they would cover shortfalls from orphaned blocks out of pocket, with payouts paused while the new chain settled.

The practical lesson for anyone treating RVN transfers as final: on a smaller-hashrate chain, confirmations are a probability, not a promise. Give large transfers more confirmations than feels necessary, and don't assume an exchange credit is irreversible.

Where things stand now

The majority of network hashrate is on the patched chain, and the main block explorers, Cryptoscope, TokenView and the Ravencoin Asset Explorer, are all showing the same canonical history. Operators should be running v4.8.0 or an equivalent build that includes both the height validation and the checkpoint logic. If you want to confirm your own node is on the right side, check block 4,494,143: its hash ends in 4c67d6a4.

Ravencoin has taken hits before, and each time it has picked the cleaner path over the convenient one. A flaw that should never have shipped got exploited, the honest majority refused the tainted history, patches went out, and the ledger was rebuilt by accumulated real work. The network is back.