A public search you can join, on a problem from 1997.

RhoNet's first public round is Exercise 97: Certicom's ECCp-97 challenge, the real curve, about 4.2 × 1014 elliptic-curve steps. It was first solved in 1998 by 588 people over 53 days. Every step you contribute is verified by replay, and the board says so in your name.

Volunteer computing has existed since SETI@home, and it has never been able to pay a stranger, because nobody could check what a stranger submitted. That is the part we built: work is verified by replaying a segment of it, so contribution is a fact rather than a claim, and a prize can be split by rule instead of by trust. Exercise 97 has no prize — it has a known answer, which is the point. Next is ECCp-131, unsolved, $20,000, open since 1997.

Join the search See the board

Status: opening. The coordinator is not serving yet, so the round cannot be joined today. What is published is everything needed to be ready for it: the curve and its provenance, every round parameter with its reasoning, the wire specification, and conformance vectors a client can check itself against before it ever connects. This line, and the board below, become live figures the moment the coordinator answers.

Round
exercise-97
Progress
opening
Network rate
steps/s
Contributors
Verification cost
0.006%of search

Leaderboard

identities verified on github · hardware self-reported

public-demo · solved

48-bit curve · 11,401 points · 8 epochs · notional pool, no funds held
#ContributorCreditsSharePointsSegments replayed
01 raullenchaiApple M3 Ultra · 4 worker processes 19.000 5,1104,863 ✓
02 claudeApple M3 Ultra · 2 worker processes 18.152 4,8904,646 ✓
unregistered key ae1e757e… disqualifieda point it submitted did not replay 0.000 00 ✓
unregistered key 612349ce… disqualifiedforged, and filtered its work to dodge the audit 0.000 00 ✓
Shown until Exercise 97 opens: the last completed round, a 48-bit curve run on one machine. The two registered accounts appear by their GitHub login because each opened a pull request binding that account to its key; the two forgers registered nothing, so they are shown as keys and never as somebody's account. Hardware is self-reported by the walker, not measured. Every epoch's audit is published and re-derived in CI: public/epochs. The pool was notional; nobody has been paid.

Join

bring a machine, or bring a faster client

The reference client is slow on purpose. Beating it is part of the work.

The coordinator verifies a submission by replaying a segment of the walk against the round specification. It has no opinion about how you produced it. So the Python client below is a reference implementation: it defines what correct means, not what fast means. It does 0.7–0.8 million steps per second per core, and there is no scenario in which that is a good number. Anyone is welcome to write a faster one, in any language, on any hardware, and every step it earns counts the same.

# clone, install, register a github identity, walk
# (until the round opens the last command exits immediately, saying so;
#  it checks the coordinator before spending anything on a ticket)
git clone https://github.com/iotexproject/rhonet && cd rhonet
python3 -m venv .venv && .venv/bin/pip install fastapi 'uvicorn[standard]' cryptography httpx
.venv/bin/python -m tools.contributor sign --github <you> --key walker.key \
    --payout 0x<your address> > contributors/<you>.json   # then open a PR
.venv/bin/python -m rhonet.walker --coordinator https://api.rhonet.dev \
    --payout 0x<your address> --procs 8

# or run the whole system yourself: a fresh curve, a coordinator, three
# honest contributors and two forgers, solved and settled in about two minutes
./demo.sh

Full walkthrough: docs/JOIN.md. Your first run mints an admission ticket — about 230 steps of the same walk the search is made of, twenty minutes on one core and under three on eight. That cost is what stops a thousand fresh identities from farming quota, and because it is the same kernel, a faster client mints tickets faster in exactly the proportion that it searches faster.

What a client has to get right

Derive its start points from the round and its own public key, follow the adding walk, submit distinguished points with a Merkle commitment to its checkpoint chain, sign the batch, and open a challenged segment on request. Nothing else is prescribed. The arithmetic, the batching, the memory layout and the hardware are yours. docs/PROTOCOL.md

How you know yours is correct

Conformance vectors, published and checked in CI against the reference implementation: for a fixed round and a fixed test key, thirty-two consecutive walk states with their branch indices, a complete walk with its checkpoint chain and Merkle root, three segment openings, and the exact signed bytes of every message type. Run them and you know before you join. spec/vectors.json

How the competition is scored

The board shows the hardware alongside the credit, so a faster implementation is visible as well as credited. There is no approval step and no whitelist: a client is legitimate if its points replay, checked the same way for everyone, including us. If the standing record is still Python, the round is telling you something.

Verification

why a stranger should believe any of this

The prize is locked before the first step

Funds sit in a contract, not an organizer's account. Abort is a condition, not a decision: a deadline, coordinator silence, or somebody else solving it first, each provable on chain, each callable by anyone, and each sponsor recovers their own deposit.

The coordinator issues no work

Start points come from the round and your public key, so anyone can recompute anyone's walk from public data. There is no secret assignment to trust and no seed server to fail.

The audit is published, not just performed

Each epoch commits to a beacon before it opens and reveals it after auditing, together with the candidate set and exactly which segments were replayed. A third party re-derives the selection and checks it was not steered; our own CI does it on every push.

The chain checks the answer

Settlement is gated on an on-chain reveal that verifies the discrete logarithm against the round's curve. The vault does not take the operator's word that the round was won.

Sampling beats proving

Proving every elliptic-curve step in zero knowledge costs orders of magnitude more than the work it proves. Replaying an unpredictable sample, and forfeiting on failure, is the honest verifier for this problem.

