Frequently Asked Questions
General
What is QuantZK?
QuantZK is an open protocol for proving that AI and software decisions followed defined rules, without revealing the decision logic, input data, or internal state. Think of it as "TLS for decisions."
What problem does it solve?
When an AI makes a decision (loan approval, medical diagnosis, content moderation), stakeholders need to trust it followed the rules. Today, this requires either:
- Sharing proprietary model details (IP risk)
- Self-reported compliance logs (trust issue)
- Third-party audits of source code (expensive, point-in-time)
QuantZK replaces all of these with a mathematical proof that anyone can verify independently, offline, forever.
Is this a blockchain?
No. QuantZK is a pure cryptographic protocol. Attestations are portable JSON objects with embedded ZK proofs. No blockchain, no tokens, no consensus mechanism. The optional transparency log uses a Merkle tree (similar to Certificate Transparency), but it's not a blockchain.
What is a zero-knowledge proof?
A ZK proof lets you prove a statement is true without revealing why it's true. For example: "I can prove this loan decision didn't use the applicant's race as a factor, without showing you the applicant's data or the model's weights."
QuantZK uses Groth16 proofs on the bn128 elliptic curve, which are compact (~200 bytes) and fast to verify (~20ms).
Do I need QuantZK servers to verify?
No. Verification is completely offline. The verification key is embedded in every attestation. The verifier code is open source. You need nothing from QuantZK to verify an attestation.
What happens if QuantZK shuts down?
Every attestation ever generated continues to verify. The math doesn't change. The verification keys are embedded. The verifier is open source. This is the core design principle.
Technical
Which ZK proof system does QuantZK use?
Groth16 on the bn128 (BN254) elliptic curve, via snarkjs. Groth16 was chosen for:
- Constant-size proofs (~200 bytes)
- Fast verification (~20ms)
- Mature tooling (circom, snarkjs)
- Widely audited
What signature scheme is used?
Ed25519 (EdDSA on Curve25519) via @noble/ed25519. Ed25519 was chosen for:
- Deterministic signatures (no nonce reuse risk)
- 128-bit security level
- Compact signatures (64 bytes)
- Fast verification
How are private inputs protected?
Private inputs (credit scores, medical data, etc.) are used only during proof generation. They appear in the ZK circuit witness but never in the attestation output. The Groth16 proof proves statements about the inputs without revealing them.
What's the performance?
| Operation | Time |
|---|---|
| Proof generation | ~1-3s (depends on circuit size) |
| Full 7-step verification | ~27ms |
| Receipt verification | ~2ms |
| Receipt scoring | < 1ms |
Can I use this in the browser?
The verifier works in modern browsers (uses Web Crypto API with snarkjs). The prover requires Node.js because it needs filesystem access to circuit artifacts and uses heavy computation.
What Node.js version is required?
Node.js 18+ (for Web Crypto API compatibility and ESM support).
How large is an attestation?
Approximately 2-5KB as JSON, depending on the verification key size and number of public signals. The ZK proof itself is ~200 bytes.
Integration
How do I integrate with my existing AI pipeline?
- Install
@quantzk/attest - After your AI makes a decision, call
attest()with:- The pipeline definition (steps and constraints)
- The decision inputs (private, never revealed)
- The outcome
- Store or transmit the attestation
- Anyone can verify with
verify(attestation)
Can I define custom constraints?
Yes. Constraints are just objects with id, description, critical, and vertex fields. You can use the built-in manifests (Fair Lending, HIPAA, etc.) or define your own.
How do I add QuantZK to a microservice architecture?
- Attestation generation should happen in the service that makes the decision (it has the private inputs)
- Verification can happen anywhere, it only needs the attestation object
- Receipt storage can use any datastore (database, object storage, message queue)
- Transparency log can run as a sidecar or shared service
Can I use verification receipts with existing trust infrastructure?
Yes. Receipts are signed JSON objects. They can be:
- Stored in any database
- Transmitted over any protocol (HTTP, gRPC, message queues)
- Validated by any system that can verify Ed25519 signatures
- Used alongside existing PKI or OAuth systems
Compliance
Is QuantZK sufficient for regulatory compliance?
QuantZK provides cryptographic proof of process compliance. It proves your system followed defined rules, but it doesn't define what those rules should be. You still need:
- Legal review of your constraints (the built-in manifests are templates)
- A compliance team to define what "compliance" means for your context
- Operational controls around key management and verifier deployment
What regulations does QuantZK support?
Built-in constraint manifests exist for:
- Fair Lending Act / ECOA, Lending discrimination prevention
- EU AI Act Article 14, Human oversight of high-risk AI
- HIPAA Privacy Rule, Protected health information handling
- NIST AI RMF, AI risk management framework
Custom constraints can be created for any regulation.
Can regulators verify attestations independently?
Yes. That's the core value proposition. A regulator receives an attestation and verifies it offline using only the verify() function. They don't need access to your systems, your data, or your model. The math proves compliance.
How does this relate to AI auditing?
QuantZK complements traditional AI auditing:
- Traditional audit: Point-in-time review of code, data, and processes
- QuantZK: Continuous, per-decision cryptographic proof of compliance
An auditor can verify thousands of attestations in seconds instead of manually reviewing decision logs.
Architecture
Why is the verification key embedded in the attestation?
To ensure offline verifiability forever. If the key had to be fetched from a server, verification would break when the server goes down. Embedding the key makes each attestation fully self-contained.
Why use canonical JSON for signatures?
JSON serialization is non-deterministic (key ordering varies). Canonical JSON (RFC 8785-style) ensures the same attestation always produces the same bytes for signing and verification, regardless of platform or implementation.
Why 7 verification steps instead of just checking the ZK proof?
The ZK proof (step 5) is necessary but not sufficient. The other steps verify:
- The attestation is well-formed (schema)
- It hasn't expired (timestamps)
- The pipeline and policy hashes are valid (integrity)
- The signature is valid (authenticity)
- The verification key hasn't been swapped (key integrity)
Each step catches a different class of attack.
Why are verification receipts necessary?
ZK verification takes ~27ms. For a single verification, that's fine. For 1000 agents each verifying the same attestation, that's 27 seconds of redundant computation. Receipts let one agent verify and 999 agents trust the receipt (~2ms each = 2 seconds total).
What's the difference between verification profiles?
- Strict: All checks + requires formal authority (law firm, standards body). For regulated, high-stakes decisions.
- Standard: All checks + accepts self-attested authority. For general-purpose verification.
- Minimal: Schema + timestamps + ZK proof only. For performance-critical paths where policy checks are done elsewhere.