Pearl (PRL) Forks: Full Timeline, What Changed, and What Miners Must Do

Pearl (PRL) changes its mining rules more often than any other coin. Over the summer of 2026 the network went through three forks, and after each one a slice of miners discovered they'd been burning electricity for nothing: the miner reported a healthy hashrate while the pool credited zero shares. This page isn't a one-off news item — it's a living reference that collects every Pearl fork, explains in plain language what actually changed, and gives you a checklist so you never mine into the void.

📌 Status as of October 3, 2026: the last fork that affected miners is the August 11 hard fork (salted noise-seed). Node releases v1.4.6, v1.4.8 and v1.4.11 (September 1, 16 and 29) are maintenance releases and don't require a miner update. The next hard fork, a move to FP8 (certificate v4), is in development with no date announced. Judging by the code, it targets H100, B200 and RTX 50 cards, without RTX 30/40, AMD or Intel. Details: Pearl FP8 hard fork: what happens to RTX 30 and 40 cards.

Why Pearl forks so often

Pearl is a very young network (mainnet launched April 27, 2026) with an unusual mechanism. Instead of computing meaningless hashes, the miner performs matrix multiplication — AI-style computation. That's Proof-of-Useful-Work.

This approach has a side effect: a fresh protocol contains loopholes that let some miners earn rewards out of proportion to their real work. When the team finds one, they close it with a fork. So Pearl's forks aren't developer whims — they're patches applied as holes are found. And more forks are likely.

For a miner this means one thing: mining Pearl demands attention. You can't set up a .bat and forget it for a month — that works with most coins, but not this one.

Two terms: soft fork vs hard fork

To follow the timeline you need to tell the two apart:

• Soft fork — the rules tighten, but old miners technically keep working. They just start earning less (or almost nothing). Nothing visibly breaks, which is exactly what makes it treacherous: you can go weeks without noticing.
• Hard fork — the rules change incompatibly. Old miners submit shares the network treats as invalid. Rewards drop to zero.

Both share the central Pearl trap, described next.

The main trap: hashrate on screen, nothing in your balance

This is the single most important thing to understand about Pearl forks, and it's what most write-ups leave out.

After a fork, an outdated miner throws no error. It starts, connects to the pool, and displays a full, healthy hashrate — everything looks perfect. But the network already treats its shares as invalid or penalized, and the pool credits nothing. ForgeMiner's developer put it in one line: full hashrate on screen, nothing accepted by the pool.

Why? Because hashrate is what the miner computes about itself. Only the pool credits work, and it does so by the network's rules. If the rules changed and the miner "doesn't know," it works faithfully by the old rules and reports faithfully — but the output is worthless.

Takeaway: when mining Pearl, never judge by the hashrate in the miner window. Watch the pool stats — accepted shares and credited balance. If the miner shows hashrate but shares on the pool aren't climbing or the balance is flat, you're almost certainly on an old version.

Timeline of Pearl forks

1. Dense-only soft fork — July 23, 2026

The first notable fork, node release v1.2.1. Technically it clarified which types of "proofs of work" the network accepts: only the larger "dense" proofs counted as full proofs, and some lighter variants stopped conferring an advantage.

What it meant for miners: most regular miners didn't notice — the change mostly concerned non-standard optimizations. But it was the first clear signal that the team would actively close loopholes.

2. Rank-penalty soft fork — August 6, 2026 (block 96251)

The most discussed fork, node release v1.3.0. It activated around 02:00 UTC at block 96251.

What rank is, in plain terms. The Pearl protocol has a noise rank parameter. Roughly, it's a "difficulty setting" for the problem the GPU solves. The higher the rank, the easier it was to get a valid result (called a jackpot) for the same amount of work. Some miners spotted this and deliberately ran at high ranks — collecting a disproportionately large effective hashrate and reward. That was unfair to everyone else.

What changed:

• The minimum allowed rank became 128.
• The jackpot bound now scales by 128 / rank. So the higher the rank, the worse the terms — the high-rank advantage was removed entirely.

What it meant for miners:

• Anyone mining at rank ≤ 128 lost almost nothing.
• Anyone mining at rank > 128 lost 50–87.5% of effective hashrate. A miner at rank 256 started earning half as much; at rank 1024, one eighth.
• Crucially, this was a soft fork: old miners kept running and showing their old hashrate. Only the payouts differed. Many people learned about the fork the next morning from a sudden drop in income.

Updated miners moved to the new rank and collected the full reward. For some (e.g. ForgeMiner 1.5.4) raw hashrate actually dipped slightly (1–2%) after updating, because the new rank costs a bit more work per share — but income returned to full.

3. Salted noise-seed hard fork — August 11, 2026 (block 99000)

Just five days after the soft fork came a mandatory hard fork, node release v1.4.1. It activated at block 99000 (some sources cite block 98900 — a hundred-block discrepancy, same event).

What "salt" is, in plain terms. Every problem the miner solves is built from "noise" (random data). Previously the way that noise was derived was predictable, which apparently opened another door for unfair optimizations. The hard fork added a "salt" — an extra secret ingredient in the noise derivation — so the old calculation method now produces wrong results.

