Keryx-node-v1.5.6-PoM

Mandatory upgrade for every node operator, pools included. This release fixes the chain split of 2026-08-28 and the sync bugs behind it. No consensus parameter change, no activation gate: the fixes apply as soon as your node runs this build.

Upgrade — pick one

Option A — snapshot (recommended, ~5 minutes).

1. Stop keryxd.
2. Delete your datadir (~/.keryx-labs/keryx-mainnet/datadir by default).
3. Download and extract datadir.zip (17.7 GB)

• https://huggingface.co/datasets/Keryx-Labs/datadir/resolve/main/datadir.zip
• https://drive.google.com/file/d/1GtMzVPnxnLii1bPx5gRaOPYD6nFYOnDS/view?usp=sharing
• https://keryx-labs.com/datadir.zip

4. Start keryxd v1.5.6. The node is at the 2026-08-28 pruning point with the complete sealed service state and catches up to the tip in minutes.

Option B — resync from scratch (~1h15). Stop, --reset-db (or delete the datadir), start v1.5.6. The import of the sealed service state is now pinned to a checkpoint, so a fresh sync always lands on the complete state whichever peers serve it — it may just take longer while few peers hold it.

Nodes that have run continuously since before 2026-08-28 may restart in place; when in doubt, take option A.

Do it before your post-sync trust window expires (about 24 hours after your last sync): past that point a node starts enforcing the service state it carries, and a node carrying one of the partial states produced today will fork off.

Inference requests stay paused until the network has converged.

What was wrong, in one paragraph

Every node computed the same inference-reward events (same winners, same amounts, same strikes — verified across long-running and freshly synced nodes). But the coinbase mint of a reward was validated against the node's committed selected chain: a node validating several chain blocks in one batch checked the second and later blocks against an empty mint window and rejected a legitimate mint for good. Which nodes rejected which block depended only on how they had received it — that is the split. On top of it, a fresh sync could silently skip the import of the sealed service state and run on an empty one, and nodes that resynced during the day propagated states missing burns they could not re-derive.

Fixed

Consensus validation

• Reward mint window derived from the block's own selected parent (a DAG fact) instead of the committed chain store; identical from every node and on every chain candidate. Regression test included. (9f6af37a)
• KERYX_RATIO_DEBUG no longer runs inside the post-sync trust window, where it crash-looped the node. (457c96e8)

Sealed service state

• The import is mandatory: a failed verification no longer leaves the pruning point marked stable, so the next attempt cannot sync ahead with an empty state. The expected commitment is voted over the last 512 chain headers instead of read from a single relayed block. (114c971f)
• Mainnet checkpoint: the rows up to daa 84 318 294 must reproduce the pinned commitment of the complete state; peers serving a partial state are skipped. (94c5a64d)
• v11 peers ship and accept every finality-flushed row, not only the 78 000-daa band above the pruning point, so a fresh node imports the recent burns instead of re-deriving them blind. (1c0f8ac1)

Initial block download

• A node stale by more than a pruning depth falls back to the headers-proof sync instead of refusing every syncer — no datadir wipe after a long downtime. (a36fdc09)
• A node whose earlier sync was interrupted (headers present, bodies missing) triggers a pruning catch-up instead of asking peers for bodies nobody serves and disconnecting them one by one. (ae2ac706)

Peering

• Peers rejected for an obsolete keryxd version are banned for 24 hours. (e54310f0)
• One flat minimum peer version (1.5.3) for every node, whatever its own sync progress. (d2cbb9ab)

Protocol v11 — compact PoM proofs

By @fearke85 (#35). v4 possession proofs travel as a Merkle multiproof (~7.4% less bandwidth per block after gzip) and an IBD requester declares its own proof horizon. Transport only: the verified, stored and re-served proof is byte-identical to what the miner produced; v10 peers keep the full-path encoding. (105dcede, e61e96b0, ea69f22f)

Known limitation

Burns of escrows older than a fresh node's pruning point that happen inside its last finality window are still re-derived without seeing those escrows. The proper fix (rebuilding the escrow vault from the imported UTXO set) is scheduled for v1.5.7 with an activation gate.

Thanks to @fearke85 for the multiproof work.