Pearl’s MoE Hard Fork: Mining Moves to Mixture-of-Experts
Pearl is hard-forking to add Mixture-of-Experts mining — the architecture behind frontier LLMs. Ordinary miners don’t need to do anything; pools and node operators do. Here’s the plain-English breakdown.
Pearl has shipped a hard fork that upgrades its proof-of-useful-work from dense matrix multiplication to Mixture-of-Experts (MoE) — the architecture behind today’s frontier large language models. The reassuring part first: if you run an ordinary GPU miner, you do not have to do anything. Your existing miner keeps working before and after the fork. The work falls on mining pools and node operators, who must upgrade before the fork activates.
The change landed on 11 June 2026 in the v2.0.0 release (pull request #173, “Moe fork changes”). Pearl Research Labs published a full MoE fork upgrade guide alongside it.
What’s changing
At a fixed block height — the fork height — blocks switch from the V1 (dense) ZK certificate to a new V2 (MoE) certificate. In plain terms:
Useful work expands to MoE. After the fork, miners can optionally produce proofs for MoE models, not just dense matmul. Dense mining still works.
Hashing miners are unaffected. Old dense proofs are valid before and after the fork. No miner change is required to keep mining.
The consensus rule is versioned. A new field,
requiredcertversion, appears ingetblocktemplate:1means a block needs a V1 (dense) certificate before the fork,2means a V2 (MoE) certificate at and after it.
Why it matters
Pearl’s entire pitch is that mining does useful AI computation instead of throwaway hashing. Dense matrix multiplication is the foundation of that, but most state-of-the-art LLMs — think Mixtral or DeepSeek — are increasingly sparse MoE models, where only a few “expert” subnetworks activate per token. By bringing MoE into consensus, Pearl’s definition of useful work tracks how frontier models actually run today, rather than a simplified stand-in. It is the network keeping its core claim honest as the AI it mirrors evolves.
When is it happening?
The fork activates at mainnet block 71935. That height is set directly in the node’s chain parameters (MoEForkHeight), and at roughly 180 seconds per block it puts activation at around 13:00 UTC on 12 June 2026 — about nine hours after this was written. Block times vary, so the live block height on our explorer is the exact countdown. Pools should still not hardcode the height in their own code: read the requiredcertversion field from getblocktemplate, which flips from 1 to 2 exactly at the fork.
What you need to do
Solo and pool GPU miners (hashing only)
Nothing. Keep mining. Your dense shares remain valid through the fork. The one optional move — mining MoE — is covered below and must wait until after the fork.
Mining pools (you generate the ZK proofs)
You must upgrade before the fork height, or every block you build afterward will be rejected. The new pearl-mining package is v0.2.0; proving functions are now version-suffixed (generate_proof_v2, etc.), and you should pass requiredcertversion from the template to the certificate-version dispatchers. The V2 prover accepts both dense and MoE shares, so old miners on your pool keep working. Full code examples are in the upgrade guide.
Node operators
Upgrade your node to the latest release before the fork height. It stays fully compatible with old miners and V1 proofs until the fork, so it is safe to do at any time beforehand.
Miners who want to mine MoE (optional)
Wait for the fork. An MoE share cannot be certified before the fork height — deploying MoE-capable miners early is wasted work, and pools will reject those shares. After the fork, both dense and MoE shares are valid.
What we’re doing
We run our own Pearl full node behind our explorer, so we’re upgrading to v2.0.0 ahead of the fork height to keep following the chain cleanly through the transition. You can watch the live network state — block height, hashrate, and pool activity — on the explorer at any time, and we’ll note the exact fork block here once it’s set.
Frequently asked questions
Do I need to upgrade my miner for the Pearl MoE fork?
No, if you mine dense models. Ordinary GPU hashing miners need no changes — old (V1 dense) proofs stay valid before and after the fork. You only upgrade if you want to mine MoE models, and only after the fork height.
When is the Pearl MoE hard fork?
The code shipped on 11 June 2026 in the v2.0.0 release, and the fork activates at mainnet block 71935 — set in the node's chain parameters. At roughly 180 seconds per block that is expected around 13:00 UTC on 12 June 2026; block times vary, so the live block height on our explorer is the exact countdown. Pools should still read the requiredcertversion field from getblocktemplate (it flips from 1 to 2 at the fork) rather than hardcode the height.
What is MoE mining?
Mixture-of-Experts (MoE) is an LLM architecture where only a subset of "expert" subnetworks activate for each token, which is how many frontier models now run. The fork adds a V2 certificate so Pearl's proof-of-useful-work can certify MoE-layer computation, not just dense matrix multiplication.
Will the fork split the chain or affect my PRL balance?
No. It is a coordinated upgrade — balances and transaction history carry over unchanged. Old dense mining remains valid through the transition, so there is no contentious split as long as node operators and pools upgrade before the fork height.
Do Pearl mining pools need to act?
Yes. Pools that turn miner shares into ZK proofs must deploy the new v2 proving code (pearl-mining v0.2.0) before the fork height, or every block they build after the fork will be rejected. The cheap step is to read requiredcertversion from getblocktemplate and pass it to the version dispatchers.
Sources: Pearl v2.0.0 release · MoE fork upgrade guide · Pearl monorepo.
