1. One-page overview

QuantZK · Verifiable API billing (api-billing-v2)
Baseline: main @ f67bf83 · Live: api.quantzk.com

---

What it is

QuantZK turns a metered API event into a cryptographically verifiable charge bundle in two HTTP calls. A customer or auditor can re-verify the bundle offline without trusting QuantZK logs at dispute time.

POST /api/vdi/billing/attest  →  signed bundle (meter + tariff + charge + receipt + optional Groth16 proof)
POST /api/vdi/billing/verify  →  pass/fail + billing_check + incircuit_binding_verification

Binding version: bn128-poseidon8-v1 (Groth16 over Poseidon8 hash of eight public commitment field-images).

---

Why Halborn is reviewing

Two parallel assurance tracks:

Track	Focus	Primary artifacts
A. api-billing-v2	Billing integrity: deterministic charge, replay guard, Phase-2 in-circuit binding, artifact governance	vdi.js, commitmentBindingV2.js, apiBillingV2.circom, MPC manifest
B. Verifiable receipts	VDI attestation + receipt chain in the broader assurance stack	Ed25519 signatures, transparency log, offline verify.html, strict profile

This packet scopes Track A as the pilot-critical path. Track B shares crypto primitives (Groth16, Ed25519) but uses separate identity/compliance circuits.

---

What we claim (validate or refute)

1. Same meter + tariff → same billing_verify_fingerprint and charge (deterministic).
2. Tampered fingerprint, commitments, or Phase-2 proof → verify fails closed.
3. Duplicate event_id per tenant/window → replay guard rejects (crash-safe).
4. Production bundles include MPC-backed billing_proof when VDI_BILLING_INCIRCUIT_BINDING=true.
5. Boot-time manifest validation detects silent artifact substitution.
6. Browser offline verifier agrees with API verify for standard profile.

---

Release gates (reproducible)

Gate	Command	Expected
Billing pilot	npm run test:billing-pilot (see packet index)	15/15
Artifact validator	validateArtifacts() on boot	12/12 manifest match
Production health	curl https://api.quantzk.com/health	"environment":"production"
Production smoke	scripts/smoke-billing-phase2.sh	attest + verify pass; tamper fails

---

Known limitations (disclosed upfront)

1. MPC Phase-2 used 3 contributors on one machine — architecture is sound; adversarial Groth16 trust needs independent-host ceremony before regulated billing disputes.
2. Phase-2 binding is opt-in via VDI_BILLING_INCIRCUIT_BINDING=true (enabled in production).
3. Warm attest budget is 8s CI ceiling, not an SLO.
4. Legacy api-billing-v1 remains in codebase; pilot is v2 only.
5. No formal SOC / prior third-party audit on this surface yet.

---

Key hashes (apiBillingV2)

Artifact	SHA-256
apiBillingV2_0001.zkey	13a088cce212b26e774dfaa8808f4ec77b739fdfa5da1213f4b8bd21e6315cc8
billing_proof.vkey_hash (canonical; smoke pin)	a486fb22805a60df7608e70a2939c178c2b12d9e84a4b94152c98e4859815bcf
MPC transcript	a5cbaaba16d77f56533f74ef12a138f1d5931b9ad4b46e7fffc1536344a46af8

Full table: verifier-api/circuits/apiBillingV2/ARTIFACT_MANIFEST.json

---

What we need back

• Pass/fail on scope table (§4 trust surface doc)
• Findings: critical / high / medium / low / informational
• Explicit answer: safe for design-partner pilot? Safe for regulated billing? (expected: pilot yes with caveats; regulated needs independent MPC + formal audit)
• Optional: re-run smoke + paste terminal log

Contact: Omar@quantzk.com · Trust index: quantzk.com/trust