The same bug, two outcomes: Telestai, Ravencoin, and what a fork inherits

Yesterday we wrote about Ravencoin's consensus bug — an unvalidated nHeight field in the block header that let attackers forge proof of work, and the three-day chain reorganization it took to undo.

There is a second half to that story, and it is the more useful one. Another chain had exactly the same bug in exactly the same place. It never got exploited.

The difference between those two outcomes is worth understanding, because it is not a difference in the code.

Telestai inherited the flaw, because that is what forks do

Telestai is a Ravencoin fork. Its codebase descends from Ravencoin's, by way of Meowcoin — Telestai Core 3.0.1's release notes still list a "Meowcoin source purge" among the cleanups, which tells you how recently that lineage was visible in the source tree.

Ravencoin's header validation didn't check the declared nHeight against the block's real position in the chain. Neither did Meowcoin's. Neither did Telestai's. Nobody introduced the bug into Telestai; it arrived with everything else, in the way that a fork inherits the parts of a codebase nobody is looking at along with the parts they are.

This is the unglamorous mechanics of how a single flaw becomes several chains' problem. Forks are not copies that drift apart into independence. They are copies that carry the parent's entire history of assumptions — including the assumption, in this case, that somebody had already validated that field.

What Telestai did with two days' notice

Ravencoin's exploit was disclosed publicly on 11 August 2026. Telestai Core 2.1.8 shipped on 13 August, titled, plainly, "Security: KAWPOW nHeight bind."

Its release notes do not hedge:

This release fixes a KAWPOW consensus/DoS issue where the header nHeight field (which selects the ethash epoch) was not bound to the chain. The same class of bug was exploited on Ravencoin mainnet. Telestai nodes running older versions remain exposed until they upgrade.

The fix itself is layered, and the layering is the interesting part:

• An absolute epoch bound is enforced immediately, before any proof-of-work hashing happens at all.
• Strict height == prev + 1 binding activates at block 1,100,000 — soft-fork style, with no history rewrite.
• Proof of work is only computed after the parent block is found and the height is verified, which closes a memory-exhaustion path where a node could be made to do expensive work on a header it should have rejected outright.
• The same checks apply on ConnectBlock and VerifyDB, so a node reindexing its database can't quietly re-accept what the new rules forbid.

Mainnet was around height 1,057,000 when 2.1.8 landed. Enforcement was set at 1,100,000. That gap — roughly 43,000 blocks — was deliberate: enough runway for exchanges, pools, explorers and node operators to upgrade before the rule turned on, and not so much that the window stayed open indefinitely.

Telestai also credited its source. The release notes point at 2miners/Ravencoin, branch rvn-nheight-fix — the same patch that came out of Ravencoin's incident — and thank the researchers who documented the fuller header-acceptance fix. The fix travelled along the same path the bug had.

The two outcomes, side by side

Two chains. One codebase heritage. One identical latent flaw.

Ravencoin's was found by an attacker first. The result was four days of counterfeit blocks before public disclosure, exchanges halting deposits and withdrawals, a roughly 20% price drop, and a three-day chain reorganization to remove the poisoned branch.

Telestai's was found by reading someone else's incident report. The result was a patch two days later, an activation height set with room to spare, and — because there was no invalid history to remove — no reorganization at all. Nothing was rolled back because nothing needed to be.

That is the whole difference. Not better code. Not a different bug. Just who noticed first, and how quickly the people maintaining the chain acted on somebody else's bad week.

Then Telestai changed the algorithm entirely

Six days after the security patch, Telestai shipped Core 3.0.0, forking at block 1,150,000 — around 16 October 2026 — onto Meraki, its own proof-of-work algorithm. Meraki is still KAWPOW's relative (a ProgPoW-flavoured Ethash derivative, and the miner started life as a fork of kawpowminer), pitched as lower-power and reachable on modest GPUs.

It's worth being careful about the causality here, because it is tempting to draw a straight line and the line isn't straight. Meraki was already in flight before August: testnet soak builds for 3.0.0 were being published on 13 and 14 August, the same days as the security release, which is not a schedule anyone assembles in forty-eight hours. The algorithm change was planned work that happened to land next to an incident, not a reaction to it.

There's also a small lesson in the release list about the unglamorous parts of maintaining a chain. Between the security fix and the fork, Telestai shipped 2.1.9 for a reason that has nothing to do with consensus: 2.1.8 had been built against a newer Berkeley DB, and opening an old wallet.dat with it could rewrite the wallet's logs so that older clients could no longer read the file. So they rebuilt against Berkeley DB 4.8 and shipped it again. A security release is not much use if upgrading to it risks your users' wallet files.

Why this matters beyond two small chains

Most people reading this hold neither RVN nor TLS. The pattern is what generalizes.

Forked chains share a bug surface, and almost nobody tracks it. Litecoin, Dogecoin, Bitcoin Cash, Ravencoin, Zcash and dozens of others descend from Bitcoin Core, and every one of them carries a divergence point after which upstream fixes stop arriving automatically. A vulnerability disclosed in one chain is a live question for every chain downstream of the same code — and the further a fork has drifted, the more work it takes to know whether the fix even applies. Telestai answered that question in two days. Not every fork has someone whose job that is.

"Nobody exploited it" is not the same as "it wasn't there." Telestai's node software was vulnerable for its entire existence. The bug was real the whole time; only the attention was new. Chains that never get an incident report from a sibling don't get to find out this way.

A fix that lands before an exploit costs almost nothing. The same fix after costs a reorg. The technical work in Telestai 2.1.8 and in Ravencoin's hard fork is broadly the same patch. What differed was everything around it: whether there was invalid history to discard, whether exchanges had to halt, whether users' confirmations meant anything for three days.

This is the same reasoning behind reproducible builds and dependency scrutiny — most of what protects you is upstream of anything you can see from inside a wallet, and it is maintained by people paying attention on your behalf.

What this means in SSP

Practically: nothing changes for you.

SSP supports Ravencoin, and our node runs 4.8.0 on the recovered chain — we verified the block hashes on either side of the reorg against the reference chain in yesterday's piece. SSP does not support Telestai, so there is no Telestai balance in your wallet to worry about.

The reason we're writing about a chain we don't support is that the story is a clean illustration of something we do take seriously. Running node infrastructure means tracking upstream security work for every chain we carry, including the ones whose codebases share ancestors. The value in that is entirely invisible when it works — a patched node looks exactly like an unpatched one right up until the day it doesn't.

Telestai's August is what that looks like from the inside: a maintainer reads about someone else's exploit, recognises the shape of it in their own tree, and ships. No incident, no reorg, no announcement anybody outside would remember. Just a version number going up.