Topics · Protocol concept

ZK-AI Chain

A party can verify batch membership and recognition state from inclusion proof material and chain-visible anchor facts while the original signed receipt bytes remain unchanged.

Concrete scenario

What this looks like in practice

A receipt verifies offline in court, but the counterparty argues it was backdated. The verifier needs independent evidence that the receipt_id was included in a governed batch_root at a protocol-visible point in time — without publishing private claim fields on-chain.

Problem

What breaks today

Offline validity proves mathematics; it does not prove when a batch was recognized on-log in governed protocol history. Disputes about timing and recognition need an anchor layer that does not become a receipt database.

Mechanism

How ZK-SNAP responds

Operators submit signed AnchorCommit material with batch_root, lane, operator identity, and time window metadata. AnchorRecord entries provide DoT-5 on-log reference. Inclusion proofs connect receipt_id to batch_root while private payloads stay off-chain and chain-visible data remains compact commitments only.

Verifiable outcome

What a verifier can check

Inclusion proof verifies receipt_id membership in the declared batch_root.
AnchorRecord replay matches governed chain rules for the claimed lane and operator.
Original receipt still passes offline signature checks independent of anchor presence.
Sigil S5 (Recorded) appears only when on-log recognition preconditions are satisfied.

Related profiles and labels

Compact commitmentsChain witnessOn-log recognition

Scope boundary

What a receipt does not replace

ZK-AI Chain is an anchor registry and witness layer — not a file store, receipt search engine, or substitute for offline validity when Chain evidence is absent.

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