4. api-billing-v2 trust surface — review scope

Baseline: main @ f67bf83
Primary integration: billing_version: v2
Review goal: Validate cryptographic and operational claims for design-partner pilots and inform assurance roadmap.

---

In scope (please validate)

Area	Claim	Key files
Two-call surface	POST /api/vdi/billing/attest → bundle; POST /api/vdi/billing/verify → pass/fail	verifier-api/src/routes/vdi.js
Deterministic billing	Same meter + tariff → same billing_verify_fingerprint and charge	protocol/packages/vdi-billing/
Tamper rejection	Fingerprint, commitment, Phase-2 mismatches fail closed	billing-pilot.integration.test.js
Replay guard	Duplicate event_id per tenant/window rejected; crash-safe	DB migration 031; replay tests
Transparency	Append-only log head, checkpoint, consistency proof	transparency routes in vdi.js
Revocation feed	GET /.well-known/vdi-billing-revocation.json	well-known handler
Phase-2 binding	incircuit_binding_verification when VDI_BILLING_INCIRCUIT_BINDING=true	commitmentBindingV2.js, apiBillingV2.circom
Artifact integrity	Boot manifest validation; pinned sha256 for apiBillingV2	artifactValidator.js, ARTIFACT_MANIFEST.json
Meter trust	External meter_envelope + VDI_BILLING_METER_TRUST_JSON	meter verification in attest path
Offline verifier	Browser verify without API trust at dispute time	protocol/site/verify.html
Health endpoint	GET /health → JSON, environment: production	healthPayload.js
Strict profile	VDI_VERIFY_STRICT_V1 requires manifest authority + revocation	strict profile tests

---

Out of scope (do not block pilot on these)

Area	Notes
Landing page / marketing UI	Not part of billing trust surface
Legacy api-billing-v1	Deprecated path; pilot is v2 only
VDI identity / captcha circuits	Separate product (proof_of_identity, adaptive circuits)
Redis / rate-limit hardening	CI runs with Redis disabled
Stripe / invoice rails	Proof-of-charge, not payment capture
Formal SOC / prior audit	This review is technical scoping
Independent-host MPC ceremony	Documented limitation; path to adversarial trust
causalProof circuit ceremony	Billing binding uses apiBillingV2 only

---

Suggested review order

git fetch origin && git checkout f67bf83

# 1. Release gate
cd verifier-api && npm run test:billing-pilot   # 15/15

# 2. Core attest/verify path
#    verifier-api/src/routes/vdi.js — runApiBillingV2Attestation, billing verify handler

# 3. Phase-2 semantics
#    protocol/packages/vdi-billing/commitmentBindingV2.js
#    zk-cp/circuits/apiBillingV2.circom

# 4. Artifact governance
#    verifier-api/circuits/apiBillingV2/ARTIFACT_MANIFEST.json
#    verifier-api/src/utils/artifactValidator.js

# 5. Trusted setup story
#    protocol/docs/api-billing-v2-trusted-setup.md

# 6. Offline verifier parity
#    protocol/site/verify.html + browser tamper on /vdi-billing

---

Diff commands (scoped PRs)

# PR #8 — pilot hardening
git diff c5019b1^..cdee739 -- verifier-api/tests/billing-pilot.integration.test.js verifier-api/src/routes/vdi.js

# PR #9 — MPC artifacts
git diff cdee739..4a88f19 -- zk-cp/build/apiBillingV2 verifier-api/circuits/apiBillingV2

# f67bf83 — trust surface + health
git diff 4a88f19..f67bf83 -- src/pages/TrustPage.tsx verifier-api/src/utils/healthPayload.js

---

Reviewer questions

Answer pass / fail / N/A + notes.

Cryptography & circuits

1. Does apiBillingV2.circom correctly bind all eight public_commitments field-images into a single Poseidon8 public signal?
2. Is commitmentBindingV2.js verify logic sound (Groth16 + semantic digest equality)?
3. Can an issuer produce a valid Phase-2 proof for commitments that disagree with the meter/tariff fingerprint?
4. Are manifest pins sufficient to detect silent artifact substitution at deploy?

Protocol & API

1. Does replay guard prevent double-commit of the same event_id under crash + concurrency?
2. Does tampered billing_verify_fingerprint fail verify without breaking attestation signature checks?
3. Is transparency append + inclusion proof consistent with the claimed append-only model?
4. Does offline verify.html agree with /api/vdi/billing/verify for standard profile?

Operations & trust

1. Do test:billing-pilot cases cover the advertised pilot surface?
2. Is the MPC transcript consistent with on-disk zkey/vkey hashes?
3. Does production /health return documented JSON with environment: production?
4. What is missing before regulated billing disputes?
5. What is missing before design-partner pilot recommendation?

---

Track B — verifiable receipts (adjacent scope)

If time permits, Halborn may also skim the VDI receipt chain used alongside billing:

Component	Role
Ed25519 attestation signature	Issuer binding on decision object
Verification receipt	Cacheable downstream trust without ZK re-run
Transparency log	Append-only audit trail
Strict profile (VDI_VERIFY_STRICT_V1)	Manifest authority + revocation enforcement

Billing bundles embed VDI attestations; receipt verification reuses @quantzk/vdi-verifier. Full VDI stack: protocol/ARCHITECTURE.md.

---

Expected deliverables from Halborn

Item	Format
Scope ack	In-scope / out-of-scope confirmation or edits
Test run log	15/15 + optional smoke output
Findings	critical / high / medium / low / informational
§ questions above	Numbered responses
Pilot recommendation	One paragraph: go / no-go / go-with-caveats