Headline result

The pre-registered weight-provenance scan asked whether any block’s committed operand is byte-identical to a tensor of a published model checkpoint. For a bounded population of blocks over a bounded span of heights it is, with nothing matching in the negative control and nothing matching after the last one. A match identifies the weights a block committed to, never that a model was run end to end.

Standing documents

Observation notes and pre-registrations

1. obs-001Preliminary2026-08-06

   OBS-001: The rank-penalty softfork transition (height 96,251)

   When the rank-penalty softfork activated at height 96,251, miners converged on the cheapest-valid configuration within blocks. This note measures that transition: the rank collapse, the pool-share shift, and what held invariant.

2. obs-002Provisional2026-08-06

   OBS-002: Full-chain script-usage census

   A full-chain census of what Pearl’s script system is actually used for, including the finding that OP_CAT, the headline capability, has never executed once in chain history.

3. obs-003Recorded2026-08-06

   OBS-003: Phase 7 acceptance at the fork boundary, and first full-corpus census

   The acceptance test for Keshi’s certificate-arithmetic series: the new accounting had to reproduce the fork discontinuity OBS-001 measured, or it would not ship. It passed, and the same census refuted the assumption that Pearl’s MoE window went unused.

4. obs-004Results2026-08-06

   OBS-004: Real-inference detection results

   The pre-registered shape-consistency classification, run over 96,406 certificates. Every statement is consistency with a signature. Nothing here proves inference occurred, and per-block accusations are never made.

5. obs-005Recorded2026-08-09

   OBS-005: Attested model-weight mining on Pearl: the weight-provenance scan

   The pre-registered weight-provenance scan: 1,110 blocks commit byte-exactly to published checkpoint tensors across three model species, with zero hits against 1,000 control blocks (2.13 million pairs), and consensus verification provably computed the sampled outputs from strips of those tensors after a publicly derivable perturbation (the attestation is one-sided toward the weights operand). Resolved to operators, the finding is launch-week adoption by a handful of operators that wound down inside the chain’s first six weeks; the coverage-completion run then matched all 43 Gemma-candidate blocks nobody had ever hashed. Only public static checkpoints are externally verifiable at all, so every zero is bounded by that ceiling.

6. obs-006Recorded2026-08-09

   OBS-006: The MoE window and its undocumented retraction

   Pearl’s only PIP-documented consensus change legalized mixture-of-experts proofs. The capability saw real production use (roughly one block in ten while legal), then a softfork no document proposes or explains rejected it again 41 days later. Pearl now distributes a checkpoint whose architecture its own consensus will not accept proofs for.

7. obs-007Recorded2026-08-10

   OBS-007: Rank-escalation economics (Open question 4)

   Why did the mining rank climb from 128 to 1024? From the difficulty rule in source, it bought nothing: expected work per block is 2^256 over the target, independent of rank, so reward per real multiply-accumulate is rank-invariant, and the later penalty only taxes high rank. No declared batch dimension ever needs a rank above 128. The escalation was the adoption curve of custom, off-official mining software, not a difficulty exploit.

8. obs-008Recorded2026-08-10

   OBS-008: Network-configuration and mining-software census

   After the rank-penalty fork three legal configuration profiles coexist, not two: pools hugging the cheapest legal minimum, one pool running an intermediate band, and one sitting at the legal maximum. A tile-pattern census separates the mining software behind the blocks into 36 signatures; the unmodified official stack accounts for about a quarter of all blocks and still runs at the tip. Tile patterns identify software, never honesty.

9. obs-009Recorded2026-08-10

   OBS-009: Entity clustering over the full miner population (Phase 14.1, DS-004)

   Clustering coinbase addresses that spend together reveals that on the all-time cumulative basis the second-largest block producer in the chain’s history is an unattributed genesis-era fleet of about 107 uniform workers that mined roughly 29% of blocks up to height 30,768, then went dark, and still holds about 27.6M PRL. Address-basis decentralization figures hide it, and the full-network Nakamoto coefficient falls from 49 addresses to 12 entities on its account alone. It is a historical fact, not a current-window threat.

