Pearl hard forks and upgrades: what miners must do

Pearl changes its consensus rules at fixed block heights, and miners do not vote on them. Since mainnet launched on April 27, 2026, four upgrades have activated, each less than 15 hours after its node release. Here is every fork, the versions it required, what happened on the day, and the proposed FP8 upgrade, as of October 6, 2026.

Why upgrades matter

A hard fork makes new blocks invalid for old software, so every node and pool must upgrade, and miners too when the work changes. A soft fork only tightens the rules: old nodes still accept new blocks, but work that breaks the new rules stops counting.

Pearl activates both at a block height written into node/chaincfg/params.go. At the height, upgraded software switches by itself; old software keeps the old rules and its work is wasted.

The proof of useful work travels in a "certificate" attached to each block, a zero-knowledge (ZK) proof of the matrix work. Each hard fork brought a new version: 1 from genesis, 2 from block 71,935, 3 from block 99,000. Nodes report the required one in the requiredcertversion field of getblocktemplate.

• Node operators, including solo miners and Pearl Wallet users, install the new release before the height.
• Pools upgrade their node and their ZK proving code, or every block they build after a hard fork is rejected.
• Miners update when the work itself changes. Otherwise they produce invalid shares or lose 50% to 87.5% of their effective hashrate.

Timeline of Pearl upgrades

Data as of October 6, 2026, ~17:00 UTC. Sources: heights from params.go in the official repository; activation times from block timestamps on explorer.pearlresearch.ai; release times from GitHub releases.

MoE hard fork (block 71,935)

What changed. Mixture-of-Experts (MoE) AI models route each token through a few "expert" sub-networks, using many small matrix multiplications grouped together. Certificate version 2 made proofs of this grouped work valid (PIP-2, now Final).

Who had to act. Nodes (v1.1.0) and pools (proving package pearl-mining 0.2.0). Hashing miners did not: the official MoE upgrade guide says old dense proofs kept working, and MoE-capable miners were optional.

What happened. Node v1.1.0 had no GitHub release of its own; it shipped inside Pearl Wallet v2.0.0. @prlnet, the official X account, told users to update on June 12.

Dense-only soft fork (block 91,630, v1.2.1)

What changed. From block 91,630, nodes reject MoE proofs again, so only dense proofs, from ordinary single matrix multiplications, are valid. We found no published reason for the change.

Who had to act. Node operators and pools. Miners producing dense proofs, the default, were not affected.

What happened. Node v1.2.0, tagged at 08:13 UTC on July 23, set the fork at block 91,600. It had a bug: once the fork was active, the node rejected every block template it built (PR #261). v1.2.1, published at 10:05 UTC, fixed it and moved the height to 91,630, about an hour later. By then block 91,600 had already been mined (09:45 UTC), so any v1.2.0 node had been failing to build templates for 20 minutes. The fork activated at 10:57 UTC, 52 minutes after the release. The next 10 blocks took about 78 minutes; the chain did not halt.

Rank-penalty soft fork (block 96,251, v1.3.0)

What changed. Each Pearl proof adds low-rank "noise" to the matrices, and the miner picks the rank. From block 96,251, the rank must be at least 128, and a higher rank faces a proportionally harder target: a rank-256 proof counts half, a rank-1,024 proof one-eighth. Miner developers call it the "rank-128" fork.

Who had to act. Miners, nodes (v1.3.0) and pools, which must apply the same penalty when they credit shares.

What happened. v1.3.0 came out about 12 hours before the fork block. Kryptex warned that older miners using a rank above 128 "will lose 50–87.5% hashrate" (Kryptex news, August 6, 2026). SRBMiner 3.5.0 arrived three hours after activation and dropped AMD RDNA2 support for pearlhash. PeakMiner's README now says that since its v2.11.0, Maxwell, Pascal, Volta and GTX 16xx cards cannot mine Pearl under the rank-128 rules; it requires an RTX 20 card or newer (as of October 6, 2026). On August 13, a user reported a fresh node sync stuck at block 96,251 (issue #285); checkpoints added in v1.4.6 (September 1) let new nodes pass it. From August 7, f2pool suspended its PRL pool, citing "instability in the PRL network"; it resumed on September 30.

Salted noise-seed hard fork (block 99,000, v1.4.1)

What changed. Miners derive each job's noise from "seeds" computed from commitments to their matrices (Merkle roots). Certificate version 3 salts each root with a keyed BLAKE3 hash (BLAKE3 is the hash function Pearl's mining uses) that also commits the matrix dimensions. The salted-seed upgrade guide does not say why the change was needed.

Who had to act. Everyone: nodes (v1.4.1), pools (pearl-mining v0.3.1) and miners. Per the guide, old miners produce invalid shares from the fork height on. Pearl Wallet v2.0.5, which bundles node 1.4.1, came out at 17:23 UTC, more than five hours after the fork, so desktop-wallet users had no updated wallet at activation.

What happened. Node v1.4.0, tagged at 08:54 UTC on August 11, set the fork at block 98,900. v1.4.1, published at 10:29 UTC, delayed it by 100 blocks. Without the delay, the fork would have hit at 10:47 UTC, 17 minutes after the release. WildRig 0.50.1 shipped at 10:24 UTC and SRBMiner 3.5.3, titled "Just another emergency hardfork", at 10:39 UTC. Block 99,000 came at 12:03 UTC. The next block took 74 minutes, and the next 100 blocks about 12 hours (7.2 minutes each, against the 194-second target). We found no evidence of a chain split.

