Research · Proposals

Three drafts, and the measurements behind them.

Three drafts against Pearl’s own proposal process, each tied to the measurement that motivates it. Two of them come out of the weight-provenance scan: one standardizes the claim that a block committed to named published weights, the other adds the field that makes such a claim legible at mining time. The third comes out of the consensus-change register and asks only for documents and notice. None of them changes what a certificate proves, and the page says so at full weight rather than in a footnote.

Provenance disclosure · Draft, submitted upstreamWeight identity · Draft, submitted upstreamConsensus-change process · Draft, submitted upstream

The status word on each chip is read from that draft’s YAML frontmatter at build time and pinned to the commit shown beside it (verified against the document). “Submitted upstream” refers to pull requests 10, 11 and 12 against pearl-research-labs/pips, opened 2026-08-15 after a discussion issue there; that is a public artifact anyone can check, and it says nothing about whether the editors will assign a number or merge. Draft is the entry status in Pearl’s own process, so it is what a submitted proposal carries.

All three drafts are authored by InverseAltruism (@InverseAltruism), read from each draft’s frontmatter at build time, the same field the upstream process expects to carry a name or a handle.

Three facts sit under all three drafts. One thing is provable today and was measured. One thing is not provable at all for most work, by construction rather than by omission. And the record of what the consensus rules are lives in release diffs rather than in documents.

Provable today

1,110matched blocks

Committed operand byte-identical to a published checkpoint tensor, out of 53,718 candidate blocks: 53,717 recorded by the scan as shape-eligible, heights 1 to the frozen tip h96,774, plus 1 added by the coverage-closure round. Recomputable by anyone from raw block bytes and a published checkpoint. A match identifies the weight operand a block committed, and it never shows that a model was run end to end.

Basis: Combined corpus, the union of the 4 hashing runs fixed by the OBS-005 section 10 errata. Unit of analysis: blocks, resolving to far fewer coinbase addresses and fewer operators still. Block counts are not independent observations.

Not provable for most work

1of 6 weight classes

Only public, static checkpoints can be checked by an outsider at all. The rest are mutually indistinguishable on chain, so no result on this site separates them.

A property of the commitment scheme, not a measured population: job_key is derived per block, so identical weights hash to different values in different blocks and an observer can check a commitment only by guessing the exact bytes. Verified against OBS-005 section 0.1, which enumerates the classes; no share and no denominator applies to it.

Not documented

4of 5 activated changes

Activated mainnet consensus changes that no PIP documents. The one that has a proposal is the capability introduced at h71,935, retracted at h91,630 with no proposal in either direction.

Unit: activated mainnet consensus changes, one per register entry, on the register’s own counting rule. The genesis rule set is a baseline rather than a change and is excluded, as is any proposal that has not activated.

N7 · What a certificate proves

The claim ladder: each rung is strictly weaker evidence than the one below implies. Reading a figure above this rung boundary is over-reading it.

01Declared shapea claim
The certificate carries the matrix dimensions the miner says were multiplied (m, n, k) plus rank and tile parameters. Consensus checks their ranges, never their truth: any matrices that satisfy the predicate are accepted.
02Committed operandprovable, public checkpoints only
The certificate commits byte-exactly to the weight-side matrix with a keyed BLAKE3 root. Recomputing that root from a published checkpoint proves which operand was committed, and only public, static checkpoints can be checked at all: private, fine-tuned or evolving weights are indistinguishable from noise.
03Declared matmul, inference, customersnever provable on chain
The ZK proof opens at most 256 output entries of the declared result. It never proves the full declared multiplication ran, that inference occurred, or that anyone was served.

Declared dimensions are what the miner claims was multiplied; the ZK proof covers at most tileSize ≤ 256 output entries of the result, never the full declared matmul, and never a measure of AI work performed.

P0 · Which finding motivates which proposal

Each row is something measured; each column is a draft. The cells that read “not used” are the load-bearing ones: the process draft does not rest on the weight-scan result at all, and the two research drafts claim nothing about governance.

Finding

Provenance disclosure

Weight identity

Consensus-change process

Blocks committed byte-exactly to published checkpoint tensors

OBS-005. The pre-registered scan recomputed the committed operand from public data and found blocks whose commitment is byte-identical to a published tensor, over a bounded span of heights early in the chain’s life.

motivates

not used

Nothing matched in the constant batch-dimension stratum

OBS-005. Within the largest declared-shape mass point the scan searched, no block committed the published bytes. Declared geometry and committed bytes are decoupled, which is why a declaration cannot stand in for an identifier.

supports

motivates

not used

Only public static checkpoints are externally verifiable

OBS-005. Private, fine-tuned, locally requantized, evolving and synthetic weights are mutually indistinguishable on chain. This bounds every zero in the scan and every claim either research draft can make.

motivates

not used

Discovery cost one hash of every candidate tensor per block

OBS-005. With no identifier on the block, the scan had to guess: every candidate tensor was hashed against every eligible block. The committed pair counts are what that cost looks like as data.

