Independent security review prep (QuantZK billing / receipt trust layer)

Audience: Halborn, NCC Group, Trail of Bits, or equivalent cryptography / application-security reviewers.
Goal: Raise the credibility ceiling from “we tested our protocol” to “an independent team reviewed these trust assumptions and attack surfaces.”
Stance: Prefer a review that finds issues you can fix over a magical zero-finding report.

60-second map (read this first)

End-to-end billing trust is five layers. Each answers a different question; do not collapse them.

1. Authority / preflight
   Signed spend authority evaluated and atomically consumed for a declared execution intent.
        ↓
2. Meter + billing
   After execution: authenticated meter evidence + deterministic charge calculation.
        ↓
3. QZR / verifier
   Authority, intent, committed billing facts, trust state, and receipt semantics reconciled.
        ↓
4. Phase-2 circuit
   Narrower subset actually bound through Groth16 (apiBillingV2 / Poseidon digest).
        ↓
5. Async issuance
   Postgres authoritative before HTTP 202; Redis/BullMQ is prove transport only; recovery from Postgres.

Layer	Question it answers	Primary docs / code
1. Authority / preflight	Was this spend allowed before execution, for this intent?	Charge authority Claims 1 & 4; POST /api/vdi/billing/authorize, preflight
2. Meter + billing	What ran, and what integer charge does the evaluator commit?	Meter envelope + tariff snapshot; fingerprint expected_charge_micros
3. QZR / verifier	Does the portable receipt bind grant, intent, charge, and trust checks?	QZR-1 Minimal / Standard / Strict; Claims 1–3
4. Phase-2 circuit	Which public commitments are cryptographically bound in-circuit?	Standard requires Phase-2; does not re-prove full tariff math
5. Async issuance	Can accept survive crashes without double-charge or lost jobs?	Async billing; replay guard + proof jobs in Postgres

Status reminder: QZR-1 overall is Candidate (not blind-implement frozen). Charge Authority v1 Claims 1–4 are frozen within that Candidate — see QZR-1 status block and freeze doc.

Claim map (frozen v1): Charge Authority v1 reviewer map.

Scope recommendation (narrow, billable wedge)

In scope:

1. api-billing-v2 issuance & verify (POST /api/vdi/billing/attest, async accept, POST /api/vdi/billing/verify)
2. Portable QZR-1 receipt offline verification path (@quantzk/vdi-billing/client, @quantzk/sdk, @quantzk/verify)
3. Replay uniqueness (tenant_id, billing_window_id, event_id) crash-safe reserve/commit
4. Async prove pipeline Postgres SoT, BullMQ as work queue only, leases + sweeper recovery
5. Meter trust anchors, commitment binding (Phase-1 / Phase-2), revocation feed semantics
6. Transparency log inclusion proofs (honesty assumptions of the log operator)

Out of scope (unless separately contracted):

• Full ZKCaptcha widget / age-verification product surface
• Broad “VDI for all machine decisions” roadmap
• Infrastructure hardening of Railway/Netlify accounts
• Social engineering / physical security

Explicit trust assumptions (ask reviewers to attack these)

Assumption	Failure mode if false
Ed25519 meter keys are controlled by the claimed meter operator	Forged usage events with valid envelopes
VDI_SIGNING_KEY is not exfiltrated	Issuer can mint arbitrary attestations
Groth16 verifying keys match published ceremony / manifest hashes	Soundness / binding break
Postgres is integrity-trusted for replay reserve	Double charge under partition if DB lied
Redis is not SoT	Queue loss must not drop accepted jobs (recovery story)
Revocation feed availability for Strict profiles	Stale “accepted” vs “currently good” confusion
Offline verify without revocation ≠ governance clearance	Reviewers should confirm messaging

Attack surfaces to prioritize

1. Fingerprint / charge malleability: can billed micros diverge from committed fingerprint while verify still passes?
2. Replay races: concurrent accepts, crash between reserve and job insert, mid-prove worker SIGKILL.
3. Async confusion: temporary receipt vs final attestation; webhook replay; lease steal; sweeper double-enqueue.
4. Profile downgrade: Standard vs Strict; missing revocation still “VALID” offline.
5. Commitment binding bypass: Phase-1 vs Phase-2; digest not constrained by public signals.
6. Meter kid / PEM mixups: wrong trust JSON; signature over non-canonical event.
7. Receipt portability: truncated .qzk, field drop, algorithm confusion in browser vs Node verifier.
8. Transparency: inclusion proof for wrong entry; log operator equivocation (document limitation).