What changed: the pearlhash algorithm itself changed (pools said so directly: "the Pearl team has changed the algorithm"). This is protocol version 2.

What it meant for miners:

• It's a hard fork: every old miner version started submitting invalid shares. Reward: zero.
• And once again the main trap: old miners kept displaying a healthy hashrate while earning nothing.
• Updating was mandatory for everyone. One subtlety: some new miner versions (e.g. PeakMiner 2.9.0) worked only after block 99000 — you couldn't run them before the fork. That's moot now; the fork is long past.

⚠️ Because of this hard fork, every miner version published in news posts on August 5–6 for the rank-penalty soft fork no longer works. If you've found an article listing versions like Krig 1.1.0, PeakMiner 2.7.1, or ForgeMiner 1.5.4 — that list was obsolete the very next day. Current versions are in the table below.

Current miner versions (after the August 11 hard fork)

Minimum versions that support the current algorithm. Anything older earns nothing.

📌 These are minimum versions. Always grab the latest (Latest) from each miner's releases page — since the hard fork almost all of them have shipped several more updates with optimizations. For a safe download and hash check of SRBMiner, see SRBMiner-Multi: How to Download, Set Up, and Run It.

Checklist: make sure you're earning, not heating the room

Run through this after every update and whenever your income suddenly drops.

1. Compare your miner version against the table above. The version is usually printed in the first lines of the miner window at launch. If it's below the minimum, update immediately.

2. Watch the pool, not the miner. Open your worker's stats on the pool's website. What should be climbing: accepted shares and balance. The hashrate in the miner window tells you nothing.

3. Check rejected shares. If the share of rejected/invalid shares in the miner log or on the pool jumps sharply, that's the first sign of a fork. What rejected shares are and what percentage is normal: Rejected shares: why they happen and how to fix them.

4. Update the miner fully, not "over the top." Download the fresh archive, extract it into a new folder, and move your .bat across. On HiveOS, note: a Flight Sheet with an already-imported miner keeps the old installation URL and will not update itself. You have to replace the URL with the new version manually.

5. Wait 10–15 minutes after updating and check the pool again. Shares should start being accepted.

How to learn about the next fork in advance

Pearl forks are announced, but beginners usually find out after the fact — from a drop in income. Here's where to watch so you're ready:

• Pearl's official GitHub repository (pearl-research-labs/pearl, Releases section). Forks are always flagged in the release name — "rank penalty softfork," "Salted Noise-seed hardfork." You can subscribe to release notifications.
• Your miner's releases page. Miner authors (SRBMiner, PeakMiner, Kryptex) ship updates before a fork activates, marked "MANDATORY UPDATE" with the activation block.
• Your pool's news. Major pools (2Miners, Kryptex) publish warnings and lists of compatible versions.
• The Pearl block explorer. A fork activates at a specific block. Knowing the block number from the announcement, you can watch the explorer for when it arrives.

Tip: if you run several rigs on Pearl, make a habit of checking the Pearl releases page every few days. Five minutes a week versus days wasted.

What to expect next

No guarantees, but the logic runs like this: Pearl is an experimental protocol in which loopholes will keep being found and the team will keep closing them. Three forks in six weeks is a pace unlikely to slow dramatically soon. On top of that, per-card revenue has already dropped noticeably since launch, and difficulty keeps rising.

That doesn't mean Pearl isn't worth mining. It means Pearl is a coin for people willing to keep a finger on the pulse. If you're just starting, the base guide is here: How to Mine Pearl (PRL) on a GPU.

Frequently asked questions (FAQ)

My miner shows hashrate but the pool credits nothing. What do I do? You're almost certainly on a miner version that doesn't support the latest fork. Compare your version against the table above and update to the newest release. Hashrate in the miner window doesn't mean shares are being accepted.

What's the difference between a soft fork and a hard fork? With a soft fork the old miner keeps running but earns less (50–87.5% less under rank-penalty). With a hard fork the old miner submits invalid shares and earns nothing. Either way, you need to update.

What is rank in Pearl? The noise rank parameter — roughly, a difficulty setting for the problem. High rank used to give an unfair advantage: a valid result came easier for the same work. The August 6 soft fork set a minimum rank of 128 and a 128/rank penalty, removing that advantage.

Do I need to change anything in my .bat after a fork? No. Updating the miner to a compatible version is enough — it follows the new rules automatically. Your .bat with the pool address and wallet stays the same.

Has there been a fork since August 11? As of October 3, 2026 — no. Releases v1.4.6, v1.4.8 and v1.4.11 are maintenance releases and don't affect miners. The next hard fork, FP8, lives in a separate GitHub branch with no activation date. What's in it and which cards it leaves out: Pearl FP8 hard fork. This page is updated when new forks appear.

I'm on HiveOS, I updated the miner, but it's still the old one. Why? The Flight Sheet stores the installation URL of a specific version and doesn't update itself. Replace the URL in the custom miner settings with the link to the new version.

This material is for informational purposes only and is not financial advice. Fork information is current as of the page's update date; Pearl is an experimental network whose rules may change.