WarpSpeed Discovers Record-Breaking ECDSA Cracking Circuit

‍

In March, Google Quantum AI announced breakthrough results: state-of-the-art small quantum circuits capable of cracking the public-key cryptography behind Bitcoin and Ethereum.

A couple of months ago, Eigen Labs turned that paper into a public benchmark, ecdsa.fail. It is a very active competition, where the state-of-the-art models compete in order to find the most efficient circuit for this same task.

We pointed our expert-intelligence AI system, WarpSpeed, at this challenge. It produced a quantum circuit that is 2.5× more efficient than Google's. Our circuit also beats every submission on the ecdsa.fail benchmark by a wide margin. Its improvement over the top leaderboard submission is about two and a half orders of magnitude larger than the median improvement on the benchmark over the last month. Our system achieved these results through self-improvement.

Alongside this post, as part of our responsible disclosure of these results, we are releasing a zero-knowledge proof. It certifies the existence of our quantum circuit and its cost, without revealing the circuit itself. We are not publishing our circuit to ecdsa.fail, since all submissions to the benchmark are automatically made public.

Separately from these algorithmic results, our agents also audited the benchmark's verifiers, and found gaps combining cryptography, performance engineering, and software security, all in one.

The Spacetime Pareto

In a quantum circuit, gates (time) and qubits (space) trade off against one another. These concepts are explained in detail in the next section. In the map below, we place all relevant circuits in terms of their space-time cost.

At the top right you can see the initial circuit which is supplied as part of the benchmark. Its spacetime cost is 10.76 × 10⁹ Toffoli-qubits. In blue we have Google's two designs: one aiming to minimise space, and another aiming to minimise time. Both sit well below the benchmark’s initial circuit, with costs of 3.17 and 2.99 × 10⁹, respectively.

In orange you can see the result of two months of public competition, with competitors running the strongest available models, including GPT 5.6 SOL and Claude Opus 5, using Codex and Claude Code respectively. The best leaderboard score is presently 1.49 × 10⁹. Finally, in green you have WarpSpeed's circuit, consisting of only 993,181 Toffoli gates and 1,205 qubits, for a total of 1.20 × 10⁹ in spacetime score.[1] Those are the figures the proof certifies.

The two researchers at doubleAI working on this project (which only took a few days) are not themselves experts in quantum computing. So, they had to leave all of the heavy lifting to WarpSpeed. How did WarpSpeed get there? Before we dive in, let’s take a brief moment for exposition.

Crash course in Quantum Circuits and Elliptic Curves

TL;DR: Bitcoin and Ethereum protect “coins” using digital signatures. Spending requires proving you hold a secret key, through the ECDSA scheme over the elliptic curve secp256k1. It’s well known that a large enough quantum computer could break this by running Shor's algorithm, which reconstructs the private key from the public one.[2]  To make sure we’re all up to speed, what follows is a very brief (3 minute read) explanation of these topics, assuming no prior knowledge.[3]

Elliptic curves. An elliptic curve is a smooth curve on which any two points can be combined to produce a third, through an operation conventionally written as addition. This operation can be chained, so you can take a fixed “base point” and add it to itself any number of times.

In ECDSA, the private key is a secret whole number, and the public key is the point you reach by adding the base point to itself that many times. The additions are cheap, so computing the public key from the private one is fast. However the reverse, working out how many times the base point was added when all you are given is the final point, is the elliptic-curve discrete logarithm problem, and for our curve (secp256k1) it is commonly assumed that no classical computer can solve it in any feasible time. This asymmetry is what is relied upon in order to keep (say) Bitcoins safe.

What is a quantum circuit? A quantum circuit stores its information on qubits and computes by passing them through a sequence of reversible steps, called gates. The result is read, at the end, through what is known as a measurement step.

A register of n qubits is a superposition of all 2ⁿ n-bit binary strings, i.e., a linear combination of all of them, with a complex amplitude αₓ on each. A measurement returns a single value x with probability |αₓ|² (and collapses the register to that value!). All quantum circuit gates are linear, so a gate applied to a superposition acts on every term of it at once. What Shor's algorithm (and every other quantum algorithm) does is delicately shape the amplitudes so that the terms leading to wrong answers cancel and the ones leading to the right answer add. That is known as interference, and how much of the intended state a real circuit actually produces is its fidelity.