supports

motivates

not used

Most activated mainnet consensus changes carry no PIP

PCCR register. On the register’s counting rule, one entry per activated mainnet change, the majority are documented by no proposal in either direction. The one change that has a PIP is the one whose capability was later retracted without one.

not used

motivates

Activation notice, where it can be measured at all, is measured in hours

PCCR register. Measured from the publication of the release carrying the height that activated to the timestamp of the activation block. Only two of the counted changes have a defensible interval at all; the rest carry a documented reason instead of a number, and the figure below draws no bar for them.

not used

motivates

motivates: The draft states this finding in its own Motivation and would not have been written without it.
supports: The draft uses this finding as evidence for a design choice, but does not rest on it.
not used: The draft does not cite this finding anywhere, and its argument does not depend on it.

Editorial mapping, not a measurement: the rows are findings from the two records named beside them, and the cells state how each draft uses each finding. Neutrals only and no ranking, because “motivates” is not a stronger version of “supports” and “not used” is a statement about a document rather than about evidence. The process draft cites no result from the weight-provenance scan, and the two research drafts assert nothing about how consensus changes are documented.

What the weight-provenance result would make possible

Provenance disclosure

Weight-provenance disclosure and verification

A signed, self-contained disclosure format asserting which published model tensors a set of blocks committed, verifiable by anyone from public data.

Draft, submitted upstreamStandards TrackCategory: Applications

Deployable today. No consensus change, and it applies to every block already mined.

PIP draft · DraftStatus read from the frontmatter (verified); “submitted upstream” refers to the 2026-08-15 pull requests against pearl-research-labs/pips, not to any decision by its editors.Created 2026-08-10docs/research/outreach/pip-draft-provenance-disclosure.mdCommit 937831d81e82sha256 76201540e9fa…PIP number unassignedUnassigned. The drafts carry the 9999 placeholder; the upstream repository assigns the number on submission.

Motivating measurement: OBS-005 recomputed the committed operand of 1,110 matched blocks from public data alone, on the combined corpus basis, out of 53,718 candidate blocks: 53,717 recorded by the scan as shape-eligible, heights 1 to the frozen tip h96,774, plus 1 added by the coverage-closure round. The verification primitive is public and cheap, and it has been exercised at corpus scale, but a verifier still has to guess which tensor a block might have committed before it can check anything. What is missing is a container for the claim itself, and a rule for what a checker may say about the result.
What it does: It fixes one JSON document in which a party asserts that a set of blocks committed named tensors of a published model at a pinned revision, signed with the coinbase payout key of the claimed blocks, with an optional OP_RETURN anchor that timestamps the document. It also fixes the verification procedure that reads such a document, and the vocabulary the result is reported in.
What it lets anyone verify: Anyone can grade each assertion in a disclosure from public data: match, no-match, or not-checkable. The third verdict is first class rather than a failure, because weights that are not public cannot be checked at all and a checker that silently folds them into “no” would be reporting a bound as a result.
What changes, and for whom: A miner gains a recognized way to say which published weights it committed, and gains nothing if it says nothing. A verifier gains a document to check instead of a guess. A node operator is unaffected: nothing here touches validity, relay or the wire format.
The hazard the draft states about itself: A disclosure is attached after the block is mined, so it can be attached, stripped or rewritten later; the signature binds a claim to a key and never to physical operation of any machine, since a payout key may belong to a pool or a custodian. Claim authenticity and claim truth are separate axes, and only recomputation settles the second.

P1 · The blocks a disclosure could claim, and when they stop

h0h96,774 (frozen scan bound)

5,000-block bins, 1,110 matched blocks on the combined corpus basis. Matched blocks per height bin as counts, never a rate: the scanned population changes composition across the span, so a per-bin share would be a composition artifact rather than a behaviour. A bin with a measured zero keeps a baseline tick, so an empty bin cannot read as an unscanned one, and the dashed rule is the frozen scan bound past which nothing was hashed at all. The interactive figure with its denominator control and its table twin stays on the OBS-005 page. Data tier: frozen. Scanned to h96,774; blocks above that bound were never hashed, and the live tip is higher and moving.

P6b · A disclosure, and the three verdicts it can earn

The document is written after the block exists, which is what makes this deployable today and what bounds what a signature can mean.

01One self-contained document states the claim
A checkpoint repository at a pinned revision, the buffer-construction convention that fixes byte order and sharding, the tensors with their digests, and one assertion per block: this height committed that tensor. A claim without a pinned revision is malformed, so a disclosure names an artifact rather than a model family.
02The signature binds the document to the coinbase payout key
The claimed blocks already pay a key on chain, so no external identity system is needed. A document with a missing or invalid signature still verifies as an anonymous claim, and a verifier reports signature validity separately from assertion truth, because they are separate axes.
03An anchor is optional and asserts nothing by itself
One transaction output carrying a tag and the document digest, spent from the same key, timestamps the claim and makes it discoverable by scanning the chain. The document still verifies or fails on its own; the anchor adds a date, not a truth value.
04The verifier grades every assertion, and one verdict is “not checkable”
Fetch the raw block, check that the header reproduces the block id, derive the key from those bytes, construct the claimed tensor and hash it under that key. Match is byte equality. No-match refutes the named tensor at the named revision under the named layout and nothing wider. Not-checkable is the verdict for weights that are not public, a layout that is not implemented, or a revision that can no longer be fetched, and folding it into no-match would report a bound as a result.

