What it is
A minimal Proof-of-Authority anchor ledger for ordering batch-root commitments and exposing recognition records.
Protocol network
ZK-AI Chain: Purpose-Built Accountability Layer
Is ZK-AI a Layer 1? Yes. Purpose-built.
ZK-AI Chain is not a general smart-contract chain and not a DeFi execution venue. Its job is narrower: order, time-bound, and recognize ZK-SNAP receipt batches.
The chain stores batch-root commitments, not private payloads. It gives machine activity a public recognition layer without turning sensitive data into public data.
ZK-AI Chain
Purpose-Built Layer 1 Recognition
Receipt truth stays at ZK-SNAP. Ordering truth is on-chain. ZK-AI Chain stores batch roots — Merkle roots over receipt IDs — not the receipts themselves. This keeps blocks small, verification fast, and private payloads off the chain. A receipt is valid at DoT-4 without the chain. The chain adds the governed on-log record: when it happened, in what order, witnessed by whom.
receipt + inclusion proof → AnchorRecord →
recognized on-log
What it is not
Not a general execution layer, receipt database, dashboard, search engine, file store, or public dump of private evidence.
What it stores
AnchorCommit and AnchorRecord material sufficient for batch-root recognition, ordering, metering, and replay.
What it proves
A valid receipt_id is a member of a batch_root that has an AnchorRecord recognized by ZK-AI Chain, even when the content is checked outside the original app.
Why this chain
Why Not Just Anchor Hashes Somewhere Else?
Anchoring a hash is not the same thing as protocol semantics. ZK-AI defines what the receipt means, how trust depth is evaluated, what counts as public recognition, how evidence is discovered, how Sigils render verification, and how GAS meters proof demand. A generic chain can store a hash. ZK-AI gives the hash meaning.
Recognition path
Chain Recognition Adds Proof Without Changing the Receipt
The original receipt bytes stay exactly the same. Chain recognition attaches inclusion material linking the receipt to a permanent AnchorRecord — so content can leave the platform that created it and still carry verifiable history.
1. Receipt issuance
An operator emits immutable ZK-SNAP receipts near execution and computes receipt_id for each receipt.
2. Batch root
Receipt IDs are sorted, committed into a Merkle tree, and represented by a compact batch_root.
3. AnchorCommit
The operator submits a signed AnchorCommit with batch_root, lane, operator, batch size, and time window metadata.
4. AnchorRecord
The chain validates and includes the commit, then exposes an AnchorRecord with anchor_id, block height, tx index, timestamps, block_id, anchor_root, and GAS metering.
5. Inclusion Proof
A verifier checks the receipt signature, receipt_id membership in batch_root, and the chain AnchorRecord for that batch_root without relying on the original dashboard.
6. DoT-5 recognition
When those checks pass, the receipt is recognized on-log. The receipt bytes stay unchanged; the proof is attached.
AnchorCommit
An AnchorCommit is a formal request to register a batch of receipts. It carries the batch root, time window, and operator signature. Validators check every commit against chain policy before acceptance. The signed payload binds metadata to the batch — anyone can verify the ordering without trusting a dashboard.
AnchorRecord
Once accepted, the commit becomes a permanent AnchorRecord. It carries block height, time, and metering references — the stable on-log reference point for every receipt in that batch. Content anchored here carries verifiable history wherever it travels.
Inclusion Proof
The chain does not store full receipts. A verifier checks the ZK-SNAP receipt, validates Merkle inclusion for receipt_id in batch_root, then checks the AnchorRecord on ZK-AI Chain.
Why Batch Roots Instead of Full Receipts
Full receipts may contain sensitive commitments or disclosure material. Batch roots keep blocks small, cost predictable, and private payloads private.
GAS and network release
ZKAI is the settlement asset for protocol GAS. GAS is consumed by chain transactions and evidence operations. The protocol is pre-testnet today — controlled private testnet will exercise the same metering and anchor rules before mainnet settlement is claimed live.
Governance model
ZK-AI.org Governs the Protocol Until the Network Can Govern Itself
ZK-AI.org is the current protocol authority for ZK-SNAP, ZK-AI Chain, Evidence Graph, Sigils, GAS metering, and release gates. The model is foundation-led now because the rules have to be coherent before the network opens outward.
Governance defines the meta-rules: validator admission, algorithm and profile registries, chain parameters, GAS schedules, public marks, and release transitions. It does not sign individual receipts or award trust to specific proofs. Operators mint receipts. Validators order and witness batches. Verifiers check the result.
Governance Sets the rules Authorizes meta-rules: validator allow-list, profile registries, chain parameters, GAS schedule. Does not sign receipts or award trust to specific proofs.
Operators Receipts & batches Emit ZK-SNAP receipts at the edge. Compute batch roots. Submit AnchorCommits. Cannot order blocks or witness finality.
Validators Blocks & anchors Sign PoA blocks. Accept AnchorCommits. Produce AnchorRecords. Cannot issue receipts or determine offline validity.
Verifiers Public check Anyone. DoT-4 offline from bytes alone. DoT-5 with chain inclusion proof. Open to anyone — no permission required.
Evidence Graph and certification marks sit beside this path — discovery and program layers, not receipt authority.
Foundation-led, then opened deliberately
ZK-AI.org holds protocol authority during pre-testnet and controlled testnet. Public network governance expands only after verifier, validator, metering, and release gates are ready.
Proof ≠ consensus weight
Generating receipts and proving demand does not grant authority over chain rules. Validators sign ordering; verifiers check cryptography.
Open kernel, governed witness
ZK-SNAP interop is the open floor. Public recognition on ZK-AI Chain and program marks are governed layers above it.
Built for the long run
Protocol economics are usage-metered with a supply floor and recycle path — designed so metering and settlement can keep operating as demand scales, not as a one-time launch event.
Protocol, operator, or research inquiries — Contact.
Network release
Pre-Testnet Now. Controlled Testnet Next. Public Mainnet Last.
ZK-AI Chain is being released in stages because receipt recognition, metering, validator rules, and public marks have to agree before they become public settlement infrastructure. The sequence is deliberate: harden the protocol and verifier first, run a controlled private testnet with real anchor mechanics and GAS metering, then expand operators and validators before any public mainnet settlement claim.
Protocol economics are usage-metered — demand pays for anchors and evidence operations, not idle emissions or passive rewards.
Network, governance, and settlement assurances remain staged: the model is specified in protocol docs; mainnet recognition and live settlement claims stay gated until hardening completes.
Pre-testnet
Public specs, Proof Lab, conformance artifacts, and verifier hardening. Receipt validity and protocol boundaries are defined before the network goes live.
Controlled testnet
Controlled private testnet with full GAS metering and anchor mechanics. Invited protocol operators exercise batching, anchoring, and canonical ZK-AI Evidence Graph submission under real protocol rules — settlement exercised privately first.
Mainnet
Public mainnet settlement, expanded independent operators, and a governed validator set grown deliberately after the private testnet proves the protocol economics, anchoring, and verification path.
See Legal and Trademarks for governance boundaries and open-spec vs governed layers.
Evidence Graph
Find the Receipt From the Content Alone
Nobody keeps the receipt file. They keep the image, the export, the screen shot. 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 them.
A copy of the content image · export · screen shot · 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.
dePoD
Payment Should Follow Useful, Receipt-Backed Work
Consumption metrics are easy to fake. Views, clicks, prompts, impressions — all of them can be manufactured without anything useful being produced. The attention economy priced those signals because attention was the measurable primitive. The machine internet needs a different primitive: accountable action. In ZK-AI, demand means a machine event happened — context-bound, receipted, and verifiable. Not passive compute. Not idle presence. Not synthetic activity. A machine action that can answer: who requested it, what was allowed, what actually happened, and where is the receipt. Proof of Demand is generated at the edge, by operators near execution. The chain orders and finalizes. It does not generate the proof.
Machine action ZK-SNAP receipt produced at the edge
Valid receipt not demand
Receipt proves what happened. But without declared intent, authority, scope, and environment — it cannot be counted as verified demand.
Context-Bound receipt eligible demand
Context (intent + authority + scope + environment) is committed inside the claim via inputs_root. Now eligible for GAS metering, dePoD settlement, and program marks.
Context-Bound path →
ZK-AI Chain batch anchored
→
GAS metered Protocol Capacity
→
ZKAI settled demand fulfilled
Not counted as demand: raw compute idle participation passive emissions
Context
Context minimally captures intent, authority, scope, and environment. It lives in the committed claim or in an artifact root committed by the receipt.
CB
Context-Bound is an eligibility classification. It changes what can count as demand fulfillment and program-mark eligibility; it does not change base receipt validity.
PoD
Proof of Demand proves that context-valid demand existed and was fulfilled by a machine action within declared bounds.
dePoD
Distributed Edge Proof of Demand means PoD is produced near execution by operators or proof nodes, then Independently Verified and economically settled by Protocol Rules.
GAS
GAS is the Protocol Accounting Unit for anchor commits, chain resources, canonical EG ingest, and heavy shared evidence operations.
ZKAI
ZKAI is the intended settlement asset for Protocol GAS. Controlled private testnet meters fees under protocol rules before mainnet settlement goes live.
AW
Action Work is operator-local runtime effort such as tokens, seconds, memory, bandwidth, or device time. AW is not Protocol and must not appear on-chain.
No idle emissions
Passive presence is not demand. Protocol incentives are tied to metered Protocol Operations and demand-driven settlement, not passive holding.
Context-Bound Demand
A receipt might be structurally valid without being demand. It becomes context-bound when the claim commits to intent, authority, scope, and environment — making the accounting claim testable by verifiers.
Proof Is Not Consensus Weight
ZK-AI Chain orders anchors; receipts provide cryptographic accountability. Generating receipts may consume Protocol Capacity, but does not grant governance authority over chain rules.
Protocol economic model only — not financial advice and not an offer of securities or regulated instruments.
Public proof, private payloads
Public Recognition Is Not Public Disclosure
ZK-AI is a parallel accountability layer. Accountability and privacy stop conflicting the moment they live in separate layers. ZK-AI issues receipts about private events — payments, swaps, attestations, private chain transactions — without requiring those events to be publicly readable. The chain sees that a receipt was anchored. It never sees what the private payload contains. See the Protocol page for the selective disclosure model.
Sealed Commitments
Using the DoT-PRIV-01@v0 profile, sensitive fields in a claim are
replaced by PCOM-v1 commitment objects. A wallet or merchant can construct a claim
containing public context alongside cryptographic commitments to sensitive data.
The resulting inputs_root commits to the claim without leaking it.
The receipt can be safely anchored on ZK-AI Chain — proving the event happened
at a specific time, without exposing the details.
Selective Disclosure
In the event of an audit or dispute, the holder of the receipt can selectively
reveal commitment openings or specific evidence items (committed via
ext_evidence).
ZK-AI does not attempt to de-anonymize private chains. It gives operators the tools to prove their actions to authorized parties, using a standard, portable receipt primitive.
Local-First Verification
This privacy-first approach extends to verification tools. Proof Lab is designed so image bytes never leave your browser. The site only needs a fingerprint to create a demo receipt, not the image itself.