--- title: "Zero-Knowledge Outside Crypto" canonical: https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/ language: en description: "Six non-crypto zero-knowledge use cases: privacy-preserving KYC, age verification, supply chain provenance, private credentials, selective disclosure." image: "https://wavect.io/img/blog/headers/header_zero-knowledge-use-cases-outside-crypto.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 26 May 2026 Last reviewed August 7, 2026 [**Next**](/blog/account-abstraction-erc4337-production/) # Zero-Knowledge Proofs Outside Crypto: KYC, Age Verification, Supply Chain TL;DR Zero-knowledge proofs are a production option for selected KYC, age, credential, supply-chain, and verifiable-ML flows. Readiness depends on the issuer, proof statement, revocation model, target-device performance, and audit surface. The engineering-week bands are Wavect planning estimates, not benchmarks or fixed quotes. Reviewed against primary sources on 2026-08-07. [Zero-knowledge](/glossary/zero-knowledge/) is escaping the crypto sandbox. The technology that lets you prove a statement without revealing the underlying data is now a viable integration option for selected KYC, age-verification, supply-chain, credential, and verifiable-ML workflows. The tooling is real, but production readiness depends on the proof statement, credential source, target hardware, and audit surface. This post covers six concrete non-crypto use cases Wavect has scoped or built. The cost bands are Wavect planning estimates, not industry benchmarks or fixed quotes. ## What does ZK actually solve for non-crypto products? One sentence: prove a fact about private data without revealing all of the data. That maps to age gates, EU residency checks, supply-chain provenance, credential verification, and verifiable ML inference. These flows are often implemented by handing over the underlying document or trusting a centralized attester. ZK can add a third option when the issuer, proof statement, verifier, revocation path, and assurance level are well defined. ## Use case 1: Privacy-preserving KYC **The problem.** Your product needs to know a user is over 18 and an EU resident. It does not need to know their date of birth, street address, or passport number. Storing that data is a liability under GDPR and a tempting target for attackers. **The ZK tech that fits.** A selective-disclosure credential or a ZK proof over an attestation from a government wallet or another trusted issuer. The eIDAS 2.0 rollout is improving the attestation landscape in 2026, but supported formats, assurance levels, and national availability still vary. **Complexity.** Medium. The circuit is small. The integration with attestation providers is the real work. **Cost band.** Engineering weeks: 4 to 8 for a production integration. Verifier infra cost: negligible. Audit cost: separate engagement with a ZK-specialist firm. ## Use case 2: Age verification for regulated content **The problem.** EU institutions and several member states are moving toward stronger, privacy-preserving age assurance for regulated content. The legal standard and acceptable method depend on the service and jurisdiction, so a generic claim that self-declaration is unlawful everywhere would be wrong. Uploading a passport also creates avoidable UX and data-protection risk. **The ZK tech that fits.** A small circuit that proves "year of birth is on or before X" from a government-issued credential. zk-SNARKs are usually overkill here; a tightly-scoped circuit with a known attester gives you fast proofs and small verifiers. **Complexity.** Low to medium, mostly low once the attestation source is chosen. **Cost band.** 3 to 6 engineering weeks for a single-jurisdiction launch. ## Use case 3: Supply-chain provenance **The problem.** You need to prove your shipment passed through certified stages (origin, processing, shipping, customs) without revealing your specific suppliers, trade routes, or commercial terms to competitors or counterparties. **The ZK tech that fits.** zk-STARKs for transparency (no trusted setup) and post-quantum resistance, or recursive SNARKs if proof size matters more than prover time. Proofs are aggregated across stages; only the final verifier sees the result. **Complexity.** High. The hard part is the data model, not the cryptography. Getting suppliers to attest is the workstream. **Cost band.** 8 to 16 engineering weeks for a pilot covering one product line. ## Use case 4: Private credentials **The problem.** A platform wants to verify "this user holds a degree from an accredited university" or "this user is a licensed professional" without storing or revealing the full document. **The ZK tech that fits.** Verifiable Credentials plus selective disclosure, with a predicate proof when the relying party needs a derived fact rather than a disclosed field. W3C VC Data Model 2.0 is a Recommendation; the W3C BBS cryptosuite remained a Candidate Recommendation Draft in April 2026. **Complexity.** Medium. Issuer integration, revocation, wallet interoperability, and the maturity of the selected cryptosuite are the main friction points. **Cost band.** 4 to 10 engineering weeks depending on issuer integrations. ## Use case 5: Confidential ML inference **The problem.** A user wants evidence that a specified model produced an output. Input privacy and model-weight privacy are separate requirements that may need FHE, MPC, or a TEE in addition to a ZK proof. **The ZK tech that fits.** zkML frameworks for proof of inference. Vendor-reported systems now cover models including Llama-class variants, but latency, cost, supported operators, quantization, and security must be reproduced for the exact model. Do not assume one fixed 30-second or multi-minute range. **Complexity.** High. Honest framing: this is still bleeding edge in 2026. See our [bleeding-edge service](/services/bleeding-edge/) for how we approach this kind of risk. **Cost band.** 12 to 24 engineering weeks for a narrow vertical pilot. ## Use case 6: Decentralised identity selective disclosure **The problem.** A user has a wallet that holds several credentials. The relying party should learn only the specific attribute it needs (residency, profession, age bracket), nothing else. **The ZK tech that fits.** A supported selective-disclosure credential, potentially using a BBS-family scheme, plus a predicate proof for derived attributes. Account-abstraction wallets can help on EVM products, but they are not required for an off-chain credential flow. **Complexity.** Medium. **Cost band.** 5 to 10 engineering weeks. ## What does the planning picture look like across all six? The following engineering-week bands are Wavect scoping estimates for a narrow first release. They exclude third-party audit fees, issuer onboarding delays, certification, legal review, and production proving infrastructure. | Use case | ZK tech | Complexity | Eng weeks | | --- | --- | --- | --- | | Privacy-preserving KYC | SNARK + attestation | Medium | 4 to 8 | | Age verification | Scoped SNARK | Low to medium | 3 to 6 | | Supply-chain provenance | STARK or recursive SNARK | High | 8 to 16 | | Private credentials | SNARK + VC / BBS+ | Medium | 4 to 10 | | Confidential ML | zkML | High | 12 to 24 | | Selective disclosure | BBS+ + ZK predicate | Medium | 5 to 10 | ![Kevin Riedl](/img/team/kevin.webp) "ZK is finally becoming an integration tool, not a crypto-only research project." ## Q&A: is ZK overkill for KYC? For some teams, yes. If a regulated provider can perform KYC under an acceptable legal and data-processing model, ZK may add complexity without reducing your actual obligations. It becomes more attractive when you need repeated attribute checks without collecting the source document, when a compatible EUDI or issuer flow is available for the target users, or when minimizing stored identity data materially reduces risk. Model the issuer coverage, revocation, recovery, and fallback flow before claiming that ZK pays for itself. ## Q&A: how long does proof generation actually take? It depends on the circuit, proof system, implementation, hardware, memory, wrapper, and browser or native runtime. Published Mopro results range from hundreds of milliseconds to tens of seconds for proving, while some Halo2 verification measurements exceed 100 milliseconds and a large RSA circuit reaches seconds or fails on mobile memory limits. zkML ranges are even more model-specific. Benchmark the exact prover and verifier paths on target devices before designing the UX. ## Q&A: can a small team build this without a cryptographer? A small team can integrate an audited credential protocol or maintained SDK, but writing or materially changing a production circuit creates a different assurance burden. Recent soundness incidents show why a few weeks of ramp-up is not a substitute for protocol review, circuit testing, fuzzing, version pinning, and an independent audit. Supply-chain proofs and zkML also require domain specialists. See our [zero-knowledge service](/services/zero-knowledge/) for how we scope that work. ## Q&A: what about [account abstraction](/glossary/account-abstraction/) and ZK together? They can be combined. An account-abstraction wallet can require a fresh credential or ZK proof as part of its authorization policy, for example before a regulated action. That is a useful architecture pattern for some [web3](/glossary/web3/) products, but it is not yet a universal 2026 standard and it adds recovery, revocation, replay, privacy, and verifier-upgrade requirements. ## Q&A: do [smart contracts](/glossary/smart-contract/) need to be involved at all? No. ZK works fine entirely off-chain. A regular web2 backend can verify a SNARK or STARK with a small library. The chain is only needed if you want public, censorship-resistant verification or composability with on-chain logic. Most KYC and age-verification deployments we have scoped are pure off-chain. Go deeper: our [pragmatic guide to building with ZK and FHE](/blog/building-real-applications-zero-knowledge-fhe-2026/) covers the decision framework and failure modes, the [2026 ZK state-of-the-art post](/blog/zero-knowledge-proofs-production-2026/) carries current zkVM benchmarks and proving costs, and [ZK vs FHE vs MPC vs TEE](/blog/zk-vs-fhe-vs-mpc-vs-tee/) compares the alternatives. ## Sources and verification 1. European Commission (2026). European Digital Identity and the end-of-2026 wallet availability deadline. [commission.europa.eu](https://commission.europa.eu/topics/digital-economy-and-society/european-digital-identity_en) 2. European Commission (2026). EU age-verification blueprint and implementation status. [digital-strategy.ec.europa.eu](https://digital-strategy.ec.europa.eu/en/factpages/blueprint-age-verification-solution-help-protect-minors-online) 3. W3C (2025). Verifiable Credentials Data Model 2.0. [w3.org](https://www.w3.org/TR/vc-data-model-2.0/) 4. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. [w3.org](https://www.w3.org/TR/vc-di-bbs/) 5. Mopro (2026). Mobile and browser proof-generation and verification benchmarks. [zkmopro.org](https://zkmopro.org/docs/performance/) 6. Lagrange (2026). DeepProve open-source release and vendor-reported zkML results. [lagrange.dev](https://lagrange.dev/deepprove) ## Final thoughts Zero-knowledge is a production option for selected non-crypto integrations, especially small, well-scoped age, KYC, and credential statements backed by a trusted issuer. Supply-chain provenance and verifiable ML need more care because the data model, issuer guarantees, workload, and cryptographic assurance all matter. The decision is not simply whether to build now or later. Confirm the legal requirement, issuer coverage, proof statement, revocation model, target-device performance, and fallback path first. Integrate maintained and audited components where possible; if you write or change a circuit, budget for specialist review, fuzzing, and an independent audit. ## You may also like.. [**Building Real Applications With ZK and FHE in 2026: A Pragmatic Guide** The decision framework: when these technologies make sense, what they cost in 2026, and the five ways projects fail.](/blog/building-real-applications-zero-knowledge-fhe-2026/) [**Wavect vs a generalist dev agency** Generalists sell capacity; we sell product judgment plus the engineering to ship it.](/compare/wavect-vs-dev-agencies/) Privacy and cryptography ## Continue through this cluster Zero knowledge, FHE and privacy-preserving computation beyond the hype. [Start with the cornerstone**Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready**](/blog/zero-knowledge-proofs-production-2026/) - [zkTLS for AI Agents: Prove Web Data Without Exposing Secrets](/blog/zktls-ai-agents/) - [Building Real Applications With ZK and FHE in 2026: A Pragmatic Guide](/blog/building-real-applications-zero-knowledge-fhe-2026/) - [Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready](/blog/zero-knowledge-proofs-production-2026/) - [Fully Homomorphic Encryption in 2026: What Ships and What Is Still Hype](/blog/fully-homomorphic-encryption-practical-2026/) - [ZK vs FHE vs MPC vs TEE: How to Choose in 2026](/blog/zk-vs-fhe-vs-mpc-vs-tee/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 26 May 2026 Last reviewed August 7, 2026 [**Next**](/blog/account-abstraction-erc4337-production/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Zero-knowledge proofs are a production option for selected KYC, age, credential, supply-chain, and verifiable-ML flows. Readiness depends on the issuer, proof statement, revocation model, target-device performance, and audit surface. The engineering-week bands are Wavect planning estimates, not benchmarks or fixed quotes. Reviewed against primary sources on 2026-08-07.", "articleBody": " Blog overview/Web3 and privacy/Privacy and cryptography Zero-Knowledge Proofs Outside Crypto: KYC, Age Verification, Supply Chain TL;DR Zero-knowledge proofs are a production option for selected KYC, age, credential, supply-chain, and verifiable-ML flows. Readiness depends on the issuer, proof statement, revocation model, target-device performance, and audit surface. The engineering-week bands are Wavect planning estimates, not benchmarks or fixed quotes. Reviewed against primary sources on 2026-08-07. Zero-knowledge is escaping the crypto sandbox. The technology that lets you prove a statement without revealing the underlying data is now a viable integration option for selected KYC, age-verification, supply-chain, credential, and verifiable-ML workflows. The tooling is real, but production readiness depends on the proof statement, credential source, target hardware, and audit surface. This post covers six concrete non-crypto use cases Wavect has scoped or built. The cost bands are Wavect planning estimates, not industry benchmarks or fixed quotes. What does ZK actually solve for non-crypto products? One sentence: prove a fact about private data without revealing all of the data. That maps to age gates, EU residency checks, supply-chain provenance, credential verification, and verifiable ML inference. These flows are often implemented by handing over the underlying document or trusting a centralized attester. ZK can add a third option when the issuer, proof statement, verifier, revocation path, and assurance level are well defined. Use case 1: Privacy-preserving KYC The problem. Your product needs to know a user is over 18 and an EU resident. It does not need to know their date of birth, street address, or passport number. Storing that data is a liability under GDPR and a tempting target for attackers. The ZK tech that fits. A selective-disclosure credential or a ZK proof over an attestation from a government wallet or another trusted issuer. The eIDAS 2.0 rollout is improving the attestation landscape in 2026, but supported formats, assurance levels, and national availability still vary. Complexity. Medium. The circuit is small. The integration with attestation providers is the real work. Cost band. Engineering weeks: 4 to 8 for a production integration. Verifier infra cost: negligible. Audit cost: separate engagement with a ZK-specialist firm. Use case 2: Age verification for regulated content The problem. EU institutions and several member states are moving toward stronger, privacy-preserving age assurance for regulated content. The legal standard and acceptable method depend on the service and jurisdiction, so a generic claim that self-declaration is unlawful everywhere would be wrong. Uploading a passport also creates avoidable UX and data-protection risk. The ZK tech that fits. A small circuit that proves \"year of birth is on or before X\" from a government-issued credential. zk-SNARKs are usually overkill here; a tightly-scoped circuit with a known attester gives you fast proofs and small verifiers. Complexity. Low to medium, mostly low once the attestation source is chosen. Cost band. 3 to 6 engineering weeks for a single-jurisdiction launch. Use case 3: Supply-chain provenance The problem. You need to prove your shipment passed through certified stages (origin, processing, shipping, customs) without revealing your specific suppliers, trade routes, or commercial terms to competitors or counterparties. The ZK tech that fits. zk-STARKs for transparency (no trusted setup) and post-quantum resistance, or recursive SNARKs if proof size matters more than prover time. Proofs are aggregated across stages; only the final verifier sees the result. Complexity. High. The hard part is the data model, not the cryptography. Getting suppliers to attest is the workstream. Cost band. 8 to 16 engineering weeks for a pilot covering one product line. Use case 4: Private credentials The problem. A platform wants to verify \"this user holds a degree from an accredited university\" or \"this user is a licensed professional\" without storing or revealing the full document. The ZK tech that fits. Verifiable Credentials plus selective disclosure, with a predicate proof when the relying party needs a derived fact rather than a disclosed field. W3C VC Data Model 2.0 is a Recommendation; the W3C BBS cryptosuite remained a Candidate Recommendation Draft in April 2026. Complexity. Medium. Issuer integration, revocation, wallet interoperability, and the maturity of the selected cryptosuite are the main friction points. Cost band. 4 to 10 engineering weeks depending on issuer integrations. Use case 5: Confidential ML inference The problem. A user wants evidence that a specified model produced an output. Input privacy and model-weight privacy are separate requirements that may need FHE, MPC, or a TEE in addition to a ZK proof. The ZK tech that fits. zkML frameworks for proof of inference. Vendor-reported systems now cover models", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "commission.europa.eu", "url": "https://commission.europa.eu/topics/digital-economy-and-society/european-digital-identity_en" }, { "@type": "WebPage", "name": "digital-strategy.ec.europa.eu", "url": "https://digital-strategy.ec.europa.eu/en/factpages/blueprint-age-verification-solution-help-protect-minors-online" }, { "@type": "WebPage", "name": "w3.org", "url": "https://www.w3.org/TR/vc-data-model-2.0/" }, { "@type": "WebPage", "name": "w3.org", "url": "https://www.w3.org/TR/vc-di-bbs/" }, { "@type": "WebPage", "name": "zkmopro.org", "url": "https://zkmopro.org/docs/performance/" }, { "@type": "WebPage", "name": "lagrange.dev", "url": "https://lagrange.dev/deepprove" } ], "dateModified": "2026-08-07", "datePublished": "2026-05-26", "description": "Zero-knowledge proofs are a production option for selected KYC, age, credential, supply-chain, and verifiable-ML flows. Readiness depends on the issuer, proof statement, revocation model, target-device performance, and audit surface. The engineering-week bands are Wavect planning estimates, not benchmarks or fixed quotes. Reviewed against primary sources on 2026-08-07.", "headline": "Zero-Knowledge Outside Crypto", "image": "https://wavect.io/img/blog/headers/header_zero-knowledge-use-cases-outside-crypto.svg", "inLanguage": "en", "mainEntityOfPage": { "@id": "https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/", "wordCount": 1832 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/web3-privacy/", "name": "Web3 and privacy", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/privacy-cryptography/", "name": "Privacy and cryptography", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/zero-knowledge-use-cases-outside-crypto/", "name": "Zero-Knowledge Outside Crypto | ", "position": 5 } ] } ```