Static diagrams in neutrals, each with the same steps written out beneath it. The single highlight in each marks the one element that is a result rather than an input; everything else is a byte range, a document or a date. Data tier: draft. The 3 proposals are labeled Draft and were submitted upstream on 2026-08-15; the label is the entry status of Pearl's own process, not an outcome. Badges are read from each draft's own frontmatter at build time and pinned to the commit on the provenance card, so they follow the documents rather than a hand-kept list.

F9 · The anatomy of one match

Four steps, all of them recomputable from raw block bytes and a published checkpoint.

01Take the block’s own bytes
The first 76 bytes of the wire header, before the parts that depend on the result, followed by the 52-byte mining configuration from the certificate. Both halves are on chain and neither is chosen after the fact.
02Derive the per-block key
BLAKE3 over those two halves gives job_key, a 32-byte key unique to this block. Because it is per block, the same weights hashed for a different block produce a different root, and reuse of weights across blocks is undetectable.
03Hash the published tensor under that key
Take the tensor bytes as extracted from the public checkpoint and compute keyed BLAKE3 with job_key as the key. Nothing here is Keshi-specific: the buffer comes from the published checkpoint and the hash is the reference implementation.
04Compare with what the block committed
The certificate carries hash_b, the commitment to the weight-side operand. If the two are byte-identical, the operand that block committed to was those exact published bytes. That is the whole claim.

How one match is checked: the block’s own header and mining config derive a per-block key, the published tensor is hashed under that key, and the result is compared to the certificate’s committed value. Equality proves which bytes were committed, and nothing about what was computed with them afterwards. Data tier: frozen. Scanned to h96,774; blocks above that bound were never hashed, and the live tip is higher and moving.

What this would let anyone check, and what it still would not

What this proves

proven

That a named block’s committed weight operand is byte-identical to a named tensor of a published checkpoint at a pinned revision, recomputed by the reader from public data.
That the party publishing the claim controls the coinbase payout key of the blocks it claims, where a valid signature is present.
That an assertion is not checkable at all, as a reportable verdict in its own right, with the search space it was checked against stated alongside.

What this does not prove

not proven

Not that a model was run end to end, and not that any request was served: a verified assertion is an identification of the committed operand and stops there.
Not that the declared arithmetic ran in full; consensus opens a sample of the result and never all of it.
Not anything about private, fine-tuned or locally requantized weights, which stay not-checkable under this procedure rather than refuted by it.
Not who operated a machine: a payout key may belong to a pool or a custodian, so a signature proves key control and endorsement.
Not that an aggregate zero means no useful work occurred; the draft forbids that reading and requires the exact search space to ship with the count.

Unit of analysis: blocks, resolving to far fewer coinbase addresses and fewer operators still. Block counts are not independent observations.

Read the draft →

Weight identity

Weight-identity commitments for PoUW certificates

Assigns the 28 reserved mining-configuration bytes to an optional, stable identifier of the committed weight operand.

Draft, submitted upstreamStandards TrackCategory: ConsensusRequires PIP-2

A consensus change. It loosens a validity rule, so it needs a coordinated activation height at a later certificate version.

PIP draft · DraftStatus read from the frontmatter (verified); “submitted upstream” refers to the 2026-08-15 pull requests against pearl-research-labs/pips, not to any decision by its editors.Created 2026-08-10docs/research/outreach/pip-draft-weight-identity.mdCommit 937831d81e82sha256 29eaf1d2d0a0…PIP number unassignedUnassigned. The drafts carry the 9999 placeholder; the upstream repository assigns the number on submission.

Motivating measurement: OBS-005: within the constant m = 32,768 stratum, 0 of 50,049 scanned candidate blocks committed the published bytes, against 1,036 of 1,199 in the varying m (not 8,192 and not 32,768) stratum. A declared shape is free to write and is not the bytes that were committed, so an observer cannot tell which weights a block used without guessing them and rehashing once per block. The scan is what that costs in practice. The certificate already records everything needed to identify the operand; what is missing is a place to record it legibly.
What it does: It assigns the reserved must-be-zero trailer of the mining configuration to an optional identifier of the committed weight operand: one scheme byte and a truncated identifier, either a public content identifier anyone can look up or a salted pseudonym that means something only to a counterparty holding the salt. All zeros keeps today’s exact semantics.
What it lets anyone verify: On the public scheme, a third party looks the identifier up in a table of published tensors and confirms the hit with one keyed hash of that one named tensor. A mismatch proves the attestation false from public data alone. The claim it settles is the identity of the weight operand, and no scheme value here reaches the activation side or the arithmetic.
What changes, and for whom: A miner that ignores the field emits the same bytes it emits today, and the wire format does not grow. A miner running published weights can name them. A pool that vendors today’s certificate decoder must ship the parser relaxation before any of its miners sets the field, or the share is rejected without an error anyone reads.
The hazard the draft states about itself: A salted identifier is deterministic in the salt and the weights, so if both leak later, every block mined under that salt becomes retroactively attributable to those weights. For an auditor that is the point; for an operator it is a risk, and the draft says which mitigations exist rather than claiming the risk away.

