"The customer is over 18." "Company turnover exceeds €50M." "The subject is not on a sanctions list." Provyn ZK gives a regulator, a partner or a smart contract a cryptographically verifiable yes / no - with no copy of an ID, a financial statement, or a list. The source data never leaves your boundary.
When a counterparty asks you to "confirm the customer is over 18", they don't want a copy of an ID. They want a proof. A copy of the ID is a liability to them: it puts them in compliance scope too.
Zero-knowledge proofs let you prove a statement about data without revealing the data itself. Provyn ZK packages this cryptography into a set of ready-made "circuits" - standard checks like "age ≥ N", "resident ≥ N days", "balance in a range", "ID belongs to a list" - called like an ordinary REST API. A 192-byte proof, verified in 12 ms, over any transport.
Circuits are mathematically verified and audited. They are invoked by an API call with a name and parameters. Entities reference records in the vault.
Each sees exactly as much as they should - and nothing more. Mathematics, not contracts.
This is what's sent to the verifier. This is all they receive from you. In the dashboard - the same object plus audit metadata.
curl -X POST https://api.provyn.cloud/v1/zk/prove \
-H "Authorization: Bearer $PROVYN_KEY" \
-d '{
"circuit": "age_over",
"subject_ref": "tok_01HXZP…",
"public": { "threshold": 18 }
}'
circuit=age_over · threshold=18 · result=true
$ provyn-verify --vkey age_over.vkey proof.bin [✓] proof format ok [✓] pairing check ok [✓] public input binding ok PROOF VALID verified locally in 11.4 ms no outbound traffic
We don't ask you to write circom. Ready circuits with clear parameters - like calling an SDK function. Every version is signed, logged, and backward-compatible.
Not "someday in Web3" but now - inside fintech, marketplaces and healthtech.
The customer verifies their age once through a national eID in the vault. On every order the marketplace receives a proof age_over(18) = true - without a date of birth. The courier never sees an ID in the app. The regulator sees nothing in the logs but the fact of a check.
A correspondent bank requires proof the customer is not on a sanctions list. Handing over a name is a leak plus a cross-border transfer. Instead: a proof merkle_exclusion(id, sanctions_root). The public root is maintained by the regulator. On the counterparty's side - 13 ms verify and a checkmark in the compliance report.
An insurer must not see a diagnosis - it's a special category of PII. But it needs to know: "is the case covered by the policy". The clinic builds a proof diagnosis_in_coverage(policy_terms). The insurer gets covered = true/false. No one learns the person is ill.
A tender platform requires "turnover ≥ €50M" and "professional-body membership". Instead of submitting financial statements and certificates - two proofs: financial_threshold (auditor-signed) + merkle_inclusion(registry). The platform sees the company qualifies; it never sees the financials.
No exotic stack. BN254 / BLS12-381, Groth16 / Plonk, Circom 2. Everything that has been audited inside and out.
| Scheme | Groth16 (BN254) · Plonk (BN254) · Halo2 (BN254) - your choice |
| Curves | BN254 · BLS12-381 · secp256k1 (for on-chain) |
| DSL | Circom 2 · Noir · halo2-lib |
| Proof size | 192 B (Groth16) · ~450 B (Plonk) |
| Prove time | 140-420 ms on a typical circuit (16-vCPU prover pod) |
| Verify time | 10-14 ms · offline · with no call to Provyn |
| Trusted setup | Perpetual Powers of Tau (phase 1) + per-circuit phase 2 ceremony |
| On-chain | Ethereum · Polygon · Base · Arbitrum |
| SDK | JS (browser-prover · WASM 4MB) · Python · Go · Rust |
| Ceremony log | Public ceremony log, signed, reproducible |
| Compliance | Cryptography - standard, audited elliptic curves; PII - handled at the vault layer |
If your question isn't here, email sales@provyn.cloud.
Cryptography. The verifier checks pairing relations on the BN254 elliptic curve - with no call to Provyn. If the prover doesn't know the real private inputs, they cannot construct a valid pair (A, B); the probability of forgery is 2⁻¹²⁸ (practically zero). It's the same maths that secures Ethereum snark-rollups.
Ideally, no. The verifier is a plain binary with a clear output: PROOF VALID. We ship it with a digital signature, documentation and an independent audit report. In practice, a fact with a checkmark in a compliance report is all the counterparty needs.
Yes. The verifier checks pairing equations locally with no network calls, so the same proof verifies identically in the EU, GCC, APAC or LATAM. For deployments with a formal national-cryptography requirement, we wrap the proof in an additional signature layer using a locally approved algorithm, so a "national signature → inner ZK proof" chain satisfies the formal requirement.
The per-circuit phase-2 ceremony is a multi-party MPC involving Provyn, the client and independent auditors. As long as at least one participant honestly deleted their toxic contribution, the setup is sound. Ceremony logs are published. Plonk uses a universal phase-1 (Perpetual Powers of Tau, 120+ participants) - so new circuits need no separate ceremony at all.
That's why every library circuit passes an internal audit + external review (Zellic / OpenZeppelin). Custom circuits are the same, review included in the price. Formal verification on the critical paths (range checks, merkle-depth bounds).
Yes. @provyn/zk-prover is a WASM package (~4 MB), proving in the browser in 1-3 s. For mobile - native modules for iOS/Android. Chrome, Safari, Firefox - all current, all WebAssembly-compatible.
By number of generated proofs and number of circuits. Library circuits from a few cents per proof at typical volumes. A custom circuit is a one-off build plus operation. PoC - a free tier of 10k proofs/month.
30 minutes with a cryptographer. We take your typical compliance scenario (age, sanctions, turnover), show the right circuit and the verifier output on real data.