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.

Abstract

A Pearl PoUW certificate commits to its weight operand as hash_b = blake3(B, key=job_key), with both hash_b and the job_key preimage recoverable from raw block bytes. When B is a tensor of a published checkpoint, anyone can therefore verify, from public data alone, that a given block's committed operand is that tensor: recompute the keyed hash of the candidate bytes and compare. This PIP standardizes the two halves of that exchange: a disclosure document in which a miner (or any third party) asserts "blocks S committed tensors T of published model M at revision R", signed with the coinbase payout key of the claimed blocks, and a verification procedure that grades each assertion match, no-match, or not-checkable. An optional on-chain anchor commits the disclosure hash via a standard OP_RETURN output spent from the same payout key. No consensus change is required; everything specified here works on today's network and on every historical block since genesis. A companion Consensus PIP proposes a certificate field that makes the same identity claim at mining time; this document is the deployable-today half and the verification substrate both share.

Motivation

Pearl's certificate proves operand commitment strength that nothing in the ecosystem consumes. The verification primitive is public and cheap (one keyed BLAKE3 of the candidate tensor per block; 0.12 seconds single-threaded for the largest 0.47 GB tensor family of the flagship 70B checkpoint), and it has been exercised at corpus scale: a retroactive scan of every shape-eligible block since genesis, followed by a registered coverage-closure round over the cells that scan had left out, identified 1,110 blocks committing byte-exactly to published checkpoint tensors, with 0 matches in 2,130,000 negative-control pairs (2,130 distinct buffers against one reused 1,000-block control, not 2.13 million independent trials), each published match independently reproducible from raw block bytes (DOI 10.5281/zenodo.21863620, which always resolves to the current version; the 1,110th block and the closure round are recorded in the OBS-005 errata block dated 2026-08-11, carried by version 2 of the deposit, 10.5281/zenodo.21884840). What is missing is a standard container for the claim itself: today a verifier must guess which tensor a block might have committed, and a miner who wants credit for real-model mining has no recognized way to say so. The published measurement study of Pearl lists operand provenance as unsolved future work requiring an external PKI (arXiv:2606.04819, checked 2026-08-08; the only such study this project's survey of 2026-08-10 found, which bounds that survey and is not offered as proof that no other exists). No external PKI is needed: the coinbase payout key of the claimed blocks is already on chain, and a signature under it binds the claim to the party the network already pays.