F0b · Match rate by declared batch dimension

Every rate carries its own numerator and denominator. Strata are the declared m, which is a claim; the match is what is proven.

Varying m (not 8,192 and not 32,768)86.4%1,036 of 1,199
Constant m = 8,1923.0%73 of 2,469
Constant m = 32,7680.0%0 of 50,049
Measured zero: 50,049 blocks scanned, none matched. Not an absence of data.

Over every stratum together, 1,109 of 53,717 scanned candidate blocks matched (2.06%). The two constant strata are declared-shape mass points: n 57,344 k 8,192 at 31,831 blocks, n 28,672 k 4,096 at 16,530 blocks, n 10,240 k 8,192 at 1,688 blocks. Blocks from the DS-006 closure cells the frozen classifier omitted; scanned and matched, with no decoded declared parameters in the DS-002 extract.

Match rate within each declared batch-dimension stratum, each row labelled with its own numerator and denominator. Shape declarations are claims and the match is what is proven; a stratum reading zero means those exact published bytes were not committed, not that nothing was computed. Data tier: frozen. Scanned to h96,774; blocks above that bound were never hashed, and the live tip is higher and moving.

The separation the weight-identity draft rests on, reused unchanged from the result page: within the population declaring a varying batch dimension most scanned blocks committed published weights, and within the largest constant mass point none did. A stratum reading zero means those exact published bytes were not committed, and it is not a statement that nothing was computed. Two bases appear on this page and each figure states its own: the matched count above is 1,110 on the combined corpus basis, while a split keyed on a declared parameter can only cover the 1,109 matched blocks whose declared parameters the extract decoded. They differ by 1: the closure cells the frozen classifier omitted were scanned without a decoded extract record. Neither figure corrects the other.

P6a · The 28 bytes, and where they sit

The reserved trailer of the mining configuration, drawn to scale against the whole configuration.

01The region already exists and is already committed
The mining configuration is 52 bytes: 24 bytes of declared configuration, then a 28-byte trailer that must be zero. Every certificate since genesis carries that trailer as zeros, current nodes reject a certificate whose trailer is nonzero, and those bytes are already parsed and already hashed into the block identifier.
02The proposal spends those bytes and nothing else
Offsets 24:52 become one scheme byte plus a 27-byte identifier of the committed weight operand, either a public content identifier or a salted pseudonym. All zeros keeps today’s exact semantics, so a miner that ignores the field emits the bytes it emits today and the wire format does not grow.
03The region sits inside the job_key preimage
job_key is BLAKE3 over the first 76 bytes of the header followed by all 52 configuration bytes. Change the region and job_key changes; the weight commitment computed under that key changes; the noise seeds derived from the key and the commitment change; the transcript that has to hash below target changes.
04So the claim is an input to mining, not a label on a finished block
An attestation written here cannot be added, altered or removed after the fact without redoing the block’s work. Off-chain registries, coinbase tags and anchor transactions are all possible today without a fork and are useful as interim measures, and all of them lack exactly this property.

P4 · The cost of finding attested blocks without an identifier

Committed (block, buffer) pairs per hashing run. One pair is one keyed hash of one candidate tensor against one block.

DS-002-weight-scan-v14,401,184 pairs53,331 candidate blocks
One keyed hash per block the run hashed would be 53,331 pairs (dashed).
DS-002b-gemma-v1333,200 pairs43 candidate blocks
One keyed hash per block the run hashed would be 43 pairs (dashed).
DS-002b-o-tp48-v11,071,360 pairs343 candidate blocks
One keyed hash per block the run hashed would be 343 pairs (dashed).
DS-006-coverage-closure-v11,026,874 pairs6,570 candidate blocks
One keyed hash per block the run hashed would be 6,570 pairs (dashed).

The dashed mark on each bar is what the field proposes and not what anything measured. A bar also carries that run’s control pairs while the mark counts only its candidate blocks, so the two are two counts side by side rather than a rate, and no pairs-per-block figure is published here.

The note states the primary run’s cost in bytes and hours rather than in pairs: 4,401,184 pairs, “which is ~1.47 PB of keyed BLAKE3 computed as pairs times manifest buffer bytes, over 25.5 h.” That volume and that wall-clock figure are the primary run’s, over its own pair count, and they are not the pair total of all four hashing runs; the bars beside them carry each run separately for that reason.