Evidence pack (attach to engagement)

Item	Location
Pilot + trust chain	protocol/docs/api-billing-pilot.md
Async architecture + recovery	protocol/docs/api-billing-async.md
Live Railway smoke	protocol/docs/api-billing-async-live-smoke-evidence.md
Chaos evidence	protocol/docs/api-billing-async-chaos-evidence.md
Attack matrix	protocol/docs/billing-v2-attack-matrix.md
Formal audit methodology	protocol/docs/formal-security-audit.md
Binding model	protocol/docs/vdi-cryptographic-binding-model.md
QZR-1 draft	protocol/docs/qzr-1.md
§4.4 freeze evidence (pinned registry + vectors)	protocol/docs/qzr-1-section-4-4-freeze.md
Charge Authority v1 freeze (pins + reproduce)	protocol/docs/charge-authority-v1-freeze.md
Charge Authority v1 reviewer map	protocol/docs/charge-authority-v1-reviewer-map.md
Charge authority claims	protocol/docs/charge-authority.md
Adversarial / pilot CI	verifier-api npm run test:billing-pilot, test:billing-adversarial, test:billing-async-recovery
Committed-value + Claim 1 suites	protocol npm run test:committed-values, npm run test:sdk
Circuit artifacts + MPC transcript	verifier-api/circuits/apiBillingV2/

Suggested review questions (paste into SoW)

1. Under the stated trust model, can an adversarial meter operator or compromised API signing key be distinguished by verifiers?
2. Does async acceptance preserve “at most one final charge identity” per event key across worker and Redis failure?
3. Are offline and online verify paths equivalent for Standard profile on a complete QZR-1 receipt?
4. What is the precise security difference between historical validity and Strict+revocation “currently accepted”?
5. Which claims in public docs over-reach the cryptography?

Deliverables we want from the firm

• Written report with severity-rated findings
• Explicit residual risks / trust assumptions
• Confirmation or negation of double-charge and binding claims
• Optional: short public attestation letter suitable for design partners

Internal readiness checklist

• [ ] Freeze a git SHA + artifact hashes for the engagement
• [ ] Provide staging API + attest secret + sample .qzk corpus (valid + tampered)
• [ ] Point reviewers at revocation URL and transparency head
• [ ] Assign a single technical contact for finding triage
• [ ] Budget engineering time to fix findings before marketing the review

Positioning after the review

Preferred public sentence:

An independent security team reviewed QuantZK’s billing receipt trust assumptions and attack surfaces; findings were remediated and residual risks are documented.

Avoid:

Certified secure / unbreakable / zero-knowledge means no trust assumptions.

Assurance scope split (Halborn)

If the engagement is still upcoming, do not expand it into the entire Machine Spend Control product. Keep findings tagged by layer.

Frozen assurance scope (cryptographic / protocol)

Charge Authority v1
QZR semantics (§4.4 committed-value dominance)
cryptographic bindings
verifier behavior
meter / Phase-2 binding as contracted

Primary pins: charge-authority-v1-freeze.md, qzr-1-section-4-4-freeze.md, charge-authority-v1-reviewer-map.md.

New product / control-plane scope (optional add-on or separate SoW)

SpendPolicy
budget reservations
gateway (credential isolation, intent freeze, idempotency)
request binding
reconciliation (AUTHORIZED / EXPECTED / OBSERVED / BILLED)
ops UI /spend

Primary docs: machine-spend-control-plane.md, pilot-ready-v0.1.md.

How to classify findings

Finding class	Example	Implication
CA / QZR crypto	Fingerprint malleability; verify bypass	Protocol / frozen assurance defect
Control-plane / gateway	Reservation race; key leak in gateway logs; DENY not enforced	Product / deployment defect — not automatic CA failure
Messaging overclaim	Docs implying QZR proves no bypass	Documentation / Claim 4 integrity

Ask reviewers to label each finding as frozen-assurance vs control-plane-product so a gateway bug does not muddy Charge Authority v1, and a CA cryptographic bug is not filed merely as “gateway implementation.”