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 tool for KYC, age verification, supply-chain provenance, credential checks, and confidential ML. The bar is lower than it was three years ago. The tooling is real. The audit landscape is thinner than crypto, but it exists. This post covers six concrete non-crypto use cases Wavect has scoped or built, with cost bands, complexity ratings, and the honest Q&A about whether it is worth it for your team.

What does ZK actually solve for non-crypto products?

One sentence: prove a fact about private data without revealing the data. That maps to a surprising number of compliance and privacy problems regulators have been pushing harder since 2024. Age gates, EU residency checks, supply-chain provenance, credential verification, private ML inference. All of these used to be solved by handing over the underlying document or trusting a centralised attester. ZK gives you a third option.

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. zk-SNARKs over a verifiable credential signed by the user's government wallet or an attestation provider. Groth16 or PLONK depending on circuit complexity. The eIDAS 2.0 wallet roll-out across the EU is making the attestation side increasingly viable in 2026.

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 rules on age verification for adult content, gambling, and certain regulated content categories tightened in 2024 and 2025. Self-declaration is no longer compliant in several jurisdictions. Uploading a passport is a UX disaster and a 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 a ZK selective-disclosure proof. zk-SNARKs work well here. Standards like W3C VC and BBS+ signatures pair naturally.

Complexity. Medium. The standards are mature; the issuer side is the friction.

Cost band. 4 to 10 engineering weeks depending on issuer integrations.

Use case 5: Confidential ML inference

The problem. A user wants to run a model on private input and trust that the right model was used, without revealing the input to the model host or the model weights to the user.

The ZK tech that fits. zkML frameworks. This is the frontier of the list. Proof generation is heavy. Use cases where a 30-second to multi-minute proof is acceptable.

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. BBS+ signatures with selective disclosure, plus an optional ZK predicate proof for derived attributes. Works neatly with account abstraction wallets on the EVM side.

Complexity. Medium.

Cost band. 5 to 10 engineering weeks.

What does the cost picture look like across all six?

"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 you can hand off KYC to a regulated provider and you do not store the data yourself, you already have an acceptable answer for most jurisdictions. ZK becomes attractive when (a) you want repeated verifications without re-asking the user, (b) you operate in a jurisdiction where the eIDAS 2.0 wallet flow is live and users expect it, or (c) the cost of a breach of your KYC database is existential. If any of those apply, ZK pays for itself fast.

Q&A: how long does proof generation actually take?

Depends heavily on circuit size and prover. For small KYC-style circuits, proof generation runs in a few hundred milliseconds on a modern laptop or in the browser via wasm. For complex multi-attestation circuits, expect seconds. For zkML, expect tens of seconds to minutes. Verification is always cheap, typically sub-100ms. Plan UX around the prover side, not the verifier side.

Q&A: can a small team build this without a cryptographer?

For use cases 1, 2, 4, and 6, yes, with care. The tooling (Circom, Noir, Halo2, plonky2, recent zkVMs) has matured to the point that a strong senior engineer with a few weeks of focused ramp-up can ship a production circuit. For use cases 3 and 5, no. You want a cryptography specialist on the team or as an external reviewer, plus a proper external audit. We bring in domain specialists when needed. See our zero-knowledge service for how that works.

Q&A: what about account abstraction and ZK together?

Strong combination. AA wallets can verify ZK proofs on-chain or off-chain as part of their signature logic. That unlocks flows like "this wallet can only transact if a fresh age-verification proof is attached". For web3 products with regulated user bases, this is becoming a standard pattern in 2026.

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.