Candidate tensors per block, not seconds. The bars are committed pair counts from the scan datasets, one (block, buffer) pair per keyed hash, which is what identifying attested blocks costs when no block names its own operand. A run’s pair count includes that run’s control pairs while its block count does not include the reused control blocks, so the two are reported side by side and never divided into each other; no pairs-per-block rate is published here. The wall-clock and volume figures are quoted from the note rather than drawn, because no committed artifact carries them as chart data, and the one-hash-per-block target is a proposal drawn as a reference line rather than a measurement. Data tier: frozen. Scanned to h96,774; blocks above that bound were never hashed, and the live tip is higher and moving.

What this would let anyone check, and what it still would not

What this proves

proven

That the block names a weight operand, in bytes committed before the work started: the field sits in the job_key preimage, so it cannot be attached to a finished block after the fact.
That a public identifier is true or false, settled by one keyed hash of the one named tensor against the block’s own commitment.
That a salted identifier is stable across blocks, to a counterparty holding the salt and to nobody else.

What this does not prove

not proven

Not that a model was run end to end, and not that any request was served.
Not that the declared arithmetic ran in full; the field adds no proof obligation and changes no circuit input.
Not anything about the activation operand: nothing in the protocol binds it to a real forward pass, so the identifier is one-sided toward the weights by construction.
Not the identity or intent of an operator: the identifier names weights, and the same public weights are available to anyone.
Not that unattested blocks computed nothing, since the default value is the value every block carries today.

Unit of analysis: blocks, resolving to far fewer coinbase addresses and fewer operators still. Block counts are not independent observations.

Read the draft →

What neither proposal would change

What a match proves, and what it does not

Neither research draft moves this boundary, and the process draft does not touch it. A disclosure standardizes a claim that is already checkable; an identity field makes the same claim cheap to find. What a match establishes is the same sentence in all three cases, so it is stated here once at full weight rather than qualified three times in passing.

What this proves

proven

The operand committed by that block was byte-identical to a specific published tensor, under a key derived from that block’s own on-chain header and mining config.
The sampled output entries consensus verified were computed from strips of that tensor, after a publicly derivable perturbation.
The block was accepted by mainnet consensus, so the commitment is on chain and anyone can recompute it from raw block bytes.

What this does not prove

not proven

Not that a model was run end to end, and not that any request was served.
Not that the computation was fresh rather than replayed or precomputed.
Not that the full declared arithmetic was performed; consensus opens a sample of the result, never all of it.
Not the identity, affiliation or intent of any operator: a match identifies weights, and the same public weights are available to anyone.
Not anything about private, fine-tuned or locally requantized weights, which are indistinguishable from noise on chain.

Unit of analysis: blocks, resolving to far fewer coinbase addresses and fewer operators still. Block counts are not independent observations.

P3b · What can be checked from outside, and what cannot

1 of the 6 weight classes the note enumerates can be checked by a third party. The other 5 are mutually indistinguishable on chain, so no result anywhere on this site separates them.

Public, static checkpointexternally verifiable

Anyone can construct the exact bytes from the published artifact at a pinned revision, hash them under the block’s own derived key, and compare with the commitment the block carries. This is the only class about which a match or a no-match can be stated at all.

Mutually indistinguishable on chain(5 classes, one undifferentiated group to any observer)

Private model
No published artifact exists to construct bytes from, so there is nothing to check against.
Customer fine-tune
Derived from a published checkpoint, but the derived bytes are not themselves published.
Locally requantized variant
The same architecture at different bytes. The requantization happens locally and is never published, so the operand is unreachable.
Evolving training weights
The bytes change between blocks, so even a party holding one snapshot cannot check the next block against it.
Synthetic noise
Random operands satisfy the consensus predicate by design, and on chain they look exactly like the four rows above. That is what makes this group mutually indistinguishable rather than merely unchecked.

The group markers are identical on purpose. A reader who could tell those rows apart here would be reading something the chain does not carry, and every zero this site publishes is bounded by that: a zero means those exact published bytes were not committed, and it says nothing about the group below.

A property of the commitment scheme, not a measured population, so there is no denominator to state and nothing here is a count: job_key is derived per block, which makes an operand checkable only by guessing its exact bytes. One class of weights can be checked by an outsider at all; the rest are mutually indistinguishable on chain, and no zero anywhere on this site excludes them. Verified against OBS-005 section 0.1, which states the enumeration this figure draws. Read section 0.1 of the note

P3a · The bound on every zero

The scan froze at h96,774. Everything above it was never hashed against any buffer, including the heights at which the register’s later consensus changes activated.

frozen scan bound h96,774PCCR-0007 activated h99,000

h0h99,000

Scanned: h1–h96,774; 53,718 candidate blocks hashed against 4,244 buffers over 4 runs, 6,832,618 pairs.
Never scanned: h96,775–h99,000; Blocks above the frozen bound were never hashed against any buffer. Nothing on this page is a statement about them, and an absence of search is not a negative result.

