An independent, dated, code-evidenced ledger of every consensus change on Pearl Network mainnet. Maintained by Keshi as part of its research track; facts sourced from Keshi's internal protocol notes with per-row code evidence.

Why this exists. Pearl has shipped four consensus changes with no PIP: the dense-only softfork (PCCR-0003), the IsMoE semantic fix (PCCR-0004), the rank-penalty softfork (PCCR-0005) and the salted noise-seed hard fork (PCCR-0007). One activated change carries a PIP, the MoE hard fork (PCCR-0002, PIP-2). The PIP repository contains three documents, PIP-1 (process), PIP-2 and PIP-3 (PIPS/pip-0001.md, pip-0002.md, pip-0003.md; 3P, listed 2026-08-11). The code, not the PIPs, is the de-facto governance record, and nobody else keeps this ledger. The register states verifiable facts about public repositories and the presence or absence of documentation; it attributes no motive and describes no low-level protocol mechanism (disclosure discipline per Keshi's internal disclosure policy).

Counting rule (stated once; it governs every count in this register). The unit is an activated mainnet consensus change, one per entry. Activation is height-gated (PCCR-0002, 0003, 0005, 0007) or release-gated (PCCR-0004); both count. The genesis baseline (PCCR-0001) is a rule set rather than a change and is excluded. An entry that has not activated (PCCR-0006, Draft) is excluded until it does. Testnet and testnet2 activations are recorded inside the entries and in the Release review log, and are never counted. On that rule the register holds five activated mainnet consensus changes as of 2026-08-11 (PCCR-0002, 0003, 0004, 0005, 0007), four of them with no PIP.

Correction (2026-08-11): the "Why this exists" paragraph above read "three consensus changes with no PIP" until this date. That count was correct through PCCR-0005 and became four when PCCR-0007 activated at height 99,000.

Note (2026-08-10). Keshi authored three PIP drafts, committed at ../research/outreach/: weight-identity commitments (Standards Track / Consensus), weight-provenance disclosure and verification (Standards Track / Applications), and consensus-change documentation and activation notice (Process; it draws on this register's record). All three are labeled Draft and have not been submitted. Under Keshi's site-first publication policy they publish on Keshi's own site as clearly labeled drafts; submission to the upstream PIP repository is a separate operator decision. The register itself is unchanged by this: it records what Pearl ships, with evidence, independent of any proposal Keshi drafts.

Maintenance rules.

• Entries are append-only and never renumbered. Corrections ship as dated errata lines inside the entry, never as silent edits.
• Every claim carries code evidence in the form file:line @ tag against the pearl-research-labs/pearl repository, or a PIP reference.
• Observed links Keshi's own measurement of the change where one exists.
• A new pearld release triggers a review of chaincfg, wire, blockchain and zk-pow diffs for candidate entries. Automated since 2026-08-07 by scripts/pearl-release-watch.py (daily timer): it flags unreviewed releases and may append REVIEW PENDING placeholder rows to the Release review log below. It never authors entries and never fills a Result; humans do the review.

Confidence legend: SRC (pinned source), WP (whitepaper), LIVE (observed on chain/infrastructure), 3P (third party).

PCCR-0001: Genesis consensus baseline

The launch rule set: V1 certificates, dense-only PoUW (tiled INT8 matmul, BLAKE3 tile predicate, Plonky2 proof), WTEMA difficulty, smooth ~1/t² emission with no halvings, Taproot-only outputs, OP_CAT and OP_CHECKXMSSSIG active in tapscript from block 0.

PCCR-0002: MoE hard fork (V2 certificates)

Update (2026-08-09): answered: 1,929 MoE certificates in the window (OBS-003 §2); governance note OBS-006.

PCCR-0003: Dense-only softfork (MoE retracted)

The capability introduced by PCCR-0002 was retracted ~19,700 blocks (≈44 days) after activation, without a PIP in either direction beyond PIP-2 itself.

Precision (2026-08-09): measured from the two activation block timestamps (/v1/blocks/{71935,91630}), the window is 19,695 blocks and 41.0 days (2026-06-12 → 2026-07-23); "≈44 days" above was a block-count × target-time estimate. Usage measurement and governance note: OBS-006.

PCCR-0004: IsMoE semantic fix

Small, but it changes which serialized certificates a node classifies as MoE. It is recorded because classification feeds validity under PCCR-0003.

PCCR-0005: Rank-penalty softfork

Testnet activations: testnet 36,761; testnet2 80,627; regtest 1.

Precision (2026-08-11): the "~18.5 hours" in the Shipped-in row is wrong. Recomputed from the two endpoints: v1.3.0 was published 2026-08-05 15:45:09 UTC (GitHub release publishedAt, 3P) and block 96,251 carries timestamp 2026-08-06 03:59:44 UTC (05:59:44+02:00 on our index, LIVE), a difference of 44,075 s = 12 h 14 m 35 s, about 12h15m. The 18.5-hour figure is not reproducible from these timestamps. The original row stands unedited per the maintenance rules.

PCCR-0006: PIP-3, V3 FP8 certificates (DRAFT)

Erratum (2026-08-11): certificate version 3 was consumed by the salted noise-seed hard fork (PCCR-0007), activated at mainnet height 99,000 on 2026-08-11. node/wire/certificate.go:84 @ v1.4.1 defines CertificateVersionV3 = 3 as the salted-seed certificate (SRC) and block 99,000 carries it (LIVE). PIP-3's proposed "V3 FP8" numbering is therefore stale as of that date: the number is taken, so an FP8 certificate would need a different one. The draft's substance is untouched by this, and PIP-3 remains Draft with no activation height. Nothing in the shipped V3 is FP8; the two are separate changes that collided on a version number.

PCCR-0007: Salted noise-seed hard fork (V3 certificates)

Other networks at v1.4.1 (SRC): testnet 38,648 (params.go:565), testnet2 83,109 (params.go:661), regtest 1 (params.go:455), simnet 1 (params.go:744). The counting rule keeps these on the record and out of the count.

Notice window: 1 h 33 m 56 s (about 1h34m), from the v1.4.1 release publication, 2026-08-11 10:29:47 UTC (GitHub release publishedAt, 3P), to the timestamp of block 99,000, 2026-08-11 12:03:43 UTC (our index, LIVE). The basis is the release carrying the height that actually activated. v1.4.0 carried the fork at a different height and produced no release event to measure from: gh release view v1.4.0 returns "release not found", and the tag ref resolves to commit fc5ca65a, committer date 2026-08-11 08:54:49 UTC (3P), which is 3 h 08 m 54 s before block 99,000. Both bases are shorter than PCCR-0005's, restated in the precision note there as 12 h 14 m 35 s.

Three mainnet heights appear in the public record for this fork. PR #280's body as opened at 2026-08-11 07:51:21 UTC gave MainNet 98830; the body was edited at 2026-08-11 08:36:07 UTC to 98900 (GitHub body edit history via the GraphQL userContentEdits field, 3P). 98900 is the value in the v1.4.0 code and in the upgrade guide at that tag. PR #282 (opened 10:17:16 UTC, merged 10:19:28 UTC) moved the mainnet height to 99000, bumped the version to v1.4.1 and updated the guide. Block 98,900 was mined at 2026-08-11 10:47:07 UTC carrying a V2 certificate (LIVE), 17 m 20 s after v1.4.1 was published, so the replacement height shipped before the height it replaced was reached.

Documentation state at v1.4.1 (SRC): the repository's docs/ directory holds two files, moe-fork-upgrade-guide.md and salted-seed-fork-upgrade-guide.md (108 lines). The latter gives the fork heights per network and upgrade steps for nodes, proving code and miners, and states that mining software deriving seeds the old way produces invalid shares from the fork height on, which is the operational difference from PCCR-0002, where old miners kept working. The v1.4.1 release notes body is a heading plus a changelog link (3P). No PIP.

Observed (2026-08-12): OBS-012 measures the fork's effect on declared certificate arithmetic. On a count-matched 80-block window each side (a full post-fork day does not exist yet), the declared over-declaration tail truncated while the median block's declared arithmetic is unchanged. A metering-integrity effect, the declared m and n are now self-consistent with the mined seed and cannot be chosen after a solution is found; it is not evidence that useful work or real inference occurred.

Register opened 2026-08-06. Entries PCCR-0001…0006 seeded from the verified facts dossier as of pearld v1.3.0.

PCCR-0007 added 2026-08-11 from the v1.4.0/v1.4.1 review, against pearld v1.4.1.

Release review log

Every pearld release is reviewed for consensus-relevant diffs (chaincfg, wire, blockchain, zk-pow) per the maintenance rules. Releases producing no mainnet entry are logged here so "no entry" is distinguishable from "not reviewed".