QStrike known gaps
What QStrike Doesn’t Have Yet
We publish what we don’t yet have. Honesty is part of the methodology.
Why we publish gaps
Honest scope is a buyer benefit
Most security vendors maintain a marketing posture that asserts capability uniformly. The post-quantum cryptography category is too young and too consequential for that posture. We’re explicit about what’s bounded, what’s pending, and what’s deliberately out of scope.
Buyers benefit from knowing the boundary; we benefit from not over-promising; the field benefits from honest comparison. A gap published is a gap a buyer can plan around. A gap hidden is a surprise during deployment.
The list below is the public-safe view of the engineering KNOWN_GAPS.md maintained in the qstrike-engine repository. Every item is a real boundary we’ve accepted, not aspirational language softened into a roadmap.
Capability boundaries
Gaps as honest scope
Public-safe QStrike platform boundaries are named, dated by status, and closed only when we ship the work.
Bounded-N Shor’s algorithm
status: hardware-boundedToday QStrike runs Shor’s at N=15, N=21, and N=143 (25-qubit implementation) on calibrated provider profiles. These prove algorithm correctness; they do not break production-strength keys. Larger Shor-N requires hardware QStrike does not yet have access to — when it becomes available, we will integrate it.
No real-customer engagement bundles in the public surface
status: by-designQStrike’s representative engagement bundle uses fictional-illustrative entities (Acme Bank, etc.) clearly labeled as such. Real-customer engagements run under SOW with confidentiality controls and are not in the public surface. As anonymized engagements complete, we publish what’s permitted.
Per-bundle attestation chain in flight
status: next-releaseToday, every SSE event envelope is signed ECDSA-P256-SHA256 — verifiable per-event via /qstrike/verify. The per-bundle attestation chain (engine code hash + per-provider job IDs + calibration snapshots, all cryptographically chained) is shipping in the next release. Until then, per-event signing is the verifiable surface.
qstrike-verify CLI not yet on npm
status: next-releaseA reference Python verifier (verify_gates.py) and a copy-paste openssl flow at /qstrike/verify are available today. The npm-published CLI (@qtonicquantum/qstrike-verify) is shipping in the next release alongside the per-bundle attestation chain (they pair).
Synthetic uptime measurement scaffolded, not yet deployed
status: pending-deployOur SLO target for /api/health is 99.9 percent on a 30-day rolling window. The synthetic monitor that produces measured numbers is scaffolded in ops/synthetic-monitor/ but not yet deployed to Cloudflare Workers. Once deployed, measured uptime will be published at /trust/slo.json and surfaced on /status.
Provider workload mix is honest, not aspirational
status: by-designToday’s typical engagement workload mix is approximately 92 percent Intelligence Model reasoning plus 8 percent quantum-cloud-executed cryptanalytic probing. Real-hardware execution scales with engagement scope. We don’t claim "all 8 providers run on every engagement" because that’s not how the work is structured.
Xanadu (photonic) integration inactive
status: inactiveThe public QStrike execution set is six commercial cloud-accessible platforms across four modalities. Published-benchmark calibration inputs are tracked separately and do not run customer workloads.
Engagement timeline 30 to 120 days, not "minutes"
status: by-designBAS tools execute in minutes; QStrike engagements span 30 to 120 days because the capture window is days-to-weeks by design. Our "real-time" claim is per-finding signed proof within minutes of validation completion — not engagement initiation.
Explicitly out of scope
What we will not publish
These are not gaps that will close on a schedule. They are claims we will not make on a public marketing surface, by policy.
Specific live customer names
Until SOW plus explicit permission. Anonymized engagement summaries are published as they become permitted.
Specific RSA-2048 break demonstrations
The hardware that would make this an honest claim does not exist commercially as of June 2026. We will not stage a misleading demonstration.
"ML-DSA signed" claims about today’s production signing path
We sign with ECDSA-P256-SHA256 today. ML-DSA migration follows the published CNSA 2.0 sequence and is not deployed on the production signing path.
Dollar-figure performance guarantees on a public marketing page
Until legal ships an underwriting attestation. No public dollar-figure guarantee, full stop.
How this list updates
Living document, signed evidence
- Updated as engagements complete and gaps close. Every change to a status line on this page is tied to a shipping event in the engineering repository.
- Source of truth for the underlying detail is the engineering KNOWN_GAPS.md in the qstrike-engine repository. This page reflects the public-safe view.
- Subscribe via /contact for change notifications. We will email when a status line moves from pending or in-flight to shipped.
- Methodology pairs with this page. The QStrike methodology describes what the platform does today; this page describes what it does not yet do.
If a competing vendor publishes a similar list, the field improves. If they don’t, you have a comparison surface they declined to provide.
Be notified when gaps close
Leave an address below to be notified as items on this page move from in-flight to shipped. We’ll also send a note when a new boundary is added — disclosure flows both directions.
Prefer to read the methodology first? /qstrike/methodology