Another key detail is that a quantum computer cannot throw information away. Every gate is reversible (formally, it is a unitary matrix, which is of course invertible). This means that whatever the circuit writes down, it still has at the end. The scratch registers a circuit borrows along the way (its ancillas) are part of the superposition as well. Therefore, once an ancilla holds something that differs from one branch to the next, the branches themselves differ, and branches that differ cannot cancel (!). Every ancilla therefore has to be put back to zero before the measurement happens, so that interference may happen. That is called uncomputing, and it incurs an additional computational cost[4].

Pricing Shor’s Algorithm. A quantum computer can break schemes like ECDSA, through Shor’s algorithm. When you trace where the work in Shor's algorithm actually goes, almost all of it comes from one modest step (repeated a great many times): adding two points on the curve. Google's construction, for example, performs 28 of these additions. The cost of the entire attack therefore rides on the cost of a single point addition. Thus, this is also the operation that the ecdsa.fail benchmark revolves around, and asks that one make cheaper.

There’s one last key detail. For Shor’s algorithm to work, the addition operation need not be exact. That is, the algorithm still succeeds even if the addition circuit is correct only on, say, 99% of its inputs, and wrong on the rest.[5] The reason is that in Shor's algorithm (like many quantum algorithms) the circuit is applied to all pairs of points in superposition, and the result is derived using the way those branches interfere with one another at the end. Thus, a slightly wrong circuit only costs fidelity instead of producing a wrong result, and if the error fraction is small enough all you will have lost is a little of the probability that a run of the algorithm ends in the private key (which you buy back by running it again).[6]

Space-time cost. A circuit is priced on two components: space, i.e., the qubits it holds, and time, meaning, the gates it runs. However, not all gates are equal. For reasons relating to error correction and fault tolerant quantum computation, all gates can be assumed to be “free” except for the Toffoli, which is an AND-like gate (it flips its target when both of its controls are 1 and has to be assembled from separately distilled states).

The product of Toffolis × Qubits (colloquially, the space-time cost) is the standard way to price a fault-tolerant quantum circuit.[7] Google's paper reports its circuits this way, as does ecdsa.fail, and much of the related literature.[8] And so do we.

WarpSpeed’s Circuit

Exploration and self-improvement

One important aspect of WarpSpeed is exploration in the space of ideas. For the ECDSA challenge, rather than work only on the original problem — creating an approximate point addition circuit — WarpSpeed worked across three diversified ‘related’ tasks:

• An exact point addition circuit.
• An approximate circuit with a strict soundness parameter.
• An approximate circuit with a loose soundness parameter.

It experimented, ablated and collaborated on and across these three tasks. This is part of its self-improvement capabilities: the more it runs against a given domain or set of tasks, the better its performance. Its agents read papers, and shared ideas, circuits, tools, and the dead ends with one another. One of the main challenges here is guaranteeing that the shared learnings are indeed both correct and helpful. This is enforced, in part, through ablation studies. Proven-useful results are made freely available to subsequent runs.

Another useful feature is automatic routing. Tasks are sent to models that best suit them. For instance, proving lower bounds on multiplicative complexity (a purely mathematical task) would often be routed to a Fable-based worker.[9] In contrast, collating a wave of algorithmic suggestions into something coherent, deciding what has been superseded and what merely looks similar, would often be tackled by an Opus worker.

All in all, this process was not expensive. For calibration, Eigen Labs spent around \$10,000 in tokens to produce the benchmark's initial results, whereas WarpSpeed's entire run, end to end, cost less than $5,000.

Picking a good starting point

Another important detail is what the workers start from. In the benchmark, each submission is made public and available to future contenders. This includes the initial ‘starting point’, i.e., the circuit from which the competition itself started. That circuit, and the methodology that has grown up around it, encourages overfitting.

