Demand is Context
Demand is not a compute property. A machine action counts as Context-Bound demand only when intent, authority, scope, and environment are verifiably bound to the receipt.
Protocol
The ZK-AI Protocol
ZK-SNAP receipts. The Depth of Trust ladder. Chain recognition. The Evidence Graph. Sigils. 3DVC program rules. Everything here is ZK-AI — not a product feature, the actual protocol.
Machine Action Something happened
ZK-SNAP Receipt Signed at the edge
Batch Root Many become one
ZK-AI Chain Permanently anchored
Evidence Graph Findable forever
Core invariants
One Job: Make Evidence Checkable
Not a compute market. Not a hosted product. Not a database. ZK-AI defines one thing: how machine actions produce receipts that can be verified from bytes alone — without the platform that created them, without a network, without anyone’s permission. That offline verifiability is the baseline. Everything else — chain anchoring, discovery, certification — is additive.
Proof is edge-generated
Receipt issuance happens at or near execution by an operator or Proof Node. The chain orders anchors; it does not generate the proof.
ZK-SNAP is atomic
The ZK-SNAP receipt is the canonical Proof Unit. It binds demanded context, machine action, outputs, and evidence commitments into an offline-verifiable object.
Economics are GAS/ZKAI
Protocol economics are expressed in GAS and settled in ZKAI. Operator billing units and runtime cost models are not Protocol Primitives.
Proof is not consensus weight
PoD provides cryptographic and economic meaning, not validator authority. Chain ordering and finality remain chain-consensus concerns.
Offline validity is base truth
Base receipt validity must be checkable from bytes, canonicalization, signatures, and declared profiles. Network-dependent signals are additive.
VMA and ZK-SNAP
ZK-SNAP: The Receipt Format
Every machine action is a Verifiable Machine Activity — the semantic unit of accountable behavior. ZK-SNAP is the wire format that represents it: a JCS-canonical JSON object, signed under a fixed domain prefix, verifiable offline. VMA is what happened. ZK-SNAP is the proof. They are separate by design. The action exists regardless; the receipt makes it checkable.
VMA
Verifiable Machine Activity is the accountable action: a digitally mediated machine behavior performed under declared authority, scope, and context.
ZK-SNAP receipt
A ZK-SNAP receipt is a JCS-canonical JSON object signed under the ZKAI-SNAPSHOT-v0.1 domain prefix. It carries provenance, inputs_root, timestamp, signature, profiles, receipt_id, and optional ext_* commitments.
Claim and inputs_root
The claim captures inputs, context, outputs, or artifact roots. The receipt commits to the canonical claim through inputs_root, allowing selective disclosure instead of public payload exposure.
Attachments
On-log proofs and hybrid signatures attach to an immutable receipt. DoT-4 to DoT-5 promotion does not mutate receipt bytes.
Receipt kernel
The Receipt Kernel
The kernel is minimal by design. Provenance, fingerprint, timestamp, signature — enough to prove what happened and who signed it, without storing the underlying content. Profiles extend the kernel for specific domains: robotics, media, agents, datasets. The kernel doesn't change. The proof obligations do.
Canonicalization
Receipts and committed claims use deterministic JSON canonicalization. Duplicate keys, unknown non-ext_* fields, malformed digests, and unsupported versions are verifier failures.
Signature preimage
The producer signs the domain prefix plus the canonical receipt object with sig and receipt_id omitted from the preimage. Verifiers reconstruct the same bytes.
Profiles
Declared DoT profiles make additional provenance fields or ext_* commitments normative. Missing required profile material causes profile failure, not silent downgrade.
Bridge fields
External C2PA, VC, DID, time, settlement, evidence, privacy, robotics, data, and training artifacts are bound by typed ext_* fields or attachments where specified.
Depth of Trust
How Deep Does the Proof Go?
S4 is the self-sovereign state: the receipt proves itself from bytes alone, with no network, no server, and no company needing to exist. S5 adds the governed on-log record: permanently anchored on ZK-AI Chain, with an inclusion proof attached to — not embedded in — the immutable receipt. The Sigils spec puts it directly: S4 is stronger for independence; S5 is stronger for public accountability. S6 adds quantum-resistant signatures. Each rung adds without replacing.
Depth of Trust
Progressive verification from structure to quantum-hardened
DoT-0
Invalid
S0
DoT-1
Draft
S1
DoT-2
Scoped
S2
DoT-3
Governed
S3
DoT-4
Proven
S4
DoT-5
Recorded
S5
DoT-6
Hardened
S6
Domain Profiles
The ladder measures proof depth. Profiles declare what a specific domain requires — robotics safety, media provenance, data transformation, agent accountability. The receipt kernel doesn't change. The obligations do.
DoT-BROWSE
Binds browser or retrieval environment evidence such as page state, tool context, and visible artifacts.
DoT-XFORM
Binds transformation chains, input roots, output roots, and stage identifiers for data or content workflows.
DoT-ROBOT
Binds robotic command, asset, safety, pre-state, post-state, and operating context claims.
DoT-DATA / DATASET / TRAIN
Binds data provenance, dataset roots, training run evidence, model manifests, and weight commitments.
DoT-RAI / SAFETY
Binds responsible AI controls, retrieval provenance, safety cases, hazard context, and policy evidence.
DoT-TIME / EVIDENCE / SETTLE / PRIV
Binds time witnesses, supply-chain or infrastructure attestations, settlement proof, and sealed privacy commitments.
Chain recognition
ZK-AI Chain: The Governed Witness
The original receipt bytes stay exactly the same. Always. The chain does not store receipts — it stores batch roots. Chain recognition is attachment-only: an inclusion proof attaches to the receipt, linking it to a permanent AnchorRecord. The chain is an anchor registry for ordering and finality, not a receipt index. One batch root anchors thousands of receipts. The private payload never touches the chain.
receipt + inclusion proof → AnchorRecord →
recognized on-log
Evidence Graph
Upload the Content, Find the Receipt
People rarely come back with the receipt file. They come back with the content — a copy of the image, an export, a screenshot. The Evidence Graph indexes proof trails by content hash, time window, and artifact root so the receipt is findable from the copy alone. It does not determine receipt validity. It does not block or downgrade DoT-5. It cannot override what the chain says. Validity comes from ZK-SNAP. Recognition comes from ZK-AI Chain. The Evidence Graph finds. See the Network page for how Chain, Evidence Graph, and dePoD fit together.
A copy of the content image · export · screenshot · dataset
No receipt file required
Evidence Graph indexes by content hash · time window · artifact root
Receipt + proof trail who anchored it · when · under what claim
Discovery
The Evidence Graph indexes receipt projections, artifact roots, normalized text roots, entity references, time windows, and anchor references so minted content can resolve back to related proof trails.
Forensics
EG supports incident reconstruction, compliance review, and evidence-chain traversal after images, files, datasets, documents, or machine records move through tickets, reports, archives, and other systems.
Not consensus
EG does not define receipt validity, DoT-5 recognition, chain finality, Sigils, or 3DVC. It must not contradict canonical chain anchors.
Privacy surfaces
Public EG responses are PRS by default. Locator material, private evidence, retention state, and identity-rich projections belong behind PDS or explicit OAS.
Privacy model
Public Recognition Is Not Public Disclosure
Accountability and privacy are not mutually exclusive — they only appear to conflict when accountability is built into the base data layer. ZK-AI is a parallel layer: it issues receipts about private events without touching the private data. The chain sees that a receipt was anchored. It does not see what the receipt contains. `inputs_root` commits to a claim without revealing it. Sensitive fields can be disclosed later, to parties with lawful access, using selective disclosure. Public proof. Private content. Separate layers.
PRS
Public recognition facts: receipt_id, batch_root, anchor_id, inclusion verification material, and computed DoT-5 recognition state. PRS must not expose locators, tenant identifiers, retention state, or linkage-heavy metadata.
PDS
Authorization-gated disclosure for encrypted locator envelopes, retention state, commitment openings, and evidence artifacts. PDS must bind disclosures to receipt context.
OAS
Explicit opt-in attribution for publisher or operator identity claims. OAS is not required for DoT-5 recognition and must not become implicit public identity.
Sigils
Sigils: The ZK-AI Trust Mark
A Sigil is always deterministic: `Sigil = f(code, dotSet, on_log, hybrid)`. No human makes the call. No platform awards it. The verifier runs the function and the Sigil is the output. S4 means the mathematics check out. S5 means governed Chain evidence records it. S0 means it failed — do not trust it. The Sigil is designed to communicate at a glance, without any protocol literacy required. S4 is the self-sovereign state. S5 is the on-log record. Both are valid. They answer different questions.
3DVC
3DVC™: The Certification Mark
A ZK-SNAP receipt is valid without 3DVC. S4 means the mathematics check out. S5 means it has governed on-log witness evidence. That's already useful — and available to anyone using the protocol. 3DVC is the program path for qualified operators who need to demonstrate something more: that the receipt came from a declared, verifiable context — an intent, an authority, a scope, an environment. Not just "this happened" but "this happened, under these conditions, by this authority, and that claim is independently verifiable." That's the Context gate. It's required for receipts claiming 3DVC because a receipt without declared context can be a valid signed record — but it can't carry an accountability claim at the program level.
ZK-SNAP
receipt
receipt
V Validity
T Transparency
F Finality
C✱ Context Gate required
3DVC_OK Certification mark
V Validity
Receipt passes ZK-SNAP verification and declared profile checks.
T Transparency
Append-only log inclusion supports anti-fork and anti-equivocation reasoning.
F Finality
External anchoring or chain finality makes the artifact durable beyond one operator.
C Context Gate ✱ required
Receipts must be bound to declared intent, authority, scope, and environment. Valid without it — not certified without it.
Independent testing by an authorized testing authority Not self-declared — operators cannot certify themselves Shown adjacent to the Sigil — never inside it, never automatic
Receipts work without 3DVC
Any ZK-SNAP receipt is valid and usable at S4 (offline-valid) or S5 (recognized on-log) without 3DVC certification. The Sigil is always shown. 3DVC is an additional certification for operators who need to demonstrate audit-grade accountability.
Verifier outcome
3DVC is computed by a verifier and returned as dimension-level results: status, V/T/F pass or fail, Context gate status, reasons, and Proof References.
Program mark
3DVC is a consumer-visible qualifier next to the VTL Sigil. It is not an additional Protocol Layer and is never required to interpret the VTL.