Miner versions that supported each fork

Sources: Kryptex news of August 6 and 11, 2026, "current miner versions supporting the PRL fork" (all rows except WildRig); WildRig Multi release notes. As of October 6, 2026, use the latest release from the developer's official repository.

What miners and pools must do

If you mine on a pool

1. Know the fork height. Compare it with the current height on the official explorer. At the ~165-second average of the 24 hours to October 6, 2026, 17:00 UTC, 500 blocks take about 23 hours; at the 194-second target, about 27 hours.
2. Update your miner before the height. Download it only from the developer's repository: SRBMiner-MULTI, BzMiner, WildRig Multi or PeakMiner (setup: how to mine Pearl). On October 6, 2026, a GitHub search for "pearl miner" returned 125 repositories, many with closed binaries from new accounts (see scams and fake tokens).
3. Check that your pool is ready. If it has posted no notice, ask.
4. Read the release notes, not just the version. WildRig warned that keeping --pearlhash-kernel after block 96,251 caused many rejected shares.
5. Watch rejected shares after the fork block. A jump means your miner or your pool still runs the old rules.
6. Expect slow blocks. After the August 11 fork, 100 blocks took 12 hours, delaying payouts.

If you run a node or mine solo

• Run the latest node, v1.4.11 (September 29, 2026; latest as of October 6). v1.4.1 was the minimum for the August 11 fork, but a fresh sync on it was reported stuck at block 96,251; the checkpoints that get past it arrived in v1.4.6. Never use v1.2.0 (template bug) or v1.4.0 (wrong fork height).
• Desktop wallet users: install Pearl Wallet v2.0.7 (September 30, 2026), which bundles node v1.4.11, not v2.0.5, which bundles v1.4.1.
• If you run the official vLLM miner, upgrade vllm-miner and pearl-gateway together with your node; no configuration change was needed for the salted-seed fork.
• Read every point release: both rescheduled heights came in a ".1" release.

If you operate a pool

• Upgrade the node and the proving package before the height.
• Read requiredcertversion from each template. Both official guides say not to hardcode the fork height.
• Verify each share with the certificate version of the template it was mined against: version 2 shares fail version 3 checks.
• Apply the dense-only and rank-penalty rules at share intake. The official example validate_share() does not, and crediting rank-256 shares without the penalty pays them double.
• Tell your miners which versions they need. The pool guide covers the proving workload.

What is next: the FP8 upgrade

FP8 is an 8-bit floating-point format widely used for AI inference. Pearl's next proposed hard fork would make FP8 matrix multiplication (the E4M3 variant) the unit of mining work, instead of integer matrices. The draft argues that most AI models run in floating point, so FP8 cuts mining overhead during inference; it concedes that FP8 results differ slightly from exact multiplication.

• Proposal: PIP-3, "FP PoUW Certificates", status Draft, created July 30, 2026, in the PIPs repository.
• Code: PR #311 (branch fp8-scheme), opened September 9, 2026 and still open on October 6.
• Announced: by @prlnet on X, with the specification and code, on September 14, 2026.
• Activation height: none. The branch sets one only for local test networks; mainnet leaves FP8 disabled.
• Certificate: version 4 in the code, carrying up to three recent block headers that pools will need from the template.

Which GPUs the FP8 reference miner accepts

FP8 results depend on how each GPU's tensor cores round and sum products (13 bits of accumulator precision on Hopper, 25 on Blackwell, per the specification). The verifier recomputes part of the work bit-exactly on a CPU for a named device, using the Hawkeye technique (arXiv 2603.20421, co-authored by Pearl co-founder Ilan Komargodski). The reference miner maps cards to allowed devices. NVIDIA labels each GPU generation with a compute capability code such as sm90.

Data as of October 6, 2026. Source: devices.py on the official fp8-scheme branch (unmerged code, may change before activation).

Other GPUs get a "no committed mining Device" error in the reference code. BzMiner v100.20 (September 11, 2026) claims to mine "certificate-v4 FP8 jobs on NVIDIA and AMD"; we could not confirm this work is valid on mainnet.

Warnings and unconfirmed reports

On September 19, 2026, the SRBMiner developer wrote in the 3.6.8 release notes that an upcoming Pearl upgrade would make consumer GPUs "pretty much useless". The founders held a Discord AMA on September 15, 2026. An attendee's notes, later repeated in a press article, say the FP8 code is done but needs a hard fork. They also say RTX 40 cards are expected to drop off and FP4 is targeted for the first quarter of 2027. Pearl has published no transcript, so treat these points as unconfirmed.

What it means for you. Nothing to do yet. If you plan to buy an RTX 30 or RTX 40 card for Pearl, the reference FP8 miner does not support it. See hashrate by GPU and profitability for what cards earn today.

How to follow releases

• GitHub releases. Every node and wallet release is on the releases page, with an Atom feed for feed readers.
• Node vs wallet naming. Node tags look like v1.4.11, wallet tags like pearl-wallet-v2.0.7. GitHub's "Latest" badge points to the node release.
• Upgrade guides. The MoE and salted-seed hard forks each came with a guide in the docs folder; params.go holds the real heights.
• Proposals. The PIPs repository (Pearl Improvement Proposals) and, for FP8, PR #311.
• Official accounts. @prlnet on X and the official Discord. We found no official Telegram channel.

Frequently asked questions