Abstract

Every Pearl PoUW certificate commits to its weight operand twice over: hash_b is a keyed Merkle root over the operand bytes, the key (job_key) is derived from the block header and the mining configuration, and both values are committed into the block identifier. Because job_key is per block, identical weights hash to different values in every block, so an observer cannot verify a commitment without guessing the full operand and recomputing the keyed root, once per block; recognizing a model, detecting weight reuse, and auditing a claim all reduce to that guess. In practice only public, static checkpoints are checkable, at a cost of one full-tensor hash per candidate pair.

This PIP assigns the 28 reserved must-be-zero bytes of the mining configuration (public data offsets 24:52) to an optional weight-identity field: one scheme byte and a 27-byte truncated BLAKE3 identifier of the pristine weight operand, either a plain content identifier (public checkpoints, verifiable by anyone from a precomputed table plus one keyed hash) or a salted identifier (private weights, a stable pseudonym that proves nothing to outsiders and everything to a counterparty who holds the salt). An all-zero region keeps today's exact semantics, so miners that do nothing are unaffected. Because the region already sits inside the job_key preimage, an attestation is bound before mining starts and cannot be added, altered, or removed after the fact without redoing the block's work. Relaxing the must-be-zero rule is a consensus change, so it rides the next certificate version (version 4 or later); versions 1, 2 and 3 are already assigned.

Motivation

The whitepaper says the network "attracts compute that does not necessarily have useful work" (Pearl whitepaper, "Towards a marketplace of useful compute"; quoted 2026-08-15). The certificate format already records everything needed to identify which weights were multiplied; what is missing is a place to record it legibly. This PIP adds the field that lets a miner who is running a real model say so, and leaves every other miner exactly where it is today. The figures below are computed from a public, independently reproducible dataset of every certificate since genesis (DOI 10.5281/zenodo.21863620, which always resolves to the current version; verification method and residual caveats in the deposited OBS-005). The corrections dated 2026-08-11 in OBS-005 §10, and the coverage-closure and control-redraw datasets they rest on, ship in version 2 of the deposit (10.5281/zenodo.21884840); the figures below are on the corrected basis.

1. Verifiable weight-backed mining existed and was abandoned inside the chain's first six weeks. A retroactive scan of 53,717 candidate blocks against the published checkpoint tensors, plus a registered coverage-closure round over 382 further blocks, found 1,110 blocks whose hash_b equals, byte-exactly, a published tensor of Llama-3.3-70B, Llama-3.1-8B, or Gemma-4-31B: 1,109 in the frozen DS-002 and DS-002b runs and one more, h68,332, in DS-006. The negative control returned 0 matches in 2,130,000 pairs across the three runs, which is 2,130 distinct buffers against one reused 1,000-block control rather than 2.13 million independent trials; every published match is independently reproducible from raw block bytes. Those 1,110 blocks resolve to 49 distinct coinbase payout addresses (unit: addresses over the 1,110 matched blocks), effective addresses 4.60 as 1/HHI. The last of them is h68,332 (2026-06-05), 39 days after genesis and now in a committed dataset rather than only a dated erratum; no block after it matches any tensor in the searched space.

2. Declared geometry is decoupled from committed bytes. The largest single cell of the certificate census is m 32,768 x n 57,344 x k 8,192 at rank 128 and tile 2 x 64, which is exactly the fused gate/up projection of the flagship published 70B checkpoint: 15,902 of 96,406 (unit: blocks; DS-001, the frozen classification corpus, heights 0 to 96,405). The unit matters: that count is one cell of the (m, n, k, rank, tile) census, not every block declaring the (m, n, k) triple, and 31,831 scanned candidate blocks (DS-002 basis) declare the triple. The 50,049 scanned blocks with constant m = 32,768 are three declared shapes from two checkpoints, all at tp1: (n 57,344, k 8,192) x 31,831, the 70B gate/up shape; (n 28,672, k 4,096) x 16,530, the 8B gate/up shape; and (n 10,240, k 8,192) x 1,688, the 70B qkv shape. Zero of the 50,049 committed the published bytes. Shape-based usefulness metrics, including every explorer's, measure declarations, and declarations are free.

