Why Null Results Are Our Best Marketing
Updated 19 September 2026.
Ten Shor-style circuits for the elliptic-curve discrete logarithm (two full Shor circuits, eight hybrids where a classical step did most of the work), real IBM hardware, ten small prime-order curves, and a private key that appeared to come out the other end. That is the story we wrote first. The story that survived is different: the quantum data played no part in the answer, the key came from the classical half of the pipeline, and we retracted the claim in public on 15 May 2026. The second story is worth more, even if the first one had been true.
An earlier, shorter version of this note said the question had been pre-registered before the March 2026 hardware runs. It had not. That correction is part of the argument, so it goes first.
What we ran
Ten circuits, one per curve, over prime-order curves from 4-bit to 21-bit group orders. Twelve jobs in total, using up to 41 qubits. Eleven ran on ibm_fez, IBM's 156-qubit device; one ran on an older 133-qubit backend that has since been retired. Every job identifier is listed in our public job ledger. They are identifiers IBM issued to our account, a record we cannot edit, not a button a stranger can press.
One more correction belongs here. For the 6-bit and 8-bit curves, a bug in our code meant the hardware results were never read back, and the numbers we published for those two were computed on a local simulator. We found that in September 2026. The other eight curves are hardware results.
What we claimed, and what the data said
The original write-up said the runs recovered the correct private key, with a statistically significant peak in the measurement data. An outside article on a related subject sent us back to the raw histograms. In the hardware results, the correct key was sitting at the noise floor. The key that had come out of the pipeline was produced by the classical stage: for curves this small, direct classical enumeration finds it without any help. The quantum data played no causal role in the answer.
So the honest summary is not "the device recovered the key" and it is not "the device failed to recover the key" either. It is that the device's contribution was indistinguishable from noise, and the claim of a quantum recovery was withdrawn on 15 May 2026. Zero of the ten circuits support a quantum break.
The criterion we should have written first
The mistake was not in running the circuits. It was in deciding what counted as success after seeing the output. Three rules would have caught it before publication. We adopted them after the retraction, and they are the rules we follow now.
Write the null before the run. Not a flat null where every outcome is equally likely. A calibrated null: what this device produces on this circuit shape when there is nothing to find.
Write the success criterion before the run. For a key-recovery claim that means the correct key has to come out on top in the quantum data, by a margin over the calibrated null that was fixed before the first shot.
Remove the classical half and check what is left. If the answer survives with the quantum stage deleted, the quantum stage did not produce the answer. This is the test our original pipeline would have failed.
None of these are exotic. They are what any blinded experiment does. We had not done them, and now we write them down before the first shot is fired.
Why the null sells
A buyer of verification work is not buying our best day. They are buying what we do on our worst one. A published retraction, with the original claim left visible next to its correction, answers that question in a way no case study can.
There is a plainer reason too. A corrected claim has a floor. "Ten circuits executed on real hardware, every job listed, no quantum break" is a sentence a buyer can build on, because it was stated at the level the data supports and no lower. "Key recovered by a quantum device" had no floor. It could only go down, and it did.
What we do with nulls now
Every technical claim on this site is on a single claims page with one of four statuses: executed, corrected, unresolved, or reproduction. The Shor runs sit under corrected, with the original claim and the floor that replaced it. A separate result, a structured circuit measured against two control topologies, sits under unresolved, because a calibrated null could neither confirm nor fully refute it and we did not archive the per-bin data that would settle it. Saying "unresolved" in public is harder than saying "detected", and it is the only one of the two we can defend.
There is also a fixed procedure for overturning any claim on that page, published in advance, so that the next correction does not depend on how we feel about the result that day.
The null is the result we can stand behind longest. It was stated at the floor the data supports, and a floor has nowhere to fall.