The height bound on every zero either research draft cites. The scan froze at its own tip; everything above it is drawn as absence and was never hashed, including the heights at which the register’s later consensus changes activated. Absence of a search is not a negative result. Data tier: frozen. Scanned to h96,774; blocks above that bound were never hashed, and the live tip is higher and moving. Data tier: dated record, append-only. Complete through h99,000 (2026-08-11), the last activated mainnet consensus change in the register when this dataset was compiled on 2026-08-12. A later activation adds a row; it never edits one.

A separate argument, from a separate record

The process draft rests on this record and on nothing else. Every entry is dated, evidenced against pinned source at a named tag, and appended rather than edited; a correction ships as a new dated line in the entry it corrects.

Consensus-change process

Consensus-change documentation and activation notice

Requires a PIP and a minimum activation notice for every consensus rule change, and a maintained register of all such changes.

Draft, submitted upstreamProcess

Process. No protocol change, no effect on deployed software, and nothing in it depends on the weight-provenance result.

PIP draft · DraftStatus read from the frontmatter (verified); “submitted upstream” refers to the 2026-08-15 pull requests against pearl-research-labs/pips, not to any decision by its editors.Created 2026-08-10docs/research/outreach/pip-draft-consensus-change-process.mdCommit 937831d81e82sha256 8f33b006ec9d…PIP number unassignedUnassigned. The drafts carry the 9999 placeholder; the upstream repository assigns the number on submission.

Motivating measurement: The consensus-change register: 4 of 5 activated mainnet consensus changes carry no PIP, and the shortest defensible activation notice is 1 h 33 m 56 s at PCCR-0007. The register was built because the record of what Pearl’s consensus rules are lives in release diffs. Most activated mainnet changes are documented by no proposal, one testnet fork height was edited after the fact to legalize blocks that violated it, and the notice available to node and pool operators has been as short as the shortest measured window below.
What it does: It sorts consensus changes into two lanes. A planned change carries a Standards Track PIP before the release that schedules it, and a minimum activation notice measured in blocks. A change that mitigates a defect putting the network at risk takes an expedited lane instead: a much shorter notice floor, an advisory published with the release, a scope limited to the mitigation, and a retroactive PIP within a bounded period. Both lanes feed a register with one entry per consensus change ever activated on mainnet, backfilled to genesis.
What it lets anyone verify: Nothing cryptographic. It changes what a reader can find out without diffing releases: which rules were in force at which height, when they changed, and which document proposed the change. That is the invariant an independent validator, an exchange listing review and a miner planning capacity all need, and none of them can currently get from documents.
What changes, and for whom: A protocol author gains a documentation obligation and a named fast path for urgent fixes, priced in disclosure rather than delay. A pool or miner gains a floor on the time available to rebuild, in both lanes. An independent index gains a canonical register to check against instead of maintaining its own.
What this draft does not claim: The record it cites is neutral and dated, and the draft states in its own words that none of it is a claim of bad faith. It names no party, it asks for no retroactive correction of any shipped change, and the notice minimum it proposes is a proposal rather than a measurement: it is sized from observed adaptation behaviour and drawn as a reference line, never as an observed window.

P6c · Release, document, notice, activation

The proposed minimum is the full width of the axis below: 3,600 blocks (8.1 days at the 194-second block target). The measured windows are drawn against it at the same scale.

01A document exists before the release that schedules the change
A Standards Track PIP at Draft status or later, stating the fork class, the activation height and network, the exact validation rules that change, and what a node that has not upgraded does across activation. Draft status is enough: the requirement is that the document exists, not that it is finished.
02The activation height lies a minimum distance after that release
3,600 blocks (8.1 days at the 194-second block target). The rule constrains when an activation height may fall, not when code may ship, and an emergency change is exempt from it in exchange for a retroactive document within a bounded period.
03The register records what activated, at what height, under which document
One entry per consensus change activated on mainnet, backfilled to genesis, with the heights on other networks recorded inside the entry rather than as separate rows so the entry count and the mainnet change count stay equal. Historical entries with no proposal keep the word none.
04The two windows that can be measured are the sizing evidence
The minimum is a proposal, not an observation, and it is sized against measured adaptation behaviour and against the two activation notices that have a defensible interval. It is drawn as a reference line for that reason, and no measured window is ever drawn at the minimum’s scale as though it were one.

P5 · Every activated consensus change, and the notice it carried

Unit: activated mainnet consensus change, one per register entry. Denominator: 5 counted entries, of which 2 carry a defensible notice window and the rest carry a documented reason instead.

Exploratory (post-hoc)

Activation height

genesis baselinePCCR-0002PCCR-0003PCCR-0005PCCR-0007

h0 (genesis)h99,000 (last activation in the record; live tip unavailable)

The square at genesis is the launch rule set. It is a baseline rather than a change, it wears the reserved neutral for exactly that reason, and it sits outside every count on this page. PCCR-0004 is counted and is not on this axis: it is release-gated, so the rule changes when a node upgrades and there is no activation block to place.