Pearl's own roadmap points the same way. The whitepaper's planned-upgrades section describes a future scheme that works while "forcing the miner to commit to the underlying (pre-quantization) weight and activation matrices", and the same document envisions "native (on-chain) settlement of compute contracts: the chain can verify that a certain amount of computation happened on account of Alice asking Bob, and settle the payment" (Pearl whitepaper, Planned Upgrades and the opening section's future-work discussion; quoted 2026-08-15). Both need a way to state which weights a block committed and to have that statement checked by a third party. This standard supplies one with no protocol change, and it works on every block already mined.

Specification

Terms

The party publishing a claim is the discloser; the party checking it is the verifier; one (block, tensor) pair inside a claim is an assertion.

The disclosure document

A disclosure is one self-contained JSON document:

{
  "weightProvenance": "v1",
  "claim": {
    "statement": "weight-provenance disclosure v1",
    "model": {
      "repo": "<checkpoint repository>",
      "revision": "<pinned commit sha of the checkpoint repository>"
    },
    "recipe": "<name of the buffer-construction convention, see below>",
    "tensors": [
      {
        "id": "<family>.tp<N>.s<shard>.L<layer>",
        "bytes": <buffer length>,
        "sha256": "<64-hex sha256 of the constructed buffer>"
      }
    ],
    "assertions": [
      { "height": <block height>, "blockHash": "<64-hex>", "tensor": "<tensors[].id>" }
    ]
  },
  "signingScheme": "BIP-340",
  "messageDigest": "<64-hex sha256 of the claim member bytes>",
  "pubkey": "<64-hex x-only coinbase payout key of the claimed blocks>",
  "signature": "<128-hex BIP-340 signature over messageDigest>"
}

Rules:

model.revision MUST pin the exact checkpoint commit; a claim without it is malformed.
recipe MUST name a published buffer-construction convention that fixes byte order, fusion order, tensor-parallel sharding axes, and dtype handling. The reference convention for the current INT7 protocol is: buffer bytes are the row-major contiguous int8 tensor at the pinned revision, fused layers concatenated in serving order (q|k|v, gate|up), column-parallel families sharded on the output dimension (each sub-projection sharded separately, shard r holding the concatenation of the r-th contiguous slice of every sub-projection, never a slice of the already-fused tensor), the row-parallel family sharded on the contraction dimension by contiguous split, raw and unpadded.
One block carries exactly one hash_b, so at most one assertion per height.
The signed message is the exact bytes of the claim member's value, from its opening brace to its closing brace inclusive; messageDigest is its lowercase-hex sha256; signature is BIP-340 over the digest. A verifier MUST slice the claim bytes out of the document rather than re-serialize.
Every claimed block's coinbase MUST pay the key in pubkey for the document to constitute a miner disclosure. A document with a missing or invalid signature MAY still be verified; it is then an anonymous claim, and a verifier MUST report signature validity separately from assertion truth.

Verification procedure

For each assertion:

Fetch the raw block for height; split certificate and header; assert SHA256d(header) == blockHash. The block bytes are self-proving; the data source is untrusted. The certificate is framed version-first, so the public data begins at a version-dependent 1-based byte offset into the raw certificate:

cert version	public data begins at	preceding fields
1	byte 37	version (4) + block hash (32)
2	byte 41	version (4) + block hash (32) + public-data length (4)
3	byte 41	identical layout to version 2

Version 3 embeds version 2 by value and changes the noise-seed derivation and the version value that enters ProofCommitment, neither of which moves a public-data offset, so a version 2 reader that accepts the version value reads version 3 unchanged (verified against the node wire package at v1.4.1: node/wire/certificate.go for the version-first framing, certificate_v1.go and certificate_v2.go for the two field layouts, certificate_v3.go for the embedding and its ProofCommitment override; the reference scanner named under Reference Implementation applies byte 41 to certificate versions 2 and 3 and byte 37 to version 1).

Read the certificate public data: hash_b = public_data[84:116], declared dims k = public_data[0:4], n = public_data[152:156].
Shape precondition: the block's declared (n, k) MUST equal the claimed tensor's sharded dims; on mismatch the assertion fails without hashing.
Derive job_key = blake3(header_bytes[0:76] || public_data[0:52]), unkeyed.
Construct the buffer for the claimed tensor at the pinned revision per recipe; compare its sha256 to tensors[].sha256. A mismatch here is an extraction dispute, reported as such, never a chain verdict.
Compute blake3(buffer_bytes, key=job_key) and compare all 32 bytes to hash_b.

Verdicts, exactly one per assertion: match (step 6 equality), no-match (step 3 or 6 fails; refutes only the named tensor, revision, and layout), not-checkable (weights not public, dtype outside the recipe, layout not implemented, or revision no longer retrievable).

A verifier publishing aggregate results SHOULD state counts per verdict with the population's composition, and MUST NOT present a no-match or an aggregate zero as proof that no useful work occurred; a zero is bounded by the exact search space (models, revisions, families, layouts, block population) and MUST ship with it.

What a match attests

A consensus-accepted block whose hash_b equals the keyed root of a published tensor attests that the sampled output entries verified by consensus were computed from strips of that tensor after a publicly derivable rank-r perturbation. It attests the weight operand only. A verifier or discloser MUST NOT describe a verified assertion as proof that inference ran, that the declared m x n x k arithmetic ran in full, that any customer was served, or as any claim about the activation operand. The recommended label is "attested model-weight mining".

Optional on-chain anchor

A discloser MAY anchor a disclosure by broadcasting a transaction with one output of the form:

OP_RETURN "PWA1" || sha256(document_bytes)        (36 bytes of data)

where at least one input of the anchoring transaction is controlled by the document's pubkey. The spend authenticates the anchor with no additional signature scheme; the anchor timestamps the claim and makes it discoverable by chain scan. An anchor asserts nothing by itself; the document still verifies or fails on its own.

Rationale

Disclosure-first, consensus-second: this standard needs no fork, works retroactively on all historical blocks, and establishes the claim format, the recipe discipline, and the verification semantics that the companion Consensus PIP's certificate field then compresses into 28 bytes at mining time. If the consensus field activates, disclosures remain the carrier for revision pinning and multi-block claims, and the field supplies the per-block candidate that makes step 5 a table lookup.

The verdict semantics are deliberately per-assertion. Each assertion resolves to match, no-match or not-checkable, and the Specification forbids presenting a no-match or an aggregate zero as proof that no useful work occurred, because a zero is bounded by the exact search space it ran over and ships with it. That rule exists to foreclose one specific reading. That measurement study reports that "the verification protocol accepts random matrices by design" and concludes that the network "produces zero useful AI computation" (arXiv:2606.04819, checked 2026-08-08), which is a negative stated over a property the protocol concedes: the whitepaper says Pearl "attracts compute that does not necessarily have useful work" (Pearl whitepaper, "Towards a marketplace of useful compute"; quoted 2026-08-15). An aggregate produced under this standard cannot be read that way. It counts assertions about named tensors at pinned revisions under a named recipe over a stated block population, so a zero means "not these exact bytes, in this space", and a match is a positive identification of the committed operand. The claim class is identification. This standard binds the discloser and the verifier to report it that way; what a third party writes about a published aggregate is outside its reach.

The coinbase payout key as the signing identity avoids inventing a PKI and binds the claim to the entity the protocol already pays. Its limits are stated rather than papered over: a payout key may belong to a pool or custodian, so the signature proves key control and endorsement, never physical operation, and it contributes nothing to assertion truth.

Precedent elsewhere: model-distribution ecosystems already treat a pinned repository revision plus per-file digests as the working notion of model identity, and artifact-signing efforts standardize signed manifests of content hashes. This PIP applies the same idea where Pearl is unusual: the chain already holds a binding commitment to the exact bytes, so a disclosure needs no trusted registry at all, only a pointer to public bytes and a recomputation. The corpus scan is why model.revision is mandatory rather than advisory: it found blocks committing to the reference artifacts at their pinned revisions and none committing to the searched public third-party int8 quantizations of the same architectures (0 matches in 329,824 pairs over a 2,216-block residue), so a disclosure names an artifact at a revision, never a model family.

Precedent on Pearl itself: voluntary coinbase data is established practice. A census of the coinbase scriptSig of every block at heights 0 to 97,000 (97,001 blocks, 0 parse errors; unit: blocks, one coinbase each) finds the stock node template string on 83,431 of them, 86.01%, and two pool self-labels on a further 5,118 (5.28%) and 3,161 (3.26%), each of those two tag families carried only on blocks paying a single payout address. Inscription-style witness envelopes are already proven on this chain at scale. The anchor profile above asks miners to do nothing they do not already do; it only standardizes the payload.

Backwards Compatibility

No consensus change. The document format, verification procedure, and anchor use existing transaction standardness. Historical blocks since genesis are claimable and verifiable.

Security Considerations

Claim authenticity and claim truth are independent axes: the signature binds a claim to a key; only recomputation establishes truth. A false assertion about a public checkpoint is provably false to any verifier (step 6 mismatch), which makes false disclosure self-defeating. A discloser can only claim blocks whose payout key it controls, so third parties cannot forge miner disclosures; they can publish anonymous claims, which verifiers evaluate identically but label as such. Signature keys are on-chain Taproot output keys; key reuse across disclosures links them, which is inherent to the design and stated here.

Privacy Considerations

Disclosure is voluntary and self-attributing: the only identity in a document is the discloser's own key. Nothing in this standard names, scores, or ranks any non-disclosing party. Verifiers publishing aggregates report populations, never operator identities.

Reference Implementation

A corpus-scale scanner, a single-assertion verifier that trusts no scanner code (raw block bytes from any Blockbook-compatible source, offsets parsed by independent arithmetic, one pip-installable hash library), and the reference buffer-construction implementation are published with the dataset (DOI 10.5281/zenodo.21863620). A second, independent implementation of the buffer-construction recipe, written from the specification text alone, exists and reproduces the reference buffers byte-exactly (six buffers spanning every match-confirmed family). A second independent implementation of the remaining verifier steps (block parsing, key derivation, keyed comparison) from this text alone completes the promotion requirement before Proposed.

Test Vectors

A complete real assertion, re-verified against raw chain bytes on 2026-08-10 (verifier exit 0):

height     = 22,816
blockHash  = e38b23b96811531c0cbf515befe9c0e47d716a436c82612e7f431407e4b6d7f0
declared   = m 16,384  n 57,344  k 8,192  rank 128  (certificate v1)
job_key    = cf0e01e50ca831efbdeca8cd2148cfacd9dcb3aedb1e355f53a5e7c8aab9ddb8
model.repo     = pearl-ai/Llama-3.3-70B-Instruct-pearl
model.revision = 6cc401caab46ffa688dea3553b2f55d3dfc1d0aa
tensor     = gate_up_fused.tp1.s0.L000   (n 57,344 x k 8,192; 469,762,048 bytes)
buffer sha256 = efe46a96b9f1813c73cacbb536c3f5d542cddde50ea3068dfbe59f99ff947eec
on-chain hash_b                  = 146977c823a20079335e54876e858a0607441249e64ce13a09151dca9e7b124d
blake3(buffer, key=job_key)      = 146977c823a20079335e54876e858a0607441249e64ce13a09151dca9e7b124d
verdict    = match

Anyone can reproduce this from a Blockbook raw-block endpoint and the public checkpoint; no artifact of the dataset is required.

References

Companion draft: weight-identity commitments for PoUW certificates (the consensus field; assigned number pending).
PIP-2: Grouped-GEMM Proof-of-Useful-Work for Mixture-of-Experts (certificate structure precedent).
Weight-provenance scan dataset and method, DOI 10.5281/zenodo.21863620 (current version 10.5281/zenodo.21884840).
BIP-340 (Schnorr signatures for secp256k1).
arXiv:2606.04819, the published measurement study of Pearl (provenance listed as unsolved future work; checked 2026-08-08).
Pearl whitepaper (pearlresearch.ai/research/whitepaper): the planned-upgrades commitment to pre-quantization weight and activation matrices, the opening section's on-chain settlement of compute contracts, and the marketplace motivation's statement about compute that does not necessarily have useful work (all quoted 2026-08-15).
pearl-research-labs/pearl v1.4.1, node/wire/certificate.go, certificate_v1.go, certificate_v2.go and certificate_v3.go (the version-first certificate framing and the per-version public-data offsets in step 1).
OpenSSF Model Signing specification, the file-manifest analogue of this document for off-chain model distribution (github.com/ossf/model-signing-spec, accessed 2026-08-10).
Bittensor pretraining subnet, on-chain model commitments as repository, revision, and submitter-bound content hash (github.com/macrocosm-os/pretraining, accessed 2026-08-10).