Topics · Protocol concept

ZK-SNAP receipt

Given only the receipt file and issuer public key material, a verifier checks receipt_id, timestamp bounds, claim binding, signature algorithm support, and declared profiles — with no network call for base validity.

Concrete scenario

What this looks like in practice

Two parties disagree about whether a configuration change was approved. One side produces a screen shot from an admin panel; the other produces a JSON export with different timestamps. Neither artifact proves what the issuing system signed at the moment of the change.

Problem

What breaks today

Dashboards narrate events; disputes need bytes. Without a canonical signed object, every review devolves into trusting the operator UI or an export that can be edited after the fact.

Mechanism

How ZK-SNAP responds

A ZK-SNAP receipt is JCS-canonical JSON under the ZKAI-SNAPSHOT-v0.1 domain prefix. It binds provenance, inputs_root, timestamp, signature, optional profiles, receipt_id, and ext_* commitments. The producer signs with sig and receipt_id omitted from the preimage; verifiers reconstruct the same bytes.

Verifiable outcome

What a verifier can check

Strict JSON parsing rejects duplicate keys and unknown non-ext_* fields before verification runs.
receipt_id matches the deterministic digest of the canonical signed payload.
Ed25519 signature verifies over domain prefix plus canonical receipt object.
inputs_root commits to the claim without requiring full payload disclosure.

Related profiles and labels

Canonical receiptClaim commitmentOffline verification

Scope boundary

What a receipt does not replace

The receipt kernel defines portable validity — not business approval, regulatory filing, or on-log recognition unless additional profiles and Chain evidence are present and verified.

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