Zero-Knowledge Proofs Outside Crypto: KYC, Age Verification, Supply Chain

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 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.

"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 for how we scope that work.

Q&A: what about 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 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 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 covers the decision framework and failure modes, the 2026 ZK state-of-the-art post carries current zkVM benchmarks and proving costs, and 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
2. European Commission (2026). EU age-verification blueprint and implementation status. digital-strategy.ec.europa.eu
3. W3C (2025). Verifiable Credentials Data Model 2.0. w3.org
4. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
5. Mopro (2026). Mobile and browser proof-generation and verification benchmarks. zkmopro.org
6. Lagrange (2026). DeepProve open-source release and vendor-reported zkML results. lagrange.dev