Activation notice

Full width is the proposed minimum: 3,600 blocks (8.1 days at the 194-second block target)

PCCR-0002MoE hard fork (V2 certificates)Hard forkPIP-2, Finalh71,935
No notice window is stated. No scheduling release exists in the public tag record to measure from. Search space: the repository's complete tag list on 2026-08-12, 13 tags, of which 8 are node tags (v1.1.5 through v1.4.1) and 5 are wallet tags. This is an absence within that search space and not a claim that no release existed.
PCCR-0003Dense-only softfork (MoE retracted)Softforkno PIPh91,630
No notice window is stated. Two releases scheduled this fork at two heights, and the first has no release object, so the record supports two defensible endpoints and no single one. Both intervals are carried as non-headline candidates; neither is a notice window this dataset states. Measurable intervals in the record, carried as non-headline candidates and never drawn: Release carrying the height that activated (v1.2.1), 0 h 52 m 10 s; First release to schedule the change (v1.2.0), 2 h 44 m 12 s.
PCCR-0004IsMoE semantic fixConsensus-adjacent semantic changeno PIP
No notice window is stated. Release-gated rather than height-gated: the rule changes when a node upgrades, so there is no activation block and no interval to measure.
PCCR-0005Rank-penalty softforkSoftforkno PIPh96,251
12 h 14 m 35 s (about 12h15m). From the v1.3.0 release publication, 2026-08-05T15:45:09Z (3P), to the timestamp of block 96,251, 2026-08-06T03:59:44Z (LIVE). One release, one height, both endpoints public.
PCCR-0007Salted noise-seed hard fork (V3 certificates)Hard forkno PIPh99,000
1 h 33 m 56 s (about 1h34m). From the v1.4.1 release publication, 2026-08-11T10:29:47Z (3P), to the timestamp of block 99,000, 2026-08-11T12:03:43Z (LIVE). The basis is the release carrying the height that actually activated; v1.4.0 scheduled a different height and produced no release event to measure from.

Proposed minimum activation notice: 3,600 blocks (8.1 days at the 194-second block target). A proposal, not a measurement. It is the standard lane's floor; the draft's expedited lane carries a separate and much shorter floor that this reference line does not represent. The seconds and days equivalents are computed by the generator from these two numbers and are never typed here. The block target is the genesis TargetTimePerBlock of 3m14s recorded in PCCR-0001. Revised 2026-08-15 from 4,320 blocks when the draft moved to two lanes.

These are neutral, dated facts about public artifacts. None of this is a claim of bad faith. The closing sentence is the process draft’s own, checked verbatim against it by the generator that built this payload (docs/research/outreach/pip-draft-consensus-change-process.md, Motivation).

One marker per activated mainnet consensus change on the register’s counting rule, positioned by activation height. A notice-window bar is drawn only where one interval is defensible from public artifacts; where the record supports two endpoints or none, the change is drawn with its reason instead of a bar, and no bar is ever estimated. The proposed minimum is a reference line from the process draft, not an observation, and the fork class is a label rather than a hue because a hard fork and a softfork are the same kind of event on this axis. Data tier: dated record, append-only. Complete through h99,000 (2026-08-11), the last activated mainnet consensus change in the register when this dataset was compiled on 2026-08-12. A later activation adds a row; it never edits one.

What this would let anyone check, and what it still would not

What this proves

proven

That a consensus change has a document stating its fork class, its activation height and network, the exact validation rules it changed, and what non-upgraded nodes do across activation.
That the activation height of a planned change lies at least the proposed minimum after the release that first ships it.
That every mainnet consensus change ever activated appears in one register, backfilled to genesis, including the ones no PIP documents.

What this does not prove

not proven

Nothing about any block, any operator or any workload: this draft is about documents and dates, and it reads no chain data beyond activation heights and their block timestamps.
Not that any change was wrong, rushed in bad faith, or should be reverted; the register records what activated and when, and the draft asks that it be written down.
Not that a longer notice window would have prevented any particular incident; the minimum is sized from observed adaptation behaviour and is a proposal.
Not that the notice windows it cites are complete: two of the counted changes have a defensible interval and the rest carry a documented reason why no interval exists.

Read the draft →

The worked example: PCCR-0007, Salted noise-seed hard fork (V3 certificates)

The most recent activated change is the worked example, because every element the draft asks for can be checked against it: a fork class, an activation height, the release that carried that height, the interval between the two, and the document that proposed it.

