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.

Spec authority

Public-safe sources for this topic

ZK-SNAP receipt kernel schema — ZK-SNAP receipt kernel includes provenance, inputs_root, timestamp, optional profiles, optional receipt_id, signature, and ext_* fields.
Receipt verification reference — Verifier checks receipt_id, timestamp, optional claim binding, and receipt signature without depending on the original platform.
Protocol Frame master spec — Base receipt validity is offline-verifiable; network-dependent signals such as recognized on-log status are additive.

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 Network Proof Lab