Ravencoin KAWPOW Proof-of-Work Bypass: Invalid Blocks Accepted, 3-Day Reorg Risk

Root Cause

Ravencoin's KAWPOW proof-of-work algorithm accepts an nHeight field embedded in the submitted block header. This field selects the ProgPoW epoch and, on vulnerable node versions, was never validated against the block's actual chain position. An attacker who crafted a header with a manipulated nHeight could steer KAWPOW's internal validation into a code path that skipped full ProgPoW DAG verification and accepted a supplied mix_hash without confirming genuine work was performed.

Mining pool 2Miners, who shipped the emergency patch, described the root cause: "The KAWPOW header contains an nHeight field that was not checked against the block's actual position in the chain. By manipulating that value, an attacker could reach a validation path that skipped full proof-of-work verification and accepted a supplied mix hash without confirming genuine ProgPoW work."

// Vulnerable kawpow_verify path (pseudocode reconstruction)
bool kawpow_verify(header, mix_hash) {
    // nHeight comes directly from the attacker-supplied block header
    uint32_t epoch = compute_epoch(header.nHeight);
    // If nHeight is manipulated to target a permissive epoch,
    // the full DAG-based verification is bypassed.
    // mix_hash is accepted without confirming real ProgPoW computation.
    return true;  // Invalid block accepted as valid
}

// Fixed version (v4.6.1.1-hf1)
bool kawpow_verify(header, mix_hash, chain_height) {
    // nHeight must match the block's true chain position
    if (header.nHeight != chain_height) return false;
    uint32_t epoch = compute_epoch(header.nHeight);
    // Full DAG-based ProgPoW verification proceeds normally
    return verify_progpow(epoch, mix_hash);
}

The fix also hard-codes a checkpoint at block 4,487,775 (the last known valid tip) to prevent a chain-capture attack via the attacker's cheaper forged chain.

Attack Steps

Impact

• Chain: Ravencoin (RVN) mainnet, UTXO / ProgPoW (KAWPOW variant)
• First invalid block: Height 4,487,776, 2026-08-07 15:44:01 UTC
• Public disclosure: 2026-08-11
• Exchange response: Upbit and Bitget suspended RVN deposits and withdrawals
• Price impact: RVN fell ~19% to ~$0.00288, market cap ~$47.3M
• Chain reorg risk: Up to 3 days of confirmed blocks could be rolled back if the attacker's forged chain achieves cumulative difficulty dominance before miners upgrade
• Direct asset theft: No confirmed direct theft reported; the bug enables block forgery and downstream double-spend risk on the Ravencoin chain, not a direct drain of a smart contract or custodied wallet
• Emergency fix: Version 4.6.1.1-hf1 shipped by mining pool 2Miners (not the core Ravencoin development team); includes hard checkpoint at block 4,487,775
• Governance concern: The patch came from a third-party mining pool rather than the core team, raising questions about the project's security incident response infrastructure

Lessons for Auditors

1. Validate all consensus inputs against chain state. Any header field that influences proof-of-work or proof-of-stake verification logic must be bounds-checked against the node's own authoritative view of the chain—never trusted verbatim from the incoming block.

2. Epoch-selection code is a critical attack surface in DAG-based PoW. In Ethash, ProgPoW, and KAWPOW schemes, the epoch index determines which DAG dataset is used for verification. An attacker who can influence epoch selection may be able to route verification into a cheaper or entirely bypassed code path.

3. Consensus bugs impose systemic risk beyond single-protocol exploits. A successful chain reorganization invalidates confirmed transactions for every user and application on the network—not just the TVL of one protocol. The blast radius is proportional to the chain's adoption.

4. Security incident response must be owned, not crowd-sourced. The emergency patch originating from a mining pool rather than the core team delayed coordinated disclosure and patching. Projects should designate explicit security contacts, maintain an ability to ship emergency releases, and pre-negotiate responsible disclosure channels with major exchanges and miners.

5. Hard checkpoints are a valid short-term mitigation with real trade-offs. Adding a checkpoint prevents the attacker's cheaper chain from overtaking the honest tip, but it sacrifices some decentralization and requires miner coordination. Projects that deploy this mitigation should communicate the trade-off explicitly before deploying.