Activation: h99,000, 2026-08-11
Fork class: Hard fork
Governing PIP: none
Shipped in: v1.4.1
Notice window: 1 h 33 m 56 s
From the v1.4.1 release publication, 2026-08-11T10:29:47Z (3P), to the timestamp of block 99,000, 2026-08-11T12:03:43Z (LIVE). The basis is the release carrying the height that actually activated; v1.4.0 scheduled a different height and produced no release event to measure from.
What the record carries: The upgrade guide shipped in this release states that mining software deriving seeds the old way produces invalid shares from the fork height on, so the notice window was also the window in which mining software had to be rebuilt. That is the operational difference from PCCR-0002, where unchanged miners kept producing valid work.
Three mainnet heights appear in the public record for this fork: 98,830 in the pull request body as opened, 98,900 in v1.4.0, and 99,000 in v1.4.1. The sequence is a dated fact from the public body-edit history and lives in the register entry.
Block 98,900 was mined carrying a V2 certificate after v1.4.1 was published, so the replacement height shipped before the height it replaced was reached.
Evidence: node/chaincfg/params.go:371 @ v1.4.1 · Mainnet SaltedSeedForkHeight 99000. (SRC)
node/wire/certificate.go:84 @ v1.4.1 · CertificateVersionV3 = 3. (SRC)
node/blockchain/validate.go:539-543 @ v1.4.1 · Strict cutover: a block's certificate version must equal the version required at its height. (SRC)

Every field above is one entry of the append-only record, cross-checked against the register by the generator that built this page’s payload. Data tier: dated record, append-only. Complete through h99,000 (2026-08-11), the last activated mainnet consensus change in the register when this dataset was compiled on 2026-08-12. A later activation adds a row; it never edits one. Read the register.

A proposal that does not state its own adoption problem is advocacy. The weight-identity draft states it in its own Motivation, and the baseline beside it is the draft’s own simulation over the chain’s history, which is small.

“The field is optional because honesty about adoption is warranted: attestation has no buyer among pools today, and this PIP deliberately costs non-attesters nothing.”

Quoted verbatim from Weight-identity commitments for PoUW certificates, Motivation. docs/research/outreach/pip-draft-weight-identity.md, commit 937831d81e82, sha256 29eaf1d2d0a0…. The sentence is the draft’s own admission about its own prospects, quoted rather than paraphrased because paraphrasing it would soften it.

Could have carried a truthful identifier

1,110of 96,406 blocks

1.15% of the classification corpus, heights 0 to h96,405. The matched blocks are exactly the blocks a truthful public identifier could have named, because the identifier is a function of the bytes those blocks committed.

Unit of analysis: blocks, resolving to far fewer coinbase addresses and fewer operators still. Block counts are not independent observations.

Over the most recent span of that corpus

4of 41,433 blocks

Quoted from the draft: “over the most recent 41,433 blocks of that span the rate is 4 of 41,433, three stragglers plus h68,332.”

Quoted, not computed here: the committed payload bins heights at boundaries that do not fall at the start of that span, so this count exists in the draft and is not recomputable from the figures on this page. The digest that pins the sentence is on the quotation above.

The other denominator

53,718candidate blocks

53,718 candidate blocks: 53,717 recorded by the scan as shape-eligible, heights 1 to the frozen tip h96,774, plus 1 added by the coverage-closure round.

Two populations, and a share over one is not a share over the other. The classification span is every canonical block over its heights; the scanned candidate population is the shape-eligible subset that was hashed. The blocks that could have carried a truthful identifier are the matched blocks, which is why the numerator is the same on both and the denominators are not.

The historical baseline the weight-identity draft states about itself, over two different populations that must not be confused: the classification corpus is every canonical block over its span, and the scanned candidate population is the subset that was shape-eligible and hashed. Both denominators are printed because a share over one of them is not a share over the other.

Cite and reuse

Everything on this page is reusable under the licences the source repository carries, and every artifact behind it is pinned. The drafts are rendered from the commit shown; the datasets are archived under a concept DOI that always resolves to the current version.

The archived measurement

doi:10.5281/zenodo.21863620 (external link)concept DOI; it always resolves to the current version of the deposit

The records the drafts read

Consensus-change register docs/registry/PCCR.md (external link)
commit 7f9d428c396e · sha256 ee9925080d7b8644…
OBS-005: Attested model-weight mining on Pearl: the weight-provenance scan docs/research/OBS-005-weight-provenance-scan.md (external link)
commit 7f9d428c396e · sha256 2ebad1bd26c68cb7…

The three drafts

Weight-identity commitments for PoUW certificates docs/research/outreach/pip-draft-weight-identity.md (external link)
commit 937831d81e82 · sha256 29eaf1d2d0a09d3d…
Weight-provenance disclosure and verification docs/research/outreach/pip-draft-provenance-disclosure.md (external link)
commit 937831d81e82 · sha256 76201540e9fa4ac1…
Consensus-change documentation and activation notice docs/research/outreach/pip-draft-consensus-change-process.md (external link)
commit 937831d81e82 · sha256 8f33b006ec9d07e4…

A submitted draft is not an accepted standard. Cite these as drafts published by an independent party and submitted upstream on 2026-08-15, with the commit and digest shown, and cite the measurement they rest on as the deposited record rather than as this page.

The drafts themselves

The three documents themselves, rendered unedited from the source repository at the commit shown on each page. Everything above is an argument about them; these are the texts, and where the two differ the document is what stands.

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.
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.
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.