Publish an operator policy and get certified

Declare what your node serves in a signed operator policy, understand exactly what you can be slashed for, and collect certifications callers can filter on.

Callers on Tenzro Network 1 choose who they send work to. Two things let them choose you: an operator policy, which is your own signed statement of what you serve and refuse, and certifications, which are signed statements about you or your models from issuers the caller trusts.

Both are permissionless. You write your own policy; nobody approves it. Anyone can issue a certification or rating: an auditor, a standards body, a regulator, a customer or a community. No issuer is privileged by the network, and each caller decides which issuers count.

The policy is also the limit of your exposure. An operator is slashed only for a provable breach of its own declared policy. Nothing you did not promise can be held against your bond.

Prerequisites

A provider node with a hardware-rooted identity and a posted bond. See Join Network 1 as a provider.
At least one model you serve, or plan to serve.

1. Find your operator identity

Your policy and every certification about you name your operator DID, which is derived from your node's TPM or Secure Enclave.

bash

tenzro node did-document

Note the did:tenzro:machine:... identifier. Only a key rooted in that hardware can sign for it.

2. Pin the models you serve by hash

A model's identity on the network is the BLAKE3 root of its manifest, which commits to every byte of every file. Refer to models by that root when you want a promise to cover exact weights, not just a name.

bash

tenzro model get-hash qwen3-8b

3. Decide what to declare

A policy has two kinds of clause, and they carry different consequences.

Clause	Kind	What happens on a breach
`serves.models`	Mechanical	Provable from a signed receipt alone. Your bond is slashed.
`jurisdictions`	Mechanical	Provable from a signed receipt alone. Your bond is slashed.
`serves.requireModelCredentials`	Enforced by your node	Your node refuses models that lack the credentials you promise.
`refuses.categories`	Judgment	A declaration. A claimed breach goes to a dispute that needs a quorum judgment, never an automatic slash.
`data`	Judgment	Same as above.

Declare only what you will actually hold to. A narrow, true policy is worth more than a broad one you cannot keep.

4. Write the policy

json

{
  "type": ["TenzroOperatorPolicy"],
  "operator": "did:tenzro:machine:<your-node-id>",
  "sequence": 1,
  "validFrom": "2026-10-01T00:00:00Z",
  "validUntil": "2027-10-01T00:00:00Z",
  "serves": {
    "models": ["qwen3-8b", "tenzro:model:<manifest-root>"]
  },
  "jurisdictions": ["EU", "CH"],
  "refuses": {
    "categories": ["malware-generation", "targeted-harassment"],
    "unsafeFormats": true
  },
  "data": { "retentionDays": 0, "trainsOnInputs": false }
}

sequence increases with every revision. The highest sequence in force wins.
validFrom and validUntil bound the policy in time. Receipts are judged against the policy that was in force when they were signed.
unsafeFormats: true declares that you refuse weights in formats that can execute code on load; only safetensors and GGUF are served.
jurisdictions: null means you make no jurisdiction promise.

5. Sign and publish it

Your node signs the policy with its hardware-rooted key and binds the keys it signs inference receipts with to your DID, so a receipt can be tied to your policy and nobody can claim your keys. The signed policy is published to the network, replicated to every node, and listed in your DID document.

Check that it is visible:

bash

tenzro node did-document

From then on your node enforces the policy on itself: it refuses to serve a model the policy does not list, and a model without the credentials the policy promises.

6. Get certified

A certification is a signed credential with a subject, an issuer, a validity window and a claim. The subject is either your operator DID or a model's manifest root. The claim says what kind of statement it is (certification, rating, evaluation, safety-scan or policy-conformance), under which scheme, and optionally a grade or score and a link to the evidence.

To get certified:

Find out which issuers your customers rely on. Regulated buyers often name a specific auditor or scheme.
Ask the issuer to review your operation or model. They sign the credential with their own hardware-rooted key or passkey.
The issuer publishes the credential. It is verifiable by anyone, from its signature, without asking the issuer.

Credentials expire, and an issuer can revoke one at any time. A revoked or expired credential stops counting everywhere at once. See Credentials.

7. See yourself as a caller does

Callers keep a trust list: the issuers they recognise and the credentials they require, for operators and for models. A router applies it to every candidate provider and serves the request only from those that pass. A caller with no trust list sees no filter.

A regulated buyer's trust list might require, for example, a certification for the operator from one named auditor and a safety-scan for the model from any of three scanners. With your policy published and those credentials issued, your node passes that filter; without them, it is skipped, whatever its price.

8. Update the policy

To change what you serve, publish a new policy with a higher sequence. A newer policy governs receipts signed after it; receipts signed under the old one are still judged against the old one.

9. What a breach looks like

Evidence of a breach is your signed policy plus a receipt your node signed that contradicts a mechanical clause: a model outside serves.models, or a caller outside jurisdictions. Anyone can check the evidence independently. Proven evidence slashes your bond once, and the same evidence cannot be used twice.

Next steps

Operator policies for the full policy format.
Trust and provenance, Credentials and Model provenance.
Compliance for compliance tiers derived from trust credentials.