Topics · Protocol concept

Sigils

Any viewer can recompute Sigil state from the same verifier inputs — the mark is not awarded manually and cannot be toggled by operator branding alone.

Concrete scenario

What this looks like in practice

A newsroom tool shows a green shield for any uploaded file with metadata. A security reviewer needs to know whether the file is offline-proven (S4) or merely uploaded, and whether on-log recognition (S5) actually exists for the displayed receipt and its anchor evidence.

Problem

What breaks today

Trust UI drifts when platforms hand out badges, reuse verified language loosely, or show the same icon for offline-valid and on-log-recognized receipts. Reviewers cannot tell which proof conditions were actually satisfied.

Mechanism

How ZK-SNAP responds

Sigils S0–S6 are deterministic visual states computed from verifier output, Depth-of-Trust set, on-log state, and hybrid crypto status. Verified language is reserved for recognized on-log receipts; offline-valid receipts surface as Valid or proven states instead of borrowed platform branding.

Verifiable outcome

What a verifier can check

Sigil state recomputes from published verifier rules and receipt facts.
S4 reflects offline validity without implying chain witness.
S5 appears only when DoT-5 recognition preconditions pass.
Manual badge overrides are outside the Sigil computation path.

Related profiles and labels

Deterministic visual stateValidVerified on-log

Scope boundary

What a receipt does not replace

Sigils communicate verifier outcomes — not aesthetic trust branding, editorial endorsement, or 3DVC certification unless the separate certification mark program applies.

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