Trust and provenance

How Network 1 lets anyone certify or rate models and operators, lets you choose whose word you accept, and ties every answer to verified weights.

When you send a request to a model on Tenzro Network 1, three questions matter: which model actually answered, who is running it, and who vouches for either of them. Network 1 answers all three with signed, verifiable records rather than with a central registry or an approved-vendor list.

Trust and provenance is built from four parts:

Part	What it gives you	Page
Certification and ratings	Signed statements about a model or an operator, issued by anyone	Certification and ratings
Trust lists	Your own choice of which issuers you accept	this page
Operator policies	A signed, public declaration of what an operator serves and refuses	Operator policies
Model provenance	A content address for every file of a model, agreed across independent origins and checked before serving	Model provenance

These records sit beside the hardware evidence described in TEE and the agent reputation described in ERC-8004.

Principles

Anyone can issue. A regulator, a standards body, an auditor, a red team, a community or the model's own creator can certify or rate a model or an operator. Every certification is a W3C Verifiable Credential signed with the issuer's hardware-rooted key. The protocol privileges no issuer and the network keeps no list of approved ones.

You choose whose word counts. Users, applications, routers and operators each decide which issuers they recognise, by signing a trust list with their own key. Nobody else can edit your list. A certification is a routing and reputation signal for the parties who chose to accept it, not a gate on joining the network. If you subscribe to no issuers, nothing is filtered.

Operators are held to what they declare. Each operator publishes a signed, machine-readable policy stating which models it serves, in which jurisdictions, and what it refuses. The network never decides centrally what content is allowed. An operator is slashed only for a breach of its own policy that can be proven from its own signed receipts.

A model is its bytes, not its name. A model is identified by a hash over every file it is made of: weights, tokenizer, chat template and configuration. Independent observers record what they found at each origin, and a node checks the files against that identity before it serves them.

Revocation and expiry are first-class. Every credential has a validity window, and an issuer can revoke any credential it issued. Routers evaluate status at request time, so a revoked certification stops counting straight away.

Subjects and names

Every trust record is about one of two kinds of subject.

Subject	Identifier
A model	`tenzro:model:` followed by the hex root of its manifest (a hash over every file)
An operator	The operator's hardware-derived DID, such as `did:tenzro:machine:...` for a TPM or Secure Enclave key, or `did:tenzro:human:...` for a person using a passkey

Issuers, observers and relying parties are also identified by hardware-derived DIDs. Because a DID is derived from its signing key, anyone can verify a record without looking the issuer up in a directory. See Identity and Hardware-rooted keys.

Trust lists

A trust list is a small document you sign with your own key. It names the issuers you accept and, optionally, the credentials you require before a model or operator is used for your requests.

json

{
  "type": ["TenzroTrustList"],
  "owner": "did:tenzro:human:...",
  "sequence": 3,
  "issuers": ["did:tenzro:human:...", "did:tenzro:machine:..."],
  "require": [
    { "subject": "model", "kind": "safety-scan" },
    { "subject": "operator", "kind": "certification", "scheme": "iso-iec-42001" }
  ],
  "provenance": { "minObservers": 2, "minOrigins": 2, "allowConflicts": false },
  "proof": { "...": "signed by the owner's key" }
}

Only the owner can replace the list; the highest sequence wins.
A requirement is met only by a valid, unrevoked credential from an issuer on the list.
The provenance block sets how much independent agreement you need on a model's files before it counts as verified.
A list that requires credentials but names no issuers could never be satisfied, so it is refused.

You can apply a trust list per request, so a single application can serve different customers under different rules, or per node, so an operator only routes to models and peers that meet its own bar.

How a request uses it

Your request names the trust list to apply, or the node applies its operator's list.
The router drops any model whose manifest is not verified to your provenance thresholds, and any model or operator that lacks a required credential from an issuer you accept.
The serving operator checks the request against its own signed policy and refuses anything the policy does not cover.
The model's files are checked against the manifest before they are loaded.
The response carries a signed receipt naming the model's manifest root, the operator, and the jurisdiction it was served from.

Each step can be recomputed by anyone from public, signed records.

Compliance without a central registry

Compliance tiers come from trust credentials, not from a registry someone maintains. A regulated organisation lists the certification bodies and auditors it already relies on, requires their credentials, and restricts jurisdictions for models, data and compute. See Compliance.