Topics · Protocol concept

Depth-of-Trust

Verifiers report which profile conditions passed and which are absent — enabling Sigils and audit language that track mathematics rather than operator marketing.

Concrete scenario

What this looks like in practice

A procurement officer sees Verified on a vendor dashboard. Offline, the same receipt only satisfies schema checks. Another receipt shows Valid offline but lacks inclusion proof for the on-log claim the UI implies. The officer needs precise states, not badge inflation.

Problem

What breaks today

A single checkmark hides which obligations were met. Teams need to distinguish structured claims, schema conformance, policy binding, offline validity, on-log recognition, and hybrid crypto assurance without collapsing them into one marketing label.

Mechanism

How ZK-SNAP responds

Depth-of-Trust profiles stack additive conditions over the receipt kernel: structured claim, schema-checked fields, constrained profiles, policy-bound context, offline-valid (DoT-4), recognized on-log (DoT-5), and hybrid crypto where declared. Each layer is evaluated independently so audit language stays precise.

Verifiable outcome

What a verifier can check

Each declared profile is evaluated independently against its published rules.
DoT-4 offline validity completes without network calls when profiles allow.
DoT-5 requires inclusion and anchor evidence — it is not inferred from UI copy.
Hybrid crypto profiles are evaluated only when explicitly declared and supported.

Related profiles and labels

Depth-of-TrustOffline-validOn-log recognition

Scope boundary

What a receipt does not replace

Depth-of-Trust labels describe verified conditions on a receipt — not organizational trust, legal certification, or 3DVC operator certification unless separate program marks apply.

Go deeper

Try the workflow, then read the spec.

Use Cases tells the story with cards. Proof Lab runs create and verify locally. Protocol holds the normative reference.

Protocol reference How it works Proof Lab