# Privacy / ZK ### What privacy means on EDMA We keep evidence provable and people private. Facts that move money are public as hashes (PoV hash, burn hash, Locked→Unlocked deltas); sensitive documents and PII stay in role-gated vaults with signed URLs and redaction commitments. Where a program needs to “see enough without seeing everything,” we add zero-knowledge proofs (ZK) so the Gate can check a statement without revealing the raw value. Two laws never change: the dossier must still pass the checklist, and money never moves early—No EMT, no funds. ### Privacy model Evidence files (COAs, BL + seal photo, temp logs) live off-chain; the chain anchors hashes. The canonical dossier omits any PII the schema marks as redactable and commits to a salted hash instead. Authorized parties fetch files via short-lived signed URLs; auditors can verify redactions offline with the salt. For fields that don’t need raw disclosure, the submitter can attach a ZK proof that a condition holds (e.g., “temperature stayed between 2–8 °C” or “shelf-life ≥ 180 days”) while binding the proof to the same PoV hash the Gate is evaluating. * **On-chain:** PoV hash, EMT ids, Locked→Unlocked EDSD deltas, fee & EDM burn lines, One-Claim updates. * **Off-chain:** PDFs/photos/CSVs/EDI + signed URLs; redaction salts in a Salt Vault (KMS/HSM). * **Commitments:** sha256(file\_bytes) for files; sha256(canonical\_json\_bytes) for the dossier; salted redaction hashes for PII. * **Access:** role-based; every fetch is audit-logged; no files in webhooks. ### What ZK is for here ZK proves statements about data without showing the data. It never replaces PoV and never overrides the schema. * **Range:** “temperature ∈ \[2,8] °C” over a Merkle-committed log. * **Threshold / inequality:** “shelf-life ≥ 180 days” computed from redacted MFG/EXP dates. * **Membership / region:** “origin ∈ {CN-Anhui, CN-Shanghai}”, “route ∈ approved corridors”. * **Format / checksum:** “serial conforms to program checksum and set X”. * **Aggregate:** “≤ 1% carton damage” from a blinded count vector. * **Identity-light:** “KYC passed & not on sanctions list” via a third-party verifiable credential. ZK is not for suppressing required documents, bypassing attestor roles, or weakening One-Claim. If the schema says the BL and seal photo/number are required, you provide them; ZK can add checks, not remove them. ### How ZK plugs into the Gate 1. **Bind:** the proof statement references the PoV hash (sha256 of canonical bytes) and the specific schema field(s). 2. **Verify:** On-chain verification for succinct circuits (range/membership). The schema lists the verifying-key hash; the Gate calls the verifier precompile/library. Attested verification for heavy circuits (large Merkle logs). The Inspector/Temperature-OEM verifies off-chain and signs a role attestation that includes the proof hash; the Gate counts that signature via the Attestor Registry. 3. **Decide:** the Gate enforces the same checklist: quorum, equality, freshness, One-Claim, must-fund. A ZK pass simply satisfies fields the schema marked as “zk-acceptable”. Performance rule: if verifying on-chain would make the business clock miss seconds-level targets, we use attested verification and keep the PoV hash as the anchor. ### Supported statements * temp\_in\_range(root, interval, min, max) — Merkle root + inclusion proofs. * shelf\_life\_ge(mfg\_hash, exp\_hash, min\_days) — redacted dates + salted commitments. * origin\_in\_set(code, set\_root) — set membership via Merkle/accumulator. * serial\_in\_program(serial\_hash, program\_root) — checksum + set membership. * kyc\_ok(vc\_hash, issuer\_key) — verifiable-credential signature (no personal data). If a statement isn’t in the schema, it doesn’t count toward PASS. ### Governance knobs * Approve statement templates, publish verifying-key hashes, set max proof age, and designate attesting roles for off-chain verification. * Rotate verifying keys with a timelock; anchor new hashes in the schema registry. * Set gas/latency budgets for on-chain verification; if a proof exceeds, the Gate rejects with E\_ZK\_BUDGET\_EXCEEDED. * Foundations unchanged: No EMT, no funds, One-Claim, must-fund, 50% burn. ### Developer surface * **GET /v1/zk/statements:** discover templates and verifying-key hashes per schema. * **POST /v1/zk/proofs:** submit { statement\_id, pov\_hash, proof\_bytes | attestor\_sig }; receive a proof\_id. * **POST /v1/trade/proof/{order}/{stage} or /v1/tokens/mint|settle:** reference proof\_id for fields marked “zk-acceptable”. **Errors:** E\_ZK\_BAD\_BINDING — proof not bound to this pov\_hash/schema. E\_ZK\_VERIFY\_FAIL — invalid proof/signature. E\_ZK\_STALE — proof older than allowed window. E\_ZK\_BUDGET\_EXCEEDED — exceeds on-chain gas/latency limit (use attested mode). * Show “ZK-verified” chips next to fields; link to the statement template. * Never show raw values when a ZK statement satisfied the field. ### Privacy recipes * Cold-chain: commit the full temp log as a Merkle root; prove each segment was in range. Public sees “in range” and the root; regulators can fetch segments by inclusion proof. * Shelf-life: redact MFG/EXP; prove “≥ 180 days” and bind to the PoV hash. * Brand auth: brand issues a signed auth VC; schema accepts kyc\_ok-style proof from the brand key—no letters uploaded publicly. * Route membership: origin/port codes proven against an allowlist accumulator; no need to disclose intermediate nodes. ### Security & pitfalls * Mis-binding: every proof must include the PoV hash; otherwise, it can be replayed. * Key drift: verifying-key hashes pinned in schemas; rotations timelocked and visible in the Explorer. * Over-use: don’t “ZK everything.” Only fields the schema marks as zk-acceptable should use it; everything else remains explicit files + hashes. * Attested verification trust: when proofs are verified off-chain, the attesting role and its SLA/bond carry accountability; governance can slash/rotate. ### Compliance mapping * GDPR/PII: keep PII off-chain; use redactions + salted commitments; ZK to prove relationships without disclosure. * Audit: proof pages link the PoV hash, statement ids, verifying-key hashes, and (when used) attestor signatures. Auditors can re-verify with the same code and keys. * Export controls/sanctions: kyc\_ok-style proofs keep documents private while proving status from a trusted issuer. ### Plain recap {% hint style="info" %} Privacy on EDMA is “hashes public, files private, proofs selective.” Canonical JSON + PoV hash anchor the dossier; redactions and salts keep PII out; ZK statements let the Gate check what matters (“in range”, “≥ X”, “in set”) without seeing the numbers. Governance approves the statements and keys, but never the settlement law. Payments still follow facts: **PASS → EMT → Locked→Unlocked EDSD → fee → 50% burn**—and until PASS is real, nothing moves. {% endhint %}