Trust and provenance

Abstract

A buyer of inference on Tenzro Network 1 can ask four questions and get signed answers: which weights answered this request, who served it, under which policy, and who vouches for the model and the operator. Anyone can issue a certification or a rating for a model or an operator. Relying parties choose the issuers they trust. Operators publish signed policies and are slashed only for provable breaches of their own policy. Model weights are identified by a hash over every file, stored across multiple origins and verified by hash. Trusted execution environments supply evidence about where a computation ran, verified fully for each vendor. Compliance tiers come from these credentials, not from a central registry.

1. Introduction

Trust in AI is usually a claim: a model card, a badge on a hub, a provider's promise. Claims do not bind to the bytes that actually served a request, cannot be revoked in time to matter, and put whoever hosts the list in charge of what everyone else may use.

Network 1 replaces claims with evidence. The design follows four principles.

1. Permissionless issuance. Anyone can issue a certification or rating. No issuer is privileged by the protocol, and nodes hold no list of trusted issuers.
2. Relying-party choice. Users, applications, routers and operators decide which issuers they recognise. Certifications are signals for routing and reputation, not gates for joining the network.
3. Accountable, not censorial, enforcement. Each operator declares its own policy. A provable violation of that policy slashes the operator's bond. The network never decides centrally what content is allowed.
4. Hardware-rooted signers. Issuers, operators, observers and relying parties sign with hardware-rooted keys. Every signer's DID is derived from its key, so a verifier needs no directory.

2. Subjects

Trust statements are made about two kinds of subject.

• A model, named by the root of its manifest: tenzro:model:<root>. The root is a Merkle root over every file of the model, so the name commits to every byte that will be served.
• An operator, named by its hardware-rooted DID, such as a did:tenzro:machine DID for a node or a did:tenzro:human DID for a person who operates one.

Naming a model by its manifest root rather than by a display name matters. A name on a hub can be re-registered by someone else; a root cannot.

3. Credentials

Certifications, ratings, evaluations and safety scans are W3C Verifiable Credentials. Each credential names an issuer, a subject, a validity window and a claim, and carries a proof over the whole document made with the issuer's hardware-rooted key.

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "TenzroTrustCredential"],
  "issuer": "did:tenzro:human:...",
  "validFrom": "2026-10-01T00:00:00Z",
  "validUntil": "2027-10-01T00:00:00Z",
  "credentialSubject": {
    "id": "tenzro:model:...",
    "claim": {
      "kind": "certification",
      "scheme": "org.example.redteam",
      "grade": "pass",
      "evidence": [{ "uri": "https://example.org/report.pdf", "sha256": "..." }]
    }
  },
  "credentialStatus": { "type": "BitstringStatusListEntry", "statusPurpose": "revocation" },
  "proof": { "...": "..." }
}

The claim kinds are:

A credential is valid at a given time only if its proof verifies, its issuer DID derives from the signing key, the time is within its validity window, it has not been revoked, and the issuer's key has not been revoked. Every credential must expire; nothing is issued forever.

An issuer can prove its standing the same way: an accreditation is just another credential that a relying party may choose to require.

4. Revocation

Revocation is first-class.

• Each issuer publishes a status list in the W3C Bitstring Status List form. Revoking a credential sets its bit, and revoked bits never clear.
• Only the issuer can revoke its own credentials, with a revocation signed by the same key.
• An issuer that loses control of its key can revoke the key itself. Every credential from that key then fails verification.

Routers evaluate status when a request arrives, not from a cache, so a revocation reaches routing promptly.

5. Trust lists

A trust list is a document a relying party signs with its own key. It names the issuers the party recognises and what it requires.

{
  "type": ["TenzroTrustList"],
  "owner": "did:tenzro:human:...",
  "sequence": 4,
  "issuers": ["did:tenzro:human:...", "did:tenzro:machine:..."],
  "require": [
    { "subject": "model", "kind": "certification", "scheme": "org.example.redteam" },
    { "subject": "operator", "kind": "policy-conformance" }
  ],
  "provenance": { "minObservers": 2, "minOrigins": 2, "allowConflicts": false }
}

• Only the owner can replace its list; the highest sequence number wins.
• A requirement is met only by a valid credential from an issuer on the list.
• A relying party with no trust list sees no filter.

Trust lists apply per request, so an application can name the list to use when it calls a model, and per node, so an operator can decide which models it is willing to serve. A regulated organisation can require credentials from the issuers its regulator recognises; an open application can require nothing.

6. Operator policies

Every operator publishes a signed, machine-readable policy stating what it serves and refuses.

The policy is enforced by the operator's own node: it refuses to serve a model its policy does not list, or a model missing the credentials the policy promises. Policies are versioned, carry a validity window and cannot be back-dated.

7. Violation evidence and slashing

