An on-chain registry that attests every model release

Why AI needs a model registry

As models proliferate and get fine-tuned, forked, and re-released, provenance becomes a supply-chain problem: which exact weights are running, who released them, and has anything been altered. A model registry is the answer, but a registry is only as trustworthy as its storage: a private database can be edited, and the parties most motivated to edit it are the ones who control it. QBC makes the registry an on-chain object, so model provenance is tamper-evident and independently checkable, extending the logic of AI content provenance to the model supply chain. The registry also slots into the wider AI audit trail the chain keeps for cognition, actions, and training, so a model's release record and its runtime record live in the same evidentiary system rather than in disconnected databases with different owners.

What QBC records for each checkpoint

QBC's model registry records, for each release, a content-addressed manifest root over the model's weights, adapter, tokenizer, and config; a name and semantic version; and the public release URI (its HuggingFace location). The manifest root is the cryptographic identity of the exact model, so a match proves the release is byte-for-byte what the chain attests, and covering the tokenizer and config matters because swapping either can change behavior while leaving the weights untouched. The step-by-step check, tooling included, is on verifying AI model integrity, and what open weights do and do not guarantee without such attestation is examined on open weights vs open source. This is the foundation of verifiable AI: model identity you can recompute from first principles rather than accept from a filename.

Finalised by validator quorum

A registry entry is not a self-asserted claim; it is finalised. Validators attest a submitted checkpoint, and once a quorum agrees, the entry is finalised on-chain with the same GRANDPA guarantees (arXiv:2007.01560) that finalise a transfer; the voting mechanics are explained on GRANDPA finality explained. That turns 'here is our model card' into 'here is a model release a validator quorum confirmed and the chain will not silently change'. The distinction is procedural, not cosmetic: a self-asserted entry can be corrected, backdated, or quietly replaced by whoever asserts it, while a finalised entry can only be superseded by a newer entry, in public, with the old one intact. The consensus machinery that produces these guarantees is covered on the Proof of Thought page.

How anyone verifies a model release

Verification is reproducible: download the released weights, adapter, tokenizer, and config; recompute the manifest root; and compare it to the on-chain registry entry. A match proves the model you are holding is the model the chain attests and the network serves, using nothing but public data and open tooling; no permission, account, or API key is involved. QBC's own flagship checkpoint is recorded on-chain and inspectable via the block explorer, the open weights live on HuggingFace, and the release process, including the attestation transaction and the serving cutover, is logged in the engineering writeup Aether v7.1 live on-chain and unified. The model itself and its training loop are described on the decentralised frontier LLM page.

What the flagship entry attests

The registry is easiest to understand through its flagship entry. At block 1,097,990 the network attested its served model: a frozen Qwen2.5-7B base, quantized to four bits, plus a ten-expert Sephirot mixture-of-experts adapter, with the manifest root matching the open weights published on HuggingFace. The adapter approach, freezing a sound base and training routed experts on top, is explained on MoE adapter fine-tuning, and the design for its next generation is sketched in V8: the Sephirot MoE, labeled as design work rather than a live release. Because the entry is checkable, benchmark claims can be tied to an exact artifact: the engineering log AethersMind v7: real benchmarks reports GSM8K up roughly ten points over the frozen base while MMLU stayed flat, an honestly mixed result published against the attested checkpoint. A registry entry turns benchmarks from marketing into citations: numbers pinned to weights the chain can identify.

Checking an entry from a light client

Registry entries are most useful to parties who will never run a node: an enterprise verifying a vendor's model, a regulator sampling attestations, a CI pipeline refusing to deploy unattested weights. QBC serves them through BEEFY with a Merkle Mountain Range, live on the network: validators co-sign compact commitments over finalised history, and a light client can confirm that a registry entry is finalised using kilobytes of proof, the mechanism described on light-client finality proofs. The deployment on the running chain, including the operational details of arming it, is documented in the engineering log BEEFY plus MMR finality proofs live. Combined with GRANDPA's deterministic settlement, this gives the registry the property provenance systems usually lack: verification cheap enough to embed anywhere, from build pipelines that gate on attestation to browser extensions that badge attested models for end users.

A tamper-evident AI supply chain

An on-chain registry gives the AI supply chain properties it usually lacks: every release is attributable, versioned, and tamper-evident, and the history cannot be quietly rewritten. Combined with per-block Proof-of-Thought, the registry lets you audit not just which model exists but which model produced a given output: provenance from release to runtime, with no gap in the middle where substitution could hide. It is secured on post-quantum rails (NIST FIPS 204), covered on the post-quantum blockchain page, and the lattice signatures behind every attestation are unpacked on Dilithium blockchain signatures. The post-quantum choice is not decoration here: a supply-chain record that could be forged retroactively by a future quantum adversary would lose exactly the property, durable attribution, that justifies keeping the record at all.

Registry, provenance, and regulation

Regulators are converging on requirements that high-risk AI be documented, versioned, and traceable (EU AI Act). An on-chain model registry is a direct, verifiable form of that documentation: model cards you cannot backdate or alter, with a finalization timestamp a third party can check. For engineering teams translating those duties into systems, the practical mapping, what to record, how to anchor it, and what an auditor can be handed, is on EU AI Act compliance engineering. The registry does not by itself make a model compliant; it makes compliance claims about the model demonstrable, which is the part that survives adversarial scrutiny. QBC anchors this today as part of the broader verifiable-AI system on the category overview and in the Aether Tree whitepaper.