10. obs-010Recorded2026-08-10

    OBS-010: Non-pearl-ai shape sweep, ended vs moved

    When attested model-weight mining went extinct, did useful-work mining end, or move to models the scan could not see? Sweeping every declared certificate shape against a 36-checkpoint dictionary of open-model geometries, plus a nine-checkpoint vision, audio and embedding screen, finds no post-extinction signature that survives a computed specificity bar. The verdict is ENDED within stated coverage bounds; weights the chain cannot verify stay untestable by design.

11. obs-011Recorded2026-08-10

    OBS-011: Coinbase-tag census over the full chain (plan item 2.2, DS-005)

    The coinbase scriptSig is discretionary space a miner can fill with anything, and this census reads it for every block in heights 0 to 97,000 (97,001 in all). 86% of those blocks carry the stock node template, so voluntary tagging is established practice; two pools go further and stamp a self-label that falls on exactly the payout address an independent label already names, which cross-validates both. A coinbase tag is self-declared: it identifies software or a chosen string, and never who mined a block.

12. obs-012Recorded2026-08-12

    OBS-012: Declared certificate arithmetic across the salted noise-seed fork (plan item A4)

    The salted noise-seed hard fork at height 99,000 ties a block’s declared matrix dimensions to the noise seed it actually mined under, so they can no longer be chosen after a solution is found. Measured across the boundary on block-count matched windows, the median block’s declared arithmetic is unchanged while the over-declaration tail is truncated: blocks declaring a dimension above 2^20 fall from 34 of 80 to 0 of 80. The fork binds self-consistency, not honesty; nothing in it establishes that a real model was evaluated.

13. prereg-001Pre-registered · frozen2026-08-06

    PREREG-001: real-inference detection over the certificate corpus

    Hypotheses, tests, thresholds and the interpretation of every possible outcome, fixed and frozen before the analysis ran at scale. Corrections ship as a new document, never as an edit.

14. prereg-002Pre-registered2026-08-07

    PREREG-002: weight-provenance scan over the certificate corpus

    The plan for testing whether any block’s on-chain commitment matches a published model’s weights, written before the scan runs. It also records what the published checkpoints actually store: the down-projection is quantized FP8, so it cannot mine at all, which corrects an expectation OBS-004 relied on.

15. prereg-003Pre-registered · frozen2026-08-10

    PREREG-003: coverage closure, layout probes, and the control redraw

    The plan for four follow-up runs and a replacement negative control, frozen before any of them ran. It closes the coverage gap the frozen candidate classifier left, probes two buffer-layout conventions against the unmatched residue, screens third-party int8 checkpoints, and redraws the control by era stratum because the audit found the original control did not satisfy the null its own pre-registration stated. It also fixes in advance what a match inside that original control would mean, so the answer is not chosen after the result is known.

Proposals

Three PIP drafts Keshi authored against Pearl’s own proposal process. All three carry status Draft and were submitted to the upstream PIP repository on 2026-08-15, as pull requests 10, 11 and 12 against pearl-research-labs/pips, after a discussion issue there. Submission is a proposal, not an adoption: the upstream editors assign a number and decide whether to merge, and nothing here claims they have. They are rendered from the same repository as the notes above, at the commit shown on each page.

The argument behind the drafts ties each one to the measurement that motivates it, states what each would let a third party check, and states what none of them establishes.

1. PIP draftDraft, submitted upstream2026-08-10

   Weight-identity commitments for PoUW certificates

   Standards Track, Consensus: assign the 28 reserved mining-configuration bytes to an optional, stable identifier of the committed weight operand, so weight identity is recognizable on chain instead of requiring an observer to guess the operand and rehash it once per block.

2. PIP draftDraft, submitted upstream2026-08-10

   Weight-provenance disclosure and verification

   Standards Track, Applications: a signed disclosure format for asserting which published model tensors a set of blocks committed, and the procedure that grades each assertion match, no-match or not-checkable. It needs no consensus change and works on every block since genesis.

3. PIP draftDraft, submitted upstream2026-08-10

   Consensus-change documentation and activation notice

   Process: require a PIP and a minimum activation notice for every consensus rule change, document emergency and retroactive changes within a bounded period, and maintain a register of every change ever activated on mainnet, including the historical ones.

Data

Datasets and analysis scripts live in the source repository; every figure in a note traces to the exact files. docs/research on GitHub ↗ (external link)