The failures are public too

An external review found four critical and six high-severity defects. A second, adversarial review of the repair found more. Every one, with its reproduction and its fix, is in the repository.

Targets

the same walk, the same credit, the same vault
TargetExpected stepsPrize1,000 GPUsStatus
Certicom ECCp-974.2e14solved 1998 by 588 volunteers~10 sopening
Certicom ECCp-1093.2e16solved 2002 by 10,308 volunteers over 549 days~13 minafter the first fast client
Certicom ECCp-1316.5e19$20,000, open since 1997~19 daysfirst public round
Bitcoin puzzle #1401.7e2114 BTC, bearer~480 daysneeds a kangaroo walk
Certicom ECCp-1634.3e24$30,000~3,400 yearsout of reach

The order is deliberate: 97 is the largest instance the reference client can actually finish, so it opens before any kernel exists. 109 is not a record to redo — it is the only rung between 1014 and 1019, and that is where the coordinator's decimal-text record format has to stop being decimal text, ahead of the 1010 points a 131-bit round produces. It is also where a negation map gets validated in the real kernel at real scale. The constant itself is cheaper to check than that: a broken negation map does not crash and does not change throughput, it only silently costs the 1.41× it was meant to buy, and 300 independent 40-bit solves pin the mean to ±2.8%, against a 29% shift — ten sigma, in forty-six seconds on one machine. So the arithmetic can be caught long before 109; what 109 buys is everything that only appears at scale. Those GPU figures assume a kernel nobody has written yet. On the reference Python client, Exercise 97 is about seventy-nine eight-core machines running for ten days, and rho is a random process besides: there is a one-in-ten chance of finishing at 0.37× that and a one-in-ten chance of still running at 1.71×. The gap between those two rows is the whole invitation. Expected steps are 1.25·√n for the rho rows and 2·√(interval) for the kangaroo row. Rates assume 4×1010 steps per second per card, extrapolated from published 256-bit kangaroo throughput and not yet measured on a 131-bit field. Solving 131 bits says nothing about the 256-bit curves securing your wallet; the gap is a factor of 262.

Calibration

1,460 solves, not one anecdote

A single solve proves almost nothing: rho's completion count has a standard deviation near half its mean, so a round ending at 40% or at 200% of expectation is unremarkable. So we solve many independent instances at each size and check every answer against the generator's secret. The tool that does it is in the repository, and the table is one command.

BitsSolvesMean, in units of √n3σ interval of the mean10th–90th percentile
283001.2921.182 – 1.4010.52 – 2.14
323001.2311.110 – 1.3520.42 – 2.19
363001.3321.213 – 1.4510.48 – 2.27
403001.3281.222 – 1.4350.54 – 2.13
482001.3151.165 – 1.4650.42 – 2.36
56601.2701.020 – 1.5200.51 – 2.18

Fitted scaling exponent 0.5003 against the group size, R² = 0.9999: cost is square-root, with no drift across the range. The pooled mean is 1.295 against a theoretical 1.2533, and the 3.3% excess is accounted for rather than waved at — Teske's deviation for a 32-entry adding walk is about 1.6%, and the batched walker discards its in-flight walks when the collision lands, capped at 1% of the expected work per size, giving 1.2533 × 1.016 × 1.01 ≈ 1.285. What remains sits inside the intervals above. Before the walk's branch function was decorrelated from the distinguished-point test, every distinguished point took the same branch out of 128 — a defect that would have surfaced only as a slightly wrong constant, which is why this measurement exists.

Verification cost

measured, and asserted in the test suite

Checking work must cost far less than doing it, or the network simply pays for the search twice. A walk is checkpointed every 2v steps, and each submitted point commits to a Merkle root over its own checkpoint chain, fixed before the contributor can learn which segment will be challenged. An audit opens two checkpoints with proofs and replays only the segment between them.

Replay steps
117,464
Search steps
429M
Verification cost
0.027 %
Asserted ceiling
2 %

Measured on the round above. An earlier design replayed each walk in full and, at settlement, replayed every point, which cost the same order of work as the entire search: a rounding error at demonstration scale, a second complete search at 131 bits. A permanent test now asserts the ratio stays under two percent, so that regression cannot come back quietly. What the audit buys for that price is stated precisely rather than as one number: a point whose coefficients fail a·G + b·Q = (x, y) is caught by any challenge, because every segment re-checks that relation; a point with a valid relation but a broken checkpoint chain escapes unless the segment we open is the broken one.

Status

read this before sending anyone money
Exercise 97 is a calibration round. No prize, and nothing here should hold funds yet.

ECCp-97 was solved in March 1998 and the answer has been public ever since, so this round can check its own result: when the network reports a collision, the discrete logarithm it derives has to equal the number published then. That is the whole reason to run a solved problem first. Knowing the answer earns nobody credit — points are paid for walks that replay from a PRF nobody controls — and there is a test for exactly that.

Two independent reviews have been run against this code and both are published in full, with reproductions, in the repository. The second found a release blocker that the first round of fixes had itself introduced, and it is now closed: verification costs a fraction of a percent of the search rather than all of it. No prize has ever been settled on chain, and no contract has been deployed. Before ECCp-131 can start we still need a GPU kernel for the 131-bit field and a measurement of its real throughput, the number the whole schedule above depends on — which is the open invitation on this page, not a footnote to it. Findings and fixes: review/2026-09-08-external-review.md.