Certification and ratings

W3C Verifiable Credentials that anyone can issue about a model or an operator, with expiry, revocation and relying-party choice of issuers.

Certifications and ratings on Tenzro Network 1 are W3C Verifiable Credentials (VC 2.0) about a model or an operator. Anyone can issue one. Whether it counts is up to the party relying on it, through their own trust list.

What a credential can say

Every credential carries a single claim of one of these kinds:

Kind	Typical issuer	Example
`certification`	An accredited certification body, a regulator, a standards body	An operator holds a management-system certification
`rating`	A community, a customer group, a review service	A graded rating of a model for a task
`evaluation`	An evaluation lab or red team	A benchmark or safety evaluation of specific weights
`safety-scan`	Anyone who scanned the files	The weights are in a safe format and contain no executable payloads
`policy-conformance`	An auditor	An operator's practice matches its published policy

The issuer chooses the scheme (for example a standard's identifier, a benchmark name, or its own reverse-domain id), and may add a grade, a numeric score, a scope describing what was reviewed, and evidence links with a hash of each report so the report cannot be swapped later.

Subjects

A credential is about exactly one subject:

a model, named by its manifest root: tenzro:model:<root>. Because the root is a hash over every file, a certification of a model covers those exact bytes. A re-quantised or modified copy has a different root and does not inherit it. See Model provenance.
an operator, named by its hardware-derived DID. A certification of an operator follows it across every model it serves.

Format

json

{
  "@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:9f2c...",
    "claim": {
      "kind": "evaluation",
      "scheme": "org.example.redteam",
      "grade": "pass",
      "scope": "Prompt-injection and data-exfiltration suite",
      "evidence": [{ "uri": "https://example.org/report.pdf", "sha256": "..." }]
    }
  },
  "credentialStatus": {
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "4211",
    "statusListCredential": "tenzro:status:did:tenzro:human:..."
  },
  "proof": { "type": "DataIntegrityProof", "...": "..." }
}

The proof is a W3C Data Integrity proof over the whole document, not just the subject, so no field can be altered after signing.
Issuers sign on their own hardware: a TPM, a Secure Enclave or a passkey. A regulator or auditor can issue with the passkey on their own laptop or phone. The node never holds an issuer's private key; it accepts only documents that are already signed.
The issuer's DID is derived from the signing key carried in the proof, so a verifier needs no directory lookup.
validFrom and validUntil are both required. Nothing is issued forever.

When a credential is valid

A credential counts at a given moment only if all of these hold:

The proof verifies over the whole document.
The issuer DID matches the key that signed it.
The moment falls between validFrom and validUntil.
Its revocation bit in the issuer's status list is not set.
The issuer has not revoked its own key.

Routers check validity at request time, so an expired or revoked credential stops affecting routing immediately.

Revocation

Revocation uses the W3C Bitstring Status List. Only the issuer can revoke its own credentials: it signs a revocation statement listing the status indices to set. Revoked bits never clear.

If an issuer's key is compromised, the issuer signs a key revocation. From then on every credential from that key fails verification, because a stolen key could have back-dated anything.

Anyone can fetch an issuer's status list and recompute every bit from the signed revocation statements it was built from.

Ratings and reputation are different signals

A certification or rating says what an issuer concluded after a review. Reputation says what paying counterparties experienced. Network 1 keeps both: credentials live in the trust records described here, and agent reputation grounded in settled payments is published through ERC-8004. A trust list can require credentials, and a router can also rank by reputation.

Why issuers are not curated

A node-held list of trusted issuers would make someone the gatekeeper for the whole network. Instead, an accreditation body can itself issue a credential to a certification body, and a relying party that cares about accreditation requires it in their trust list. The chain of trust is expressed in credentials and chosen by the party relying on it.