Research with frontier AI

Research with frontier AI

AI expands the set of research ideas Potomac can test. Frontier language models propose hypotheses and implement candidate circuits; deterministic evaluators measure them against explicit objectives; researchers decide what the results mean. Each iteration proposes a candidate, measures it, and records the outcome. Improvements are retained and failures inform the next experiment.


Case study

An accepted ECDSA.Fail submission

On 8 September 2026 the ECDSA.Fail challenge organizers accepted a submission by Ross Nkama, Potomac’s CTO, for the reversible secp256k1 point-addition circuit. His public submission note describes the method; the organizers’ validation commit records the accepted contribution. The steps below summarize the disclosed methodology without reproducing commands, seeds, prompts, or infrastructure details.

  1. Reproduce the baseline

    The prior frontier circuit was rebuilt and rerun in the official harness before any change, so that later improvements were measured against a reproduced number rather than a displayed one.

  2. Form a hypothesis and a tradeoff

    A mathematical hypothesis about the arithmetic identified where executed Toffoli count could fall, together with the constraint that peak qubit width must not rise.

  3. Explore with parallel research agents

    An agentic run using the MultiVM Labs research harness in an agentic coding environment dispatched parallel research subagents to explore and implement candidate changes.

  4. Test against evaluators

    Candidates were checked against explicit correctness evaluators and the benchmark’s resource accounting, and discarded when they failed either.

  5. Coordinate classical compute

    A GPU screening procedure written for the run, with checkpointing and reassignment after failed hosts, handled the classical search work the experiment needed.

  6. Repeat in a fresh environment

    The accepted configuration was rerun from a fresh clone of the official harness, and the evidence was retained with the submission.

ResultsPrior frontier baseline versus the accepted submission
MeasurePrior frontier baselineAccepted submission
Logical qubit width1,2601,260
Average executed Toffoli count, rounded904,049902,838
Score, Q multiplied by T1,139,101,7401,137,575,880

Prior frontier baseline versus the accepted submission, as displayed by the benchmark. The score uses the benchmark’s accounting and rounded displayed values.

The accepted change reduced the average executed Toffoli count by 1,211, from 904,049 to 902,838, at an unchanged logical qubit width of 1,260. Under the benchmark’s score, Q multiplied by T, that is an improvement of about 0.13 percent. The measure is gate count, not circuit depth.

Recorded where

Validation commit

Accepted on 8 September 2026. Submission 9e1ab6ad-c778-4d2f-8a04-16413677abf6 is recorded in the challenge repository.

Official validation commit (Layr-Labs/ecdsafail-challenge)
Community ranking

The community leaderboard listed Rossnkama third of 71 authors by best score when reviewed on 20 September 2026. Rankings change as new submissions are accepted.

Community author ranking for Rossnkama
Evaluator

The official harness that measured both the baseline and the submission.

Challenge repository and evaluator

Research workflow

Research workflow

One iteration

  1. Define a taskState the operation, operand size, correctness conditions, and resources to minimize.
  2. Propose candidatesModels suggest circuits, rewrites, or experiments within the constraints.
  3. Test correctnessEvaluators check every candidate against the specification; failures are discarded.
  4. Measure resourcesCount qubits, gates, and depth under the declared convention.
  5. Review and iterateResearchers judge what improved, why, and whether the task should change.
Each review defines the next task.
Models propose
Candidate circuits, transformations, and experiment designs.
Evaluators check
Correctness, resource counts, and reproducibility, automatically and deterministically.
Researchers decide
Which results are valid, which are worth pursuing, and how to report them.
Output
A verified improvement, or a documented reason the attempt failed.

Evaluation methods

Evaluation methods

Specification
Researchers define the task and its correctness conditions before any search begins.
Verification
Every candidate passes a deterministic check. Nothing counts because a model says it works.
Accounting
Resource counts follow a declared convention, so improvements are comparable and cannot be manufactured by changing the yardstick.
Baselines
Improvements are measured against a reproduced baseline, not a remembered or displayed one.
Interpretation
People decide whether a smaller circuit matters, what it costs elsewhere in the stack, and what to publish.

Research infrastructure

The research system being built

Potomac is developing research infrastructure that generalizes the workflow above beyond circuit design toward compilation, resource estimation, and hardware experiments. Its design is informed by the accepted submission and by the MultiVM Labs harness used to produce it.

The specification for that system covers explicit task contracts, parallel proposals, evidence-based review of competing claims, measured evaluation against declared objectives, recorded failures, bounded iteration, and reusable experiment records. These are design commitments for a system under construction; the case study above was produced with the earlier harness, not with the completed platform.

Explicit tasks
Every run starts from a written objective, constraints, and correctness conditions.
Parallel proposals
Several candidates are explored at once, and compared rather than accepted in the order they arrive.
Evidence-based review
Claims are normalized to evidence and cross-checked before they influence the next step.
Measured evaluation
Deterministic evaluators and declared accounting decide what counts as better.
Recorded failures
Negative results are kept so the same dead end is not explored twice.
Bounded iteration
Runs have budgets and stopping conditions, and end with a reusable record.

Frontier models

What frontier AI means here

Frontier language models are used as research instruments: they read the arithmetic, propose transformations, write and revise implementations, and explain what they changed. The contribution Potomac is building is the workflow around them, in which every proposal meets a deterministic evaluator, a declared accounting convention, and a researcher’s judgment before it counts.

The accepted submission was produced under a declared model label of the team’s own research harness. The question the company is pursuing is testable: whether model-assisted search, held to those checks, finds circuits and experiments that careful people would not have found as quickly.

The paper this contribution builds on