How the entropy reservoir, health gating, cryptography layer, and audit pipeline are wired. Every draw is observable. Every response is reproducible.
fallback object on every responseSix layers back every draw. Three feed the API today (L2, L5, L6). Three remain on the internal calibration loop (L1, L3, L4).
X25519 + ML-KEM-1024 hybrid secure construction. FIPS 203 Category 5 (256-bit quantum security). AEAD via AES-256-GCM with 96-bit nonces. ML-DSA-65 signatures on provenance records (FIPS 204).
SP 800-90B Repetition Count Test (RCT) and Adaptive Proportion Test (APT) on every draw against a 1024-byte sample window. rct_passed / apt_passed boolean fields in the response.
State-tomography snapshots from the calibration loop. Used to characterize backend fidelity and validate admission thresholds. Not yet surfaced in the API.
State-transport fidelity tracking per channel on the calibration loop. Not yet surfaced in the API.
Hardware-derived entropy from IBM Quantum backends (Falcon, FEZ, Kingston, Brussels). Per-batch entropy_score admission threshold: ≥ 0.99. source_class enum in every response.
Engineered gate connectivity and backend-specific correlation metrics. Informs the hardware procurement cycle. Not yet surfaced in the API.
Every authenticated draw returns the same shape. Fields are stable across versions; additions are versioned.
Request body
{
"size_bytes": 32,
"tier": "standard"
}
Response body (real shape, abbreviated)
{
"entropy": "base64:...",
"size_bytes": 32,
"key_exchange": "X25519+ML-KEM-1024",
"source_class": "hardware-derived-premium",
"entropy_score": 0.999,
"source_id": "qrng-hardware-001",
"health_check": {
"rct_passed": true,
"apt_passed": true
},
"fallback": {
"is_fallback": false,
"reason": null,
"original_source": null
},
"provenance_id": "prov_2026_06_23_abc123",
"issued_at": "2026-06-23T14:22:08.117Z"
}
key_exchange — the hybrid KEM negotiated for this response (currently "X25519+ML-KEM-1024")source_class — enum: hardware-derived-premium | conditioned-archive-derived | hardware-derived | csprng-fallbackentropy_score — float, admission threshold ≥ 0.99source_id — opaque backend identifier (e.g. qrng-hardware-001)health_check.rct_passed / health_check.apt_passed — booleans, SP 800-90B gatingfallback — nested object, never flat. is_fallback: false on a normal draw; is_fallback: true with a reason code when CSPRNG fallback engagedprovenance_id — opaque record key for GET /v1/audit/:idFive sequential stages from raw hardware output to signed API response. Each stage gates the next; failure at any stage is observable.
Raw measurement output from IBM Quantum backends. Per-batch min-entropy estimated against the conditioning circuit. Pool byte-age cap: 14 days.
entropy_score ≥ 0.99 required for admission. Min unique states per batch: 8,192. Below threshold → batch is rejected, never admitted to reservoir.
SP 800-90B RCT and APT run on a rolling 1024-byte sample window. Failed tests force fallback regardless of entropy_score.
Admitted bytes buffer in the edge layer. Pool threshold: ≥ 1 MB (MIN_POOL_THRESHOLD = 1024 * 1024). Consumption cap: 90% per draw (MAX_BATCH_CONSUMPTION = 0.90).
Authenticated draw returns entropy bytes + signed provenance record. KV (90-day operational) + R2 (7-year persistent) audit chain attached.
Fallback is explicit and customer-visible. The fallback.is_fallback field is true only when one of these checks fails — never silently.
Reservoir must hold at least 1 MB plus the requested draw. Failure → reason: "pool_unavailable".
entropy_score of the candidate batch must be ≥ 0.99. Failure → reason: "entropy_score_below_threshold".
RCT and APT must both pass on a 1024-byte sample. Failure of either → reason: "health_tests_failed:RCT,APT" (or whichever test failed).
If any check fails, the response is still issued — with bytes from the documented CSPRNG fallback path and the nested fallback object populated. The original requested source and the failure reason are both preserved in fallback.reason and fallback.original_source.
Every draw produces two records: an operational telemetry record (KV) and a permanent compliance record (R2). Both share the same provenance_id.
Cloudflare KV · 90-day rolling TTL
Cloudflare R2 JSONL · 7-year retention
End-to-end latency budget for a normal draw at the edge.
| Stage | Component | Typical |
|---|---|---|
| 1 | TLS + auth verification (Cloudflare edge) | 5–10 ms |
| 2 | Pool byte extraction (KV-backed) | <1 ms |
| 3 | NIST RCT/APT on 1024-byte sample | 2–5 ms |
| 4 | Hybrid KEM encapsulation (X25519 + ML-KEM-1024) | 1–3 ms |
| 5 | Provenance record construction + signature | 3–6 ms |
| 6 | KV write (operational) + R2 append (persistent) | 5–15 ms |
| 7 | Response serialization + edge return | <1 ms |
| Total | Edge P50 | <30 ms |
| Total | Edge P95 | <50 ms |
The service is delivered via Cloudflare Workers at 300+ edge locations. No infrastructure to manage; no warm-up; no provisioned capacity.
Edge runtime at 300+ global POPs. Sub-50ms P95 latency.
Operational audit record. 90-day TTL.
Persistent audit log. 7-year retention.
Sandbox keys provisioned within 24–48 hours. Same response shape, same audit chain, capped volume.