3. The certificate binds the operand commitment in full and samples the arithmetic by design. Sampling is what keeps verification cheap: the consensus proof authenticates at most a few hundred sampled output entries per block, which puts the corpus-wide MAC-weighted proven-to-declared ratio at about 8.3e-9 (unit: proven MACs per declared MAC, aggregated over the 96,406 blocks of the frozen classification corpus DS-001, heights 0 to 96,405). The operand commitment is the part that is bound in full, and it is the part this proposal spends. No new proof obligation is added.

4. Configuration carries no workload information. Over the window opened by the rank-penalty softfork, heights 96,251 to 98,089 (1,839 blocks; unit: blocks, corpus snapshot of 2026-08-10), 39.6% of blocks (729 of 1,839) declare exactly the legal-minimum configuration (rank 128, k 2,048), and per-pool configuration profiles separate by mining software, spanning 10.0% to 95.1% at the minimum across labeled pools (unit: each pool's share of its own blocks in that window, by coinbase-tag attribution; the unattributed remainder is its own population, is never redistributed, and is outside this range). That window closes before the salted noise-seed hard fork at height 99,000; the live index extends past it, but no frozen dataset does yet, so no post-99,000 configuration basis is quoted here. Observers cannot infer anything about useful work from any declared field. An explicit attestation field is the only remaining place such information can live.

5. The network's own roadmap already proposes a weight commitment. The whitepaper's planned-upgrades section describes a future floating-point scheme that works while "forcing the miner to commit to the underlying (pre-quantization) weight and activation matrices" (Pearl whitepaper, Planned Upgrades; quoted 2026-08-15). That is the binding half of the problem, and it is already Pearl's stated direction. This PIP supplies the legibility half: 28 bytes that name which weights the block committed, checkable by anyone against a published artifact. The unshipped floating-point proposal (PIP-3) targets real serving workloads on whitelisted hardware, and the ecosystem's stated direction is commercial inference on private or customer models. Under the current format none of that activity can be attested, even voluntarily: private weights are indistinguishable from synthetic noise, and public weights are checkable only by brute recomputation. A format revision is already on the table; this is the moment to add the one field that makes useful work legible.

Honesty about the historical baseline is owed here. Simulated over the chain's own history, scheme 0x01 could have carried a truthful public identifier on 1,110 of the 96,406 blocks at heights 0 to 96,405 (1.15%, unit: blocks), all inside the first six weeks and produced by roughly five effective (address, day) units; over the most recent 41,433 blocks of that span the rate is 4 of 41,433, three stragglers plus h68,332.

That baseline is not an artifact of partial scanning. A follow-up registered and frozen before execution (PREREG-003, committed as DS-006 and DS-007) closed every remaining cell the original search space implies, 31 enumerated cells of which 28 hold no corpus block at all; refuted the column-major byte-order alternative for the unmatched o-family residue against a positive control that matched 20 of 20 under the standard convention and 0 of 1,680 under the variant (0 of 13,200 population pairs); refuted both registered gate_up tp2 fusion-order variants (0 of 304,800 pairs each, same positive-control design); redrew the negative control era-stratified over 952 blocks and seven buffer sets, with 0 matches in 2,372,384 pairs; and found no block committed to a public third-party int8 quantization of these architectures (0 matches in 329,824 residual pairs, at pinned revisions). This PIP is therefore forward-looking by construction: it is the legibility layer for the workloads PIP-3 aims to attract, and for the official miner, and it claims no retroactive demand.

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. Its near-term consumers are the official miner (which can attest by default, since it multiplies exactly the published tensors), explorers and researchers (who can then verify a block against one named candidate instead of scanning hundreds), and any compute provider that wants to prove model consistency to a customer.

Specification

Reserved region layout

The 28-byte region at mining-configuration offsets 24:52 (public data offsets 24:52; the region is currently required to be zero at deserialization) is redefined as:

attest_scheme (1 byte, offset 24) || attest_payload (27 bytes, offsets 25:52)

Scheme values:

0x00  UNATTESTED   payload MUST be all zeros (bit-identical to today)
0x01  WEIGHT_ID    payload = WID_public(B)
0x02  WEIGHT_ID_S  payload = WID_salted(salt, B)
0x03..0xff         reserved for future PIPs

Validation rules (consensus):

• A verifier MUST reject a certificate with attest_scheme = 0x00 and a nonzero attest_payload.
• A verifier MUST accept any payload value under schemes 0x01 and 0x02. The payload's truth is not a validity condition; see Security Considerations.
• A verifier MUST accept unknown scheme values 0x03..0xff with any payload. Future PIPs MAY constrain them.

All other certificate validation is unchanged. The wire size is unchanged. The region remains part of the mining_config bytes hashed into job_key and committed through ProofCommitment into the block identifier, exactly as the zero bytes are today.

The weight-identity functions

Let B be the exact byte string whose keyed BLAKE3 Merkle root the certificate commits as hash_b, in the same serialization the commitment hashes (for certificate versions 1, 2 and 3: the pristine pre-noise int8 operand in native row-major layout, raw and unpadded; version 3 carries version 2's operand encoding unchanged). Defining the identifier over the same bytes as the commitment makes the pair (hash_b, weight_id) refer to one object with no additional encoding convention.

WID_public(B)       = BLAKE3-derive_key("pearl weight-id v1 public", B)[0:27]
WID_salted(salt, B) = BLAKE3-derive_key("pearl weight-id v1 salted", salt || B)[0:27]

derive_key is BLAKE3's standard key-derivation mode with the quoted ASCII context strings; the output is truncated to 27 bytes. salt is a 32-byte value chosen and kept by the miner. A miner using scheme 0x01 MUST compute the payload as WID_public(B). A miner using scheme 0x02 MUST compute it as WID_salted(salt, B) and SHOULD reuse one salt per (model, counterparty) scope where cross-block linkability is the goal.

If a later certificate version changes the operand commitment's input encoding, B under that version is the canonical pre-noise operand encoding it defines, and the context strings above are versioned independently of the certificate version, so identifiers remain comparable across certificate versions whenever the underlying bytes are identical.

Verification

Three procedures, in increasing strength:

1. Structural (consensus, always): the scheme/payload rules above.
2. Public-identity check (anyone, scheme 0x01): maintain a table WID_public(T) -> (repo, revision, tensor) over published checkpoints; on a hit for a block's payload, recompute blake3(T, key=job_key) for that one tensor and compare all 32 bytes to the block's hash_b. A match verifies the attestation. A mismatch proves the attestation false. The expected verification cost is one keyed hash of one tensor per block, replacing today's scan of every candidate tensor per block.
3. Salted check (counterparties, scheme 0x02): a party holding salt and the weights runs the same recomputation. To everyone else the payload is an opaque, stable pseudonym.

What a verified attestation means, and does not mean, follows the existing verification ladder for hash_b matches: consensus proves the sampled output entries were computed from strips of the committed operand after a publicly derivable rank-r perturbation. It attests the weight operand's identity. It never proves that inference was served, that the declared m x n x k arithmetic ran in full, or anything about the activation operand. Implementations and explorers MUST NOT describe a verified attestation as certified inference.

Rationale

Why this slot

The reserved region is the only place in the protocol where a declaration is bound before the work happens. The region sits inside mining_config[0:52], which is the tail of the job_key preimage (job_key = blake3(header_bytes[0:76] || mining_config[0:52])); the noise seeds derive from job_key and the commitments (b_noise_seed = blake3(job_key || hash_b)); the winning tile depends on the noise. Changing the attestation therefore changes job_key, which changes hash_b, the noise, and the transcript: the entire block's work is invalidated. An attestation here is an input to the mining computation itself rather than a label attached to a finished block. Off-chain registries, coinbase tags, and OP_RETURN anchors (all possible today without a fork, and useful as interim measures) lack exactly this property: they can be attached, stripped, or rewritten after mining.

Why it costs nothing

The bytes already exist, are already parsed, already feed job_key, and are already committed to the block identifier. The wire format does not grow by one byte. A miner that ignores the feature emits the same bytes it emits today. Computing WID_public(B) is one unkeyed hash of the operand at model-load time, amortized over every block mined with those weights: measured on commodity hardware, 0.12 seconds single-threaded for the largest 0.47 GB tensor of the flagship 70B checkpoint, a rate of about 3.8 GB/s on one core, so about 24 seconds once for that model's entire 600-buffer, 92.6 GB reference set. The two published checkpoints together are 840 buffers and 102.0 GB, about 27 seconds on the same core.

Verifier-side, the field collapses discovery cost by orders of magnitude. Without it, identifying attested blocks retroactively meant hashing an average of 384 MB across 16 to 160 candidate tensors per block (the executed corpus scan processed 1.47 PB over 25.5 hours). With it, verification is a table lookup plus one keyed hash of one named tensor, about 0.2 seconds per block on one core.

Why no new grinding surface

The header serialization places the merkle root inside the first 76 header bytes and the nonce outside them. Miners therefore already hold unbounded job_key freedom through the coinbase extra-nonce; 28 additional variable bytes in the same preimage add no capability they lack: coinbase freedom (extra-nonce pushes, output ordering, value dust) already contributes far more than the 224 bits this field frees. The anti-grinding property of the protocol (operands committed before noise is knowable) is unchanged, since the region is committed at the same point in the derivation chain as every other configuration field.

Why truncated to 27 bytes

The scheme byte plus payload must fit the 28-byte region without moving any existing offset. 27 bytes is a 216-bit identifier; collision resistance (about 2^108) and preimage resistance (2^216) exceed the security level of everything else in the certificate. Reserving a scheme byte rather than spending all 28 on the digest buys an explicit unattested state, salted identities, and room for future schemes.

The operationally relevant collision question is registry-side: against a table of every published-checkpoint tensor (realistically 10^4 to 10^6 entries), expected 216-bit collisions are negligible beyond argument. The residual failure mode is two registry entries with byte-identical tensors, which is a data question rather than a cryptographic one (the reference buffer set contains zero byte-identical pairs across its 840 tensors), and it is harmless anyway: procedure 2 confirms every hit with a full 32-byte hash_b recomputation, so a truncation or registry collision costs one wasted hash and can never produce a false verified attestation.

Why optional rather than required

Pearl's proof system is built not to reveal its inputs: the whitepaper's privacy section states that "the proof attests only to the correctness and integrity of the computation, without revealing any details of the inputs themselves" (Pearl whitepaper, Privacy; quoted 2026-08-15). The field is opt-in to preserve that default, so a miner that writes 0x00 discloses exactly what it discloses today, and scheme 0x02 lets a miner prove continuity of an unnamed model to a chosen counterparty without disclosing anything to anyone else.

A mandatory field would either force synthetic miners to lie (writing identifiers for weights they do not use, which scheme 0x01 makes provably false and scheme 0x02 makes meaningless) or force disclosure of private-model existence. Neither improves the network. The observed adoption mechanics on this network are that miners comply when share acceptance forces it or when a change cuts costs; a zero-cost optional field with immediate explorer-side display is the strongest proposal consistent with that record.

Why the field is weight-side only

The certificate commits both operands, and only one of them can carry a checkable identity claim. Nothing in the protocol binds hash_a to activations produced by a real forward pass: the activation commitment binds whatever bytes the miner supplied. An identifier over the activation operand would therefore assert nothing an outsider could test against a published artifact. The attestation is one-sided for that reason, and its meaning is bounded to match: a verified attestation proves that a named weight operand was committed, and it never shows that inference ran, that the declared m x n x k arithmetic ran in full, or anything about the activation side. That residual is inherent to this design and is not closed by any scheme value defined here.

Why not full consensus verification of the identifier

Consensus could, in the circuit of whichever certificate version carries this field, authenticate the opened operand strips against a second, unkeyed Merkle root carried in it, making attestation truth a validity condition rather than an externally checkable claim. Because the attestation is committed before the winning tile is known, a cheating miner would need a second tree agreeing with the real operand on every openable strip, which forces byte equality. This PIP does not require that circuit change: it would roughly double in-circuit strip authentication work, it binds the field to one commitment design, and the falsifiability of scheme 0x01 already makes false public attestations self-defeating. The field's layout is chosen so a later PIP can upgrade scheme 0x01 verification from falsifiable to consensus-proved without changing the wire format.

Relationship to PIP-3

PIP-3, the floating-point certificate proposal, replaces the arithmetic (integer to floating point) and keeps the attestation surface empty. It is referred to here without a certificate version number: its draft proposes "V3", and certificate version 3 was taken by the salted noise-seed hard fork activated at mainnet height 99,000 on 2026-08-11, so a floating-point certificate now needs a later number, as does this field. The two proposals are orthogonal and complementary: PIP-3 makes more real workloads mineable, this PIP makes mineable workloads legible. If they activate together, PIP-3's canonical pre-quantization operand encoding (its "medium precision" step) is best defined with this field in mind so B stays well defined under it. The coupling is timing only: this PIP is activation-vehicle-agnostic, changes no arithmetic and no hardware assumption, and inherits none of PIP-3's hardware-whitelist considerations, which remain PIP-3's to analyze.

Related work

Survey conducted 2026-08-10, with one entry added 2026-08-11 (Hawkeye); external claims are as published by the cited projects.

• A 2026 proof-of-useful-work chain (TensorCash) makes model identity mandatory consensus state: an on-chain registry pins approved checkpoints per repository revision, miners post deposits to register models, and verification statistically replays inference against the pinned model. The design contrast is direct: that scheme requires a mandatory external registry plus replay, where this one is an optional per-block identifier verifiable in one keyed hash, with no registry, no deposit and no reward attached.
• Bittensor's pretraining subnet commits models on chain as repository, revision, and a content hash bound to the submitter's key, and its weight-plagiarism history produced a three-part defense: identity-bound hashes, commitment before disclosure, and an incumbency margin. The salted scheme here reproduces the identity-binding half; the competitive parts do not transfer because attestation under this PIP carries no reward.
• Bitcoin's segregated-witness commitment (BIP-141) is an optional commitment carried in existing consensus bytes, required only when witness data is present; Zcash's ZIP-244 block-commitments field is explicitly designed as an extensible chain of commitments with a terminator reserved for future structures. This field composes both patterns: optional, versioned, and carried in bytes that already exist and are already committed.
• Artifact-signing standards for models (OpenSSF model signing over Sigstore) hash serialized files; none fixes a canonical tensor-byte identity, so re-serialized or requantized weights change identity under them. This PIP avoids inventing a serialization by defining the identity over the exact bytes the protocol's own commitment already hashes.
• Activation-fingerprint (TOPLOC), zero-knowledge (zkLLM), optimistic (opML), and sampling-based inference verification all presuppose an external answer to which weights the verifier should load. This field supplies that answer at the consensus layer and composes with any of them as stronger upper tiers.
• Hawkeye (arXiv:2603.20421) is the closest such primitive and the natural complement to this field. It reproduces GPU tensor-core matrix multiplication bit-exactly on a CPU, which lets an auditor replay a computation and detect execution that does not match what was claimed; one of its motivating examples is "a service provider wishing to cut costs by serving a smaller language model", which is the weight-identity question stated as an auditing problem. The replay verifies execution once the verifier knows which weights to load. This field names the weights, at the cost of one keyed hash instead of a replay. Neither subsumes the other: an identifier without replay checks no arithmetic, and a replay without an identifier has nothing to load.
• Within this survey, no prior instance of an optional per-block weight-identity field inside a proof-of-work consensus structure was found. The novelty claim is bounded by that search, and is not offered as proof of absence.

Backwards Compatibility

Current nodes reject any certificate whose reserved trailer bytes are nonzero at deserialization (the check runs in the mining-configuration decoder, before any proof verification, in every certificate version). Activating schemes 0x01/0x02 therefore loosens a validity rule: blocks valid under this PIP are invalid to non-upgraded nodes, a hard fork. Deployment requires a coordinated activation height at the next certificate version (version 4 or later). No historical block is affected: every existing certificate carries the all-zero region, which remains valid and means UNATTESTED. That is measured. An independent decoder that fails loudly on any nonzero trailer byte has parsed every certificate since genesis without one such failure: 100,122 of 100,122 canonical blocks carrying a version 1, 2 or 3 certificate, heights 0 to 100,121, at the index tip of 2026-08-15T14:39:32+02:00 (unit: blocks; this count tracks the live corpus and moves with every block, so it is stated with the height and time it was taken rather than as a standing figure). The population includes 1,122 version 3 certificates, heights 99,000 to that tip; the version boundary was confirmed on chain at the same time, height 98,999 carrying version 2 and height 99,000 version 3. Pools, wallets, transaction relay, and non-PoUW validation are unaffected.

One deployment hazard deserves its own sentence: a pool that vendors today's decoder would reject a share whose reserved region is nonzero, so an attesting miner on a non-upgraded pool loses shares silently. The one-line parser relaxation therefore has to ship in each stack that vendors the decoder before any miner sets the field, which means well ahead of the activation height.

Security Considerations

False attestation. Under scheme 0x01 a false attestation is provably false by one keyed-hash recomputation against the named tensor, from public data alone, by anyone. The proof of falsity is stronger than today's baseline, where a miner's implicit shape declaration cannot be audited at all without scanning every candidate tensor. Under scheme 0x02 no third party can evaluate the claim; the payload asserts nothing publicly and therefore cannot deceive publicly.

Mimicry. A miner cannot claim another party's public model while mining different bytes without being caught by procedure 2, and cannot produce a valid attestation for weights it does not possess, since the identifier is a function of the full operand bytes it must also commit under hash_b and open strips of in the proof.

Grinding. See Rationale: the coinbase extra-nonce already varies the job_key preimage without bound; this field adds no new grinding capability. The derivation order (attestation committed before noise is derivable) is preserved.

Confirmation attacks on salted identities. A salted identifier is deterministic in (salt, B). If both later leak, every block mined under that salt becomes retroactively attributable to those weights. For auditability this is a feature; operators for whom it is a risk should rotate salts per scope or mine unattested. Miner software that exposes scheme 0x02 owes its users documentation of this tradeoff; the normative requirement lives in the Specification.

Denial of service. None identified: the field is fixed-size, parsed today, and validation adds two byte comparisons. No zero-knowledge circuit input changes: the proof statement, its public inputs, and the recursion are untouched, since the region reaches the proof only through job_key exactly as its zero bytes do today.

Privacy Considerations

Attestation is strictly opt-in and per-block. The default (0x00) is bit-identical to current behavior, so the fork itself reveals nothing about any miner. Scheme 0x01 identifies weights, never miners: anyone can mine a public checkpoint, and the field carries no operator identity. Scheme 0x02 reveals only that some blocks share an unknown model, and only to observers who already suspect linkage; a miner seeking full unlinkability uses 0x00 and loses nothing it has today. Private models remain private under every scheme.

Reference Implementation

To be linked before this PIP is promoted to Proposed. The verification side exists and has run at corpus scale: an independent scanner has recomputed keyed operand roots for every shape-eligible block since genesis and published the datasets, the single-assertion verifier (raw block bytes from any Blockbook-compatible source, offsets parsed by independent arithmetic, one pip-installable hash library), and the buffer-extraction conventions for the published checkpoints (DOI 10.5281/zenodo.21863620). A second implementation of the buffer-extraction conventions, written from the specification text alone, reproduces the reference buffers byte-exactly on six buffers spanning every match-confirmed family. The miner-side change is the identifier computation at model load plus writing 28 bytes; the node-side change is replacing the must-be-zero check with the scheme rules above. One constraint on defaults: the protocol's CPU reference miner draws fresh random operands every iteration and so can never truthfully attest a checkpoint; scheme 0x00 is the only correct default for it, and for any miner whose operands are synthetic.

Test Vectors

Identifier function vectors (27-byte outputs, hex):

WID_public("abc")                       = 046fbd7766a0204206bd6272876d247adaeeb3d43958adabd7e883
WID_public(ramp)                        = 939aaad981c4d41ef3ed076e7a3cff473978a48fb83d33e1255ebb
  ramp = bytes 0x00..0xff repeated 4 times (1,024 bytes)
WID_salted(salt, "abc")                 = 24f8455d03d67bddde989d4feeca0d592df57be2eedf057e79979b
  salt = 00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff

Real-operand vector (the flagship published checkpoint's first fused gate/up tensor, extracted under the published conventions):

repo      = pearl-ai/Llama-3.3-70B-Instruct-pearl
revision  = 6cc401caab46ffa688dea3553b2f55d3dfc1d0aa
tensor    = gate_up_fused, tp 1, shard 0, layer 0  (n 57,344 x k 8,192)
bytes     = 469,762,048
sha256    = efe46a96b9f1813c73cacbb536c3f5d542cddde50ea3068dfbe59f99ff947eec
WID_public = 0e04d97ac4d6f3e6f252ec366cd64df40f4b8179f7ab9ae0c97986

Structural vectors: a conformant verifier rejects a certificate with scheme 0x00 and any nonzero payload byte, and accepts a certificate with scheme 0x01 and the 28-byte region 01 || 0e04d9...c97986 regardless of whether the identifier matches the operand (the normative rules live in the Specification).

References

• PIP-2: Grouped-GEMM Proof-of-Useful-Work for Mixture-of-Experts (certificate versioning and pouw_meta precedent).
• PIP-3: FP PoUW Certificates (Draft 2026-07-30; its proposed configuration layout lists this reserved field explicitly).
• Pearl whitepaper (pearlresearch.ai/research/whitepaper): the planned-upgrades commitment to pre-quantization weight and activation matrices, the privacy section on attesting computation without revealing inputs, and the marketplace motivation's statement about compute that does not necessarily have useful work (all quoted 2026-08-11).
• Hawkeye, arXiv:2603.20421 (bit-exact CPU reproduction of GPU tensor-core matrix multiplication for third-party auditing of model execution).
• Weight-provenance scan: dataset, method, and verification residuals, DOI 10.5281/zenodo.21863620 (current version 10.5281/zenodo.21884840).
• BLAKE3 specification (derive_key mode and keyed mode).
• BIP-141 (segregated witness; the optional coinbase witness commitment) and Zcash ZIP-244 (extensible block commitments).
• TensorCash, "Verifiable Inference" whitepaper (tensorcash.org/whitepapers/Verifiable_Inference.pdf, accessed 2026-08-10).
• Bittensor pretraining subnet, chain model commitments (github.com/macrocosm-os/pretraining, accessed 2026-08-10).
• OpenSSF Model Signing specification (github.com/ossf/model-signing-spec, accessed 2026-08-10).
• TOPLOC, arXiv:2501.16007 (activation-commitment inference verification).

Copyright

Copyright and related rights waived via CC0.