What it is
A minimal Proof-of-Authority anchor ledger for ordering batch-root commitments and exposing recognition records.
Protocol network
Chain, Discovery, and Economics Move Together
A receipt proves itself using mathematics. But mathematics alone doesn't make it findable six months later on a different platform — or governed as on-log evidence at a specific point in time. ZK-AI Chain adds the anchor path. The Evidence Graph adds the discovery layer. dePoD ties accounting to the work that actually happened. Three roles. One network.
ZK-AI Chain
A Governed Anchor Without a Data Dump
Receipt truth stays at ZK-SNAP. Ordering truth is on-chain. The 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.
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
Chain resource usage is metered in GAS. The protocol is pre-testnet today — controlled private testnet will exercise the same metering and anchor rules before mainnet settlement goes live.
Governance
Proof Infrastructure Needs Rules That Outlive Any One Platform
Most projects treat governance as an afterthought. ZK-AI does not. Receipt validity stays with ZK-SNAP mathematics. Chain recognition stays with a governed PoA ledger. Rule changes stay visible. Roles stay separated so no single party can both mint a receipt and rewrite the ledger that witnesses it.
Governance authorizes the meta-rules — validator allow-list, algorithm and profile registries, chain parameters, GAS schedule. It does not sign individual receipts or award trust to specific proofs. Validators sign blocks and accept anchor commits. Operators emit receipts and submit batches. Anyone can verify 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.
Visible rule changes
Governance decisions become chain-visible events and are mirrored publicly. The ledger rules are not edited through opaque dashboards.
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. Mainnet When It Holds.
This is not a rush-to-market chain. Machine actions happen everywhere — the network has to work at scale and keep working. Release is staged: harden the spec and verifiers first, run a controlled private testnet with real anchor mechanics and metering, then expand independent operators and validators before any public mainnet settlement.
Protocol economics are usage-metered — demand pays for anchors and evidence operations, not idle participation.
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. No rush to market — the network has to work at internet scale and keep working.
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 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 them.
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.
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 production. In ZK-AI, demand means a production 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.
Privacy-Adjacent Trust Layer
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 receipt contains. See the Protocol page for the technical surface model (PRS, PDS, OAS).
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 format.
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.