Why Pearl changed consensus four times in 27,000 blocks
Pearl passed mainnet block 99,000 this week, and with it the fourth consensus change in 27,065 blocks. Two of the four were hard forks and two were softforks, which matters for what a miner had to do but not for why any of them happened. Four upgrades that close together reads like a chain in trouble. It is closer to the opposite. Read in block order they are not four separate problems, they are one problem approached from four sides, and the last of them closes it. Every height, rule and version below is read from the chain's own consensus source rather than from an announcement.
What Pearl asks a miner to do
Start with what Pearl asks a miner to do, because none of the rest makes sense without it. Pearl launched its mainnet on 27 April 2026 as a layer one that secures itself with matrix multiplication rather than hashing. The multiply is the same dense linear algebra that AI training and inference spend almost all of their time on. A miner runs a noisy matrix multiply on the GPU, hashes the result into a commitment, and wraps that work in a zero knowledge proof so the network can check it cheaply. The base layer underneath is deliberately boring, a fork of Bitcoin's btcd node, so that the new idea sits on old and well understood plumbing.
Why the shape of the work matters
Now the hard part of that idea. When the work is a hash there is exactly one way to do it and exactly one number that says how hard it was. When the work is a matrix multiply, the miner also has to declare the shape of it: how large the matrices are, and how much low rank noise is folded in. The chain never sees the GPU. It sees a proof, and a description of the work that proof is about. Every one of the four upgrades is about that description, and about making each part of it cost something to claim.
Block 71,935: the mixture of experts certificate
The first, a hard fork at block 71,935, moved proofs from the v1 certificate to the v2 one. The upgrade is named for what the new certificate can describe: a mixture of experts, the shape real inference on a large model takes, where only a few experts out of many run for any given token. A proof format that can only describe one big dense multiply can only ever describe part of that. The v2 certificate also carries a field the v1 one did not, the noise rank, and that field is what made the third upgrade possible at all.
Block 91,630: dense only, for now
The second, a softfork at block 91,630, narrowed the door that had just been widened: from that block the network rejects mixture of experts proofs and accepts dense ones only. That looks like a reversal and it is not one. The certificate stayed at v2, so the format kept everything it had gained; what changed is which shapes count while the chain is young. The project has not published its reasoning for the timing, so this is where a reader should be told that and not handed a guess dressed as a motive.
Block 96,251: the rank stops paying
The third, a softfork at block 96,251, is the one with a number a miner can feel. The rank sets how much low rank noise is folded into the multiply, and before this fork the target a share had to beat was made easier in proportion to the tile size times the full dot product length. Turning the rank up therefore bought a proportionally easier target while the GPU did no more real work: the dial that decides how much of the computation is genuine was also the dial that decided how many shares you were paid for. From this block the same bound is scaled by the tile size times the dot product length divided by the rank times 128, and any rank below 128 is refused outright. Those two expressions differ by exactly 128 divided by the rank, so the effect on a miner still running the old setting is arithmetic rather than an estimate: at rank 256 the target is twice as hard as it used to be for the same work, and at rank 1024 eight times.
A consensus change that tightens what counts as real work can also retire hardware, because the tightened rule has to be produced bit for bit on whatever card is doing it. Whether any specific GPU generation lost Pearl support with this fork is a question for each miner's own release notes rather than for the chain, and this article does not name any, because the chain's source says nothing about cards. It is still the sort of thing worth checking before buying a card for one coin.
Block 99,000: the seed is bound to the shape
The fourth, a hard fork at block 99,000, is the smallest change and the easiest one to describe wrongly. The noise a miner multiplies against is derived from the proof's two Merkle roots. Before this fork those roots went into the derivation raw, so the noise did not depend on the matrix dimensions the proof commits to. From block 99,000 each root is first mixed with one of those dimensions, the row count for one and the column count for the other, and only then does the seed chain run. A given piece of noise therefore belongs to exactly one declared shape. The certificate layout is byte for byte what v2 was and the wire still carries the raw roots; only the version number selects which derivation applies, which is why the only thing this asked of a miner was a new binary.
What the four add up to
Put the four in a row and they say one sentence four ways. The chain cannot watch the GPU, so everything a proof claims about itself has to cost something to claim. Mixture of experts widened what a proof can describe. Dense only narrowed what counts while the chain is young. The rank penalty stopped one dial inside the claim from buying an easier target. The salted seed stopped one piece of noise from serving more than one claimed shape. A young chain finding these in its first months and fixing them inside 27,000 blocks is a better sign than a young chain that has found none.
What this means if you mine PRL
The practical part, for anyone mining PRL. All four activated at a fixed block with no transition period, and all four fail in the same quiet way: an out of date miner keeps reporting a perfectly healthy hashrate while its shares stop counting for anything. The hashrate number on your own screen is not evidence on a fork day. Watch your accepted share count instead, and update before the block rather than after it. If you merge mine, the loss doubles, because a Pearl share that is not valid carries no auxiliary block either.
On our side each of these was in place ahead of its fork block, so the only thing that had to change for a miner was the miner binary. Same address, same port, same wallet.
Where these numbers come from
Where the numbers come from, so anyone can check them rather than take our word: the four activation heights, the block time and the mainnet genesis timestamp are read from the chain's own network parameters and genesis definition; the rank rule and the 128 divided by rank figure are read from the proof verifier's sanity checks, where the old and new bounds sit next to each other; and the certificate versions and the salted derivation are read from the wire format and the seed module. Anything the source does not state is left out of this article rather than filled in.