Model provenance

A model name tells you very little. The same name can point to different weights on different hosts, a repository can change after you last looked, and a tokenizer or chat template can change a model's behaviour without touching its weights. Tenzro Network 1 identifies a model by what it is made of, and checks that identity at every step from download to response.

The manifest

A model manifest lists every file of a model: weights, tokenizer, chat template, configuration. For each file it records the path, the size, a SHA-256 hash and a BLAKE3 hash. Files are sorted by path and paths are normalised, so the same set of files always produces the same manifest.

The manifest's root is a Merkle root over those entries. It becomes the model's identity:

tenzro:model:<hex manifest root>

Because the root covers every file, changing a single byte of weights, a quantisation, a tokenizer or a template produces a different model identity. A certification of one root never carries over to another. An inclusion proof lets you check a single file against the root without downloading the others.

Multiple origins, independent observers

Weights for the same model are published in several places: by the model's creator, on public model hubs, on mirrors, and on Tenzro's own storage providers. Network 1 does not trust any one of them.

Instead, observers record what they found. An origin attestation is a signed statement by an observer, identified by its hardware-derived DID, saying: at this origin, at this time, these files had these sizes and hashes. Origins are of four kinds:

Each attestation either agrees with a manifest (every file matches in path, size and hash) or conflicts with it (a shared path differs). A conflict is a signed, attributable statement, so an origin or observer that lies is exposed by name.

When a model counts as verified

A model is verified when enough independent observers agree across enough distinct origins, with no conflict. By default that means more than one independent observer, across more than one distinct origin. A relying party can raise these thresholds, forbid any conflict, or accept only observers who are also issuers on its trust list.

Verified before serving

Model files on Network 1 are stored across providers as ordinary content-addressed objects: each file's BLAKE3 hash is its storage address. Any peer or storage provider can serve the bytes, and the downloader checks every chunk as it streams, so a corrupt or substituted chunk is caught immediately without trusting whoever sent it.

Before an operator's node loads a model, it streams every file through SHA-256 and BLAKE3 and compares them with the verified manifest. A tampered shard fails with the name of the file that did not match, and the model is not served.

At ingest, files are also checked for safe formats by their content, not their file names. Weights must be safetensors or GGUF; pickle-based formats are refused outright. A scan result can be published as a safety-scan credential by whoever ran it. See Certification and ratings.

Provenance on responses

Every inference response is covered by a receipt signed with one of the operator's declared receipt keys. The receipt binds:

• the model's manifest root,
• hashes of the request and the response,
• the operator and the jurisdiction the request was served from,
• the time it was signed.

So you can prove afterwards which exact model answered, and who served it. If the operator runs inside a TEE, the attestation evidence can be bound to the same response. See TEE.

The same receipt is the evidence used to hold operators to their own policies. See Operator policies.

Hosting a model

An operator that wants to serve or host a model:

1. Downloads the files from any origin.
2. Builds the manifest locally and checks it against the verified manifest for that model, or publishes an origin attestation if it is among the first observers.
3. Publishes the files to its storage, where each file is addressed by its BLAKE3 hash, and issues a storage origin attestation.
4. Loads the model only after local verification passes.

Building manifests, verifying local files and hosting them are admin operations on your own node, because they read your local disk. Reading a model's manifest, attestations and verified status is open to anyone.

Related

• Trust and provenance
• Models
• Model serving
• Decentralised storage