Verifiable evidence
Trooth publishes two signed objects buyers and agents usually meet, and three narrower ones. For each: the signed bytes, their subject, the key and how to check it without Trooth.
The profile itself, its facts and a company's declarations are not signed by anyone.
Every signed object, exactly
| Object | Signed bytes | About | Key | Status and replay | Check it yourself |
|---|---|---|---|---|---|
Witness statement, trooth.witness-statement.v2 (from October 4, 2026) or v1 (earlier) | The payload string itself, UTF-8, as served. Do not parse and re-serialize before checking. | One reading of a domain's public surface: each check's outcome, and counts. v2 also binds the mapping digest, evaluator version, scope, evidence manifest digest and a reason per check; v1 binds none of these. | key_id, listed at api.trooth.co/public/keys with its purpose and lifecycle times | No revocation list. Freshness is the signed read_at; apply the published key policy. | Run npx trooth verify with the domain, or follow the written rules. |
Trust Ledger Token, tlt2 | The issuer's over the payload, Trooth's over the signing event, which excludes the claim bytes. | The company's claims, signed by it; Trooth's signature records when it signed. | The company's key, and Trooth's trust-ledger key | Expiry inside the token; revocation reported by the verify endpoint. | GET api.trooth.co/v1/trust-ledger/verify/<token or id>, or the Model Context Protocol (MCP) tool trooth_verify. |
| Signed sign-off export | RFC 8785 canonical JavaScript Object Notation (JSON), one line, the exact file bytes; the signature is in a sidecar. | One buyer's recorded decision about a vendor. Not a backup of an account. | The export key at /api/verify/export-keys | No revocation list; the record carries its own date. | The openssl command below. |
Directory receipt, receipt_signature | Not published. The covered bytes are not served, so it cannot be checked independently today. | A published directory listing. | authority_key_id | Not applicable | Not possible yet. Use the witness statement. |
| Audit-chain block | Internal, hash-linked records of reads of connected systems. | A company's connected-system readings. | The trust-ledger key | Hash-linked; a break shows tampering. | Not published to the public. |
The crosswalk below is conceptual. Trooth issues no W3C Verifiable Credential and none of these objects conforms to one; this is not an interoperability claim.
What a witness statement binds
A v2 statement signs, beside the outcomes, the sha256 of the exact check mapping document the evaluator used, the evaluator's name and version, the subject scope, and the sha256 of an evidence manifest. The key, the signature format and the canonicalization are the same as for v1.
Each mapping version is published once and never edited, at /standard/check-mapping/<version>.json, and the index lists every version with its sha256. Check a reading against the version it names, not against the current mapping.
The manifest has one entry per check: the public sources it read, or a salted commitment where publishing the reference would expose a company's declaration or a sensitive path. The profile record carries it as witnessEvidenceManifest.
Every check not as expected carries a versioned reason code with its source, or a statement that the detail is withheld. A timeout or an unavailable source is not read, never not as expected.
A v1 statement, issued for readings before October 4, 2026, binds none of this. Its signature shows Trooth's key signed those outcome bytes, and it cannot by itself establish which mapping or sources produced them.
v1 statements stay valid, and no digest is ever added to one later.
To check a statement on your own machine, run npx trooth verify followed by the domain. It checks the signature, the key's status, the domain, the counts and both digests, and trusts no summary from Trooth.
A checker reports four results apart: binding present and matching, binding absent (v1, narrower assurance), binding mismatch, and bad signature.
Two objects, two roles
Beside the witness statement, two signed objects behave like ones your systems may consume.
Trust Ledger Token
A portable, signed receipt a company hands to a buyer or agent, with subject, issuer, claims and an offline-verifiable proof. Trooth co-signs as a notary, witnessing the signing, not the claims.
Audit-chain block
An internal, hash-linked record of a witnessed read, signed by Trooth's attestation key: Trooth produced this observation at this time, replayable end to end.
The crosswalk
Credential terms on the left; the matching Trooth field on the right.
| Verifiable credential | Trooth |
|---|---|
| Credential subject | The company the profile is about, by domain or Trooth slug. |
| Issuer | Trooth signs the witnessing event with its runtime attestation key; the customer signs the payload with its own key. |
| Claims | Declared audit-root hash, frameworks and classification, recorded byte-for-byte, not warranted true. |
| Proof | Two Ed25519 signatures in the token (tlt2): the customer's over the payload, Trooth's over the witnessing event. Each re-verifies alone. |
| Issuance and expiry | The signed wall-clock time and expiry. An expired token needs re-issuing, not a failure of trust. |
| Revocation | A revocation record by token id; the verify endpoint reports revoked tokens. |
| Anchoring | None: Trooth uses no third-party time service. The signing time is Trooth's own statement, checkable against its published public key. |
What the signature means
A notary stamps the signing, not the document's truth. Trooth's outer signature records that the customer's signature existed at the witnessed time.
It excludes the claim bytes, so only the company's signature binds the payload. It says nothing about whether the claims are true; verifiers assess them independently.
Signed exports from the buyer workspace
A buyer can download any sign-off as one line of RFC 8785 canonical JSON (a machine-readable format), the exact signed bytes. The Ed25519 signature is in a sidecar, never in the file.
Its trooth_envelope holds the key id, signing time, subject company, record id and digest, all signed. The public key is at /api/verify/export-keys.
The check takes three steps, the first two as the sidecar lists them:
- Save that key's public_key_pem as trooth-export-key.pem.
- Base64-decode the sidecar's Signature line into export.sig.
- Run the command below. It needs nothing from Trooth beyond that key.
openssl pkeyutl -verify -pubin -inkey trooth-export-key.pem -rawin \ -in trooth-signoff-<id>-<date>.json -sigfile export.sigA valid signature proves the bytes and signer, not that the decision was right, the vendor safe or any statement true.
Take the key from Trooth's site, never the sidecar, so one source does not supply both.
See also the Trust Protocol and the agent pattern.