Every served request produces a receipt signed with one of the operator's declared receipt keys. The receipt names the model's manifest root and where the request was served.

Some clauses are mechanical: a single receipt can prove a breach. If a receipt shows a model that the policy does not serve, or a jurisdiction the policy excludes, anyone can submit the policy and the receipt as violation evidence. The check is deterministic:

1. The policy's signature verifies.
2. The receipt's signature verifies under a receipt key the policy declares.
3. The receipt was signed while the policy was in force.
4. The receipt contradicts the named clause.

A proven violation slashes the operator's bond once per piece of evidence, and the evidence is recorded so it cannot be submitted twice.

Other clauses, such as refused categories or data handling, need judgement. They are declarations; a breach goes through the dispute process and is never slashed automatically.

This is the core of the design: an operator is accountable for its own promises, and nobody else decides what it must allow.

8. Model provenance

8.1 Manifests

A model manifest lists every file of a model with its path, size, SHA-256 and BLAKE3 hash. That includes weights, tokenizer, configuration and chat template: a chat template can change a model's behaviour as much as its weights can. The manifest root is a BLAKE3 Merkle tree over those entries, and an inclusion proof lets a downloader check a single file against the root.

8.2 Many origins

A model's files can be held by its creator, by public model hubs, by mirrors and by Tenzro storage providers. An observer, anyone with a hardware-rooted DID, can sign an origin attestation stating what it saw at an origin: each file's path, size and hash at a given version.

• An attestation agrees with a manifest if it lists every file with matching hashes.
• It conflicts if any file it shares with the manifest differs.

By default a model is verified when more than one independent observer, across more than one distinct origin, agrees and nothing conflicts. A relying party can demand more, or can require observers from issuers it trusts. A lying mirror produces a conflict: a signed, attributable false statement.

8.3 Storage and download

Each file's BLAKE3 hash is also its storage address on the network, so storage providers and peers serve verified content by construction, and every chunk is checked as it streams. A node that downloads a model verifies every file against the manifest before serving it; a tampered shard fails with the path of the offending file.

8.4 Safe formats

Before a model is hosted, its files are scanned by content, not by file name. Weights must be in safe tensor formats such as safetensors or GGUF. Formats that can execute code on load are refused. The scan result can be issued as a safety-scan credential by whoever ran it.

9. TEEs as evidence

Trusted execution environments protect data in use and attest to what code ran where. On Tenzro they are evidence, not custody, and they never weight consensus.

9.1 Supported platforms

Attestation is verified fully for each vendor: signatures, certificate chains to pinned vendor roots, validity periods, security versions and measurements. Simulated or unverifiable reports are refused. An attestation is bound to the key and the workload it speaks for, so it cannot be lifted from one enclave and presented for another.

9.2 What attestation is used for

• Confidential inference. Prompts and outputs are processed inside an attested enclave; the attestation and the operator's receipt tell the caller where and on what the request ran. Inference verification on Tenzro is TEE-first.
• Confidential training. Sealed training data is decrypted only inside an attested trainer enclave whose measurement the sponsor specified.
• Credentials and routing. A verified attestation can be referenced in a credential, and a trust list can require it.

9.3 What attestation is not used for

TEEs are never custody: no user or network key is sealed inside an enclave in place of hardware-rooted device keys. And TEEs never substitute for a quorum: physical attacks on memory can defeat enclave guarantees, and in a permissionless network the operator has physical access by definition. Consensus safety rests on n = 3f + 1, not on trusted hardware.

10. Compliance tiers

A compliance tier is the answer to a relying party's trust list, not a label in a central registry. The same identity can meet one organisation's requirements and not another's, because each chooses its issuers. For people and organisations, tiers come from identity credentials issued by parties the relying application recognises. For models and operators, they come from the credentials, policies and provenance described above. See Hardware-rooted identity.

11. How it fits together

A request with a trust list runs as follows:

1. The application calls a model and names its trust list.
2. The router keeps only providers whose operator and model meet the list: valid, unrevoked credentials from listed issuers, verified provenance, and an operator policy that serves the model.
3. The chosen operator serves the request under its policy and signs a receipt naming the manifest root.
4. The receipt is settled, feeds reputation and pricing, and remains available as evidence.

Everything a relying party needs to check this is public and signed: credentials, status lists, trust lists, policies, manifests, origin attestations and receipts. Every record re-verifies when it is applied, so records can arrive from any peer in any order and every node converges on the same state.

12. Conclusion

Trust on Tenzro is built from evidence that anyone can check and nobody controls centrally: permissionless credentials, relying-party trust lists, signed operator policies with slashing for provable breaches, verifiable model provenance, and TEE attestation treated as evidence. For hands-on detail, see Trust and provenance, Credentials, Operator policies, Model provenance and TEE.