As it happens, the initial circuit was an already-approximate one, which fixes several non-trivial (and far from optimal) algorithmic decisions. Since the circuit is already “wrong” (has phase errors), small algorithmic changes to it typically cause large accumulation of error, and thus prevent true exploration.

Rather than inherit an algorithmic design and risk overfitting to it, WarpSpeed wrote its own naive (actually correct) point addition. That circuit is as simple as it gets: it computes the chord formula directly, with a full-width modular inverse. Consequently, every piece later removed from it is a deliberate decision, opening the path for true exploration, and cleaner ablation studies.

The benchmark’s verifier

The benchmark’s verifier takes a circuit and tries to judge whether it is an “approximately correct point addition” or not. To this end, it simulates the circuit on 9,024 test inputs and checks three things on every test case: (a) that the output point is correct, (b) that no “phase” has been left accumulated, and (c) that every ancilla came back to zero.[10]

Why test 9,024 random inputs? And how does that capture approximate correctness?

The answer lies in Google’s paper. Google's difficulty was that they weren’t ready to make their circuit publicly available, yet they still wanted its cost figures believed. Thus, they published what’s known as a zero-knowledge proof, a certificate that can convince a stranger of a property of the circuit without revealing the circuit itself.

Google’s proof had to establish that their circuit returns the right sum on at least 99% of its inputs. A common way of doing so is to use the Fiat–Shamir heuristic. In short, the circuit is hashed, and the digest then determines the test inputs. Since the circuit’s author cannot predict the digest before fixing the circuit, they cannot tailor a circuit to the test inputs. Google (and therefore also the benchmark) chose to implement the heuristic using the SHAKE256 extendable-output function (XOF). Choosing n = 9,024 with this construction allows one to prove that a circuit is correct on >99% of inputs, with 128-bits of cryptographic security. [11] [12]

This is not wrong, per se, but it fails to separate concerns. As mentioned above, Fiat–Shamir is part of the verifier, which fuses together two problems which ought to stay apart. The algorithmic task is to build an approximate point addition at a given soundness parameter. That is not what the verifier scores. It scores a circuit against the particular 9,024 inputs that the circuit’s own bytes happen to select (through the random seed).

This opens a second, easier but much narrower route to a good score (one that has nothing to do with point addition): leave the circuit exactly as it is, and go after the seed instead. This is what has been occurring on the benchmark for the last few weeks. Because the seed is a hash of the serialised gates, a tiny no-op edit “re-rolls” it while leaving both what the circuit computes and what it costs untouched. Therefore, a slightly broken circuit can be re-rolled again and again until one roll happens to draw 9,024 inputs it passes. More on this later.

WarpSpeed's verifiers

WarpSpeed wrote its own verifiers rather than rely on those provided by the benchmark.

To do so, it introduced a parameter, λ: the expected number of bad outputs in a batch of 9,024 random i.i.d. tests. Varying λ yields the different variants on which WarpSpeed’s agents were tested.[13]

λ is estimated statistically. The verifier replays the candidate over a large corpus of i.i.d. draws, counts the bad outcomes, and scales: if \(f\) of \(N\) inputs fail, then \(\lambda = 9024 \cdot \frac{f}{N} \). Since the draws are independent, \(f\) is binomial and by standard tail bounds, the probability of being off by more than \(\varepsilon\) decays like \(e^{-2N\varepsilon^2}\). WarpSpeed’s verifier also records which inputs failed, which turned out to be quite a useful debugging tool.

For sufficient statistical power (enough draws that the expected number of failures, \(Np\), is itself large, and the relative error on \(\hat{p}\) falls as \(1/\sqrt{Np}\), not \(1/\sqrt{N}\)), \(N\) has to be quite large. It turns out that a million random inputs suffice.

Wouldn’t simulating 1M random inputs for every submission be slow? Naively, it would be. However, this is where WarpSpeed used its performance engineering know-how. It rewrote the verifier’s simulator.

The benchmark’s own simulator is already bit-sliced, allowing it to run 64 inputs “concurrently”. WarpSpeed wrote a bit-exact re-implementation of this simulator, that carries 512 inputs at once (eight 64-input sub-batches, one per 64-bit lane of a 512-bit AVX-512 word), using AVX. This resulted in eight times fewer passes, each moving a fifth of the bytes. It also did the same for the SHAKE256 hash. This, together with concurrency, yielded a two-orders of magnitude reduction in the running time of the simulator, allowing 1M random inputs to be trivially checked in seconds[14].

It’s also worth noting that for the exact point addition circuit, simply setting λ=0 is not enough. There could still always be some inputs on which the circuit errs. In this case, WarpSpeed, used a co-evolution tactic: it iteratively generated exact addition circuits, and then adversarially ‘attacked them’, resulting in improvements to its verifier. This led to the inclusion of many interesting corner-cases, such as coordinate differences that are exact powers of two, differences within a few units of the field prime \(p\), and Fibonacci-ratio pairs (the worst case inputs for, say, a binary GCD). Importantly, random sampling would never have found these on its own.[15]

Lastly, we reiterate once again that in WarpSpeed’s verifiers, there is no mention of Fiat–Shamir, and the seeds are not a function of the circuit.[16] This removes the agents’ incentive to “grind” seeds and overfit.

The result: WarpSpeed Took A Different Algorithmic Approach

The leaderboard's circuits and ours compute the same thing: the slope of the chord through the two points, and then the two output coordinates. Formally, given points \(P = (x_1, y_1)\) and \(Q = (x_2, y_2)\), their sum \(R = (x_3, y_3)\) is obtained by taking the slope \(s = (y_2 - y_1)/(x_2 - x_1)\), and then letting \(x_3 = s^2 - x_1 - x_2\) and \(y_3 = s(x_1 - x_3) - y_1\) (where here every operation is carried out mod \(p\)).

However, the way in which they do so is fundamentally different. Almost all of the Toffoli cost (time) is the modular inverse (\((x_2 - x_1)^{-1}\)) inside that slope. The leaderboard computes it with a truncated unrolled variant of the circuit from a paper due to Schrottenloher. In contrast, WarpSpeed uses a variant of a Kaliski almost-inverse (curiously, the benchmark’s initial circuit also used Kaliski, in a different variant, but contenders quickly pivoted away from that). In so doing, WarpSpeed found ways to rebuild the arithmetic that inversion is made of, including reductions that exploit the shape of secp256k1’s prime, and reductions from modular doubling into cheaper operations.

The different algorithmic choice exposed new “levers” for the soundness of its circuit. In our circuit, the error budget goes almost entirely into the Kaliski inversion, by controlling how many iterations it runs, how wide its operands may be, and how far its comparisons look.

GPU Performance Engineering meets ECDSA

How does one get from a circuit with a given λ parameter, to a circuit that passes the benchmark’s Fiat-Shamir based verifier?

Recall that the benchmark derives its 9,024 test inputs by hashing the “op stream” (flattening of the circuit) that one submits. In theory, nothing stops you appending free (non-Toffoli) gates that compute nothing at all — and since the hash is computed over the whole circuit, this will result in the seed getting “re-rolled”. So the idea is straightforward, simply append a series of gates corresponding to the identity at the end of the circuit. The leaderboard calls this a tail nonce.

All submissions on the leaderboard use this same “trick”. Since grinding the nonce is embarrassingly parallel, many of them simply offload this naive search to a large fleet of CPUs, as their published submission notes describe in some detail (often using up to 20K CPUs). Their CPU fleet of thousands of cores runs an in-memory seed grinder, at roughly 5,200 seeds a second.

With per-input failure rate \(p\) and \(n = 9{,}024\), a seed is clean with probability \((1-p)^n \approx e^{-\lambda}\), so the number of seeds you must try grows as \(e^{\lambda}\). The current leaderboard head sits at \(\lambda \approx 19.7\), which puts a clean seed at roughly one in \(3 \times 10^8\) and a 90%-confidence search at \(8.3 \times 10^8\) nonces. At 5,200 seeds a second, that comes out at about 44 hours of their entire fleet, for just one submission.

This is all woefully inefficient. Let’s make it faster.

Precompute the head of the hash. The nonce touches only the last 96 ops, so the SHAKE state after absorbing everything before them is the same for every trial.[17]

While this pre-computation buys some speedup, it is not where the bottleneck lies. Even if the hash were free, we are still paying, per nonce, for 9,024 elliptic-curve scalar multiplications and a full simulation of a million-gate circuit. This is where most of the time goes, so let’s take a closer look.

Early Exit. Most nonces fail, and they do so for reasons that are visible long before the simulator has finished. So, rather than perform a full simulation, we opt for two separate stages: a fast “screening” stage, followed by a full simulation of the remaining candidates.

How do we screen? This is tightly coupled to the algorithmic choices behind our family of circuits. A circuit in this family fails for reasons relating to our choice of truncation: an operand in the division grows wider than the schedule allotted it, or a comparison window is too narrow to decide. Crucially, whether a given input trips one of those conditions is a property of that input’s field elements rather than of the quantum state, so it can be settled with a handful of modular operations instead of a full replay (!). The screen evaluates those conditions across the divisions and abandons a nonce the moment one of them fails.

It’s worth noting that for screening, over-detection is exponentially fatal, whereas under-detection is only linear. That is, a screen that misses real failures costs a constant factor in throughput, but a screen that fires on an input the circuit actually gets right raises \(p\) itself, and \(p\) sits in the exponent: a spurious rate of one in 9,024 costs a factor of \(e\) in expected search time.

Screening quickly on the GPU. WarpSpeed wrote a single fused kernel to perform the screening. It takes a nonce, re-absorbs the tail block as mentioned above, and expands the seed into candidate inputs. These inputs are kept in projective coordinates so that one shared inversion serves a handful of field elements. These are then evaluated against the truncation conditions, input by input, abandoning the nonce the moment one of them fails. A GPU warp advances a fixed window of candidates in lockstep and refills it in aggregate, so no lane sits idle waiting for its neighbours. There are many other small performance improvements inherent in the code, mostly related to better L2-cache usage.

Putting all of this together, our accelerated seed grinding code is able to go through 56K seeds per second per GPU versus slightly less than 1000 for the full simulation, a 56.8× speedup on the same hardware.[18]

Our optimised seed grinder runs some 500× faster than the incumbents' fleet, which is worth \(\ln 500 \approx 6.2\) extra units of \(\lambda\). Put concretely, a day of their fleet buys a circuit at about \(\lambda = 19\), whereas a day of ours buys \(\lambda = 25.3\). This allows for some score improvements, although we note that increasing \(\lambda\) from 19 to 23 only improved WarpSpeed’s score marginally. Importantly, even at the same error rate as the incumbents’, WarpSpeed reached an 18% lower spacetime score.

In fact, you don't need a circuit at all…

We also sent our agents to audit the verification harness itself. There, they found something interesting: a way to bypass the verifier outright and hand the benchmark any score they liked, with no circuit at all.[19] This is reminiscent of the same class of harness hack we wrote about in SOL-ExecBench.

This time, the trick lives in the linker. The harness is one Rust crate compiled into two programs; an untrusted build_circuit, which runs the contestant's code inside a locked-down sandbox, and a trusted eval_circuit, which reads the circuit back, simulates it, and writes the score. Due to security considerations, the benchmark’s verifier enforced a clear security boundary:  eval_circuit deliberately does not import the contestant's module, so that contestant code never runs within the trusted process.

But… It runs regardless. A module can carry a function that fires before main does, such as a constructor registered in the program's startup table. By putting one in the contestant's module, and because the linker folds the whole crate into both programs, that constructor is present in eval_circuit too. The instant the trusted binary starts, the constructor runs first. It can then do as it pleases (including, say, writing a perfect score to disk, and exiting before the verifier has executed a single line). The sandbox, in other words, had been wrapped around the wrong process.

Evals are becoming much harder to guard. It is becoming ever more apparent that as agents grow in capabilities, they also become increasingly difficult to contain, and defending against agents is not the same as defending against human beings. Sandbox escapes are not hypothetical, either: in just the past few weeks, agents from OpenAI and Anthropic have been reported breaking out of their own sandboxes. This underscores the need for strong verifiers that can withstand powerful agents, something we at doubleAI specialise in.

‍