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 boardStatus: 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.
Leaderboard
identities verified on github · hardware self-reportedpublic-demo · solved
48-bit curve · 11,401 points · 8 epochs · notional pool, no funds held| # | Contributor | Credits | Share | Points | Segments replayed |
|---|---|---|---|---|---|
| 01 | raullenchaiApple M3 Ultra · 4 worker processes | 19.000 | 5,110 | 4,863 ✓ | |
| 02 | claudeApple M3 Ultra · 2 worker processes | 18.152 | 4,890 | 4,646 ✓ | |
| — | unregistered key ae1e757e… disqualifieda point it submitted did not replay | 0.000 | 0 | 0 ✓ | |
| — | unregistered key 612349ce… disqualifiedforged, and filtered its work to dodge the audit | 0.000 | 0 | 0 ✓ |
Join
bring a machine, or bring a faster clientThe 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.
Accounting
designed and tested, never yet run with moneyThis is how a round is meant to pay out. Every step below runs today against a local vault in tests, and none of it has ever moved real money.
- You walk the curve.
Your GPU follows a pseudo-random path from a start point derived from your own public key. Occasionally it lands on a distinguished point, one whose x-coordinate ends in enough zero bits. That is the only thing you ever send.
- Each point is worth its expected work.
A point with w trailing zero bits stands for 2^w steps, and one credit is 2^30 verified steps. No block reward, no halving, no treasury, no vote.
- A sample of your work is replayed.
After each epoch closes, a fixed fraction of every contributor's submissions is walked again from scratch, so no choice of identifiers changes how much of your work is checked. Which points get picked depends on a beacon: with an external beacon, that value is published only after the batch seals and nobody could have known it; without one, the operator commits to a secret before the epoch opens and reveals it after auditing, which is unpredictable to contributors but not to an operator colluding with them. A funded round requires the external beacon. One failure forfeits everything.
- Your balance is committed on chain.
Every epoch the coordinator posts one Merkle root of every address and its credited steps to a vault on an Ethereum L2, built from balances that already survived that epoch's audit.
- The collision ends the round and pays everyone.
When two walks meet, the discrete logarithm falls out. The vault verifies it on chain itself, then each contributor sends one transaction and pulls their share. A prize that arrives weeks later is still claimable under the same root.
Which rollup the vault lives on, who funds the pool before a round opens, and how a prize awarded to a named entity, as Certicom's is, reaches a contract that pays strangers. The settlement denominator is now bound on chain to the leaves the operator published, so it can no longer be understated, but nothing on chain checks that a leaf corresponds to work anyone actually did: an operator can still insert a leaf for itself and dilute every honest share. Leaves are public, so this is observable; it is not yet preventable. The cost caveat that does survive is on the contributor's side: you must keep your checkpoint chains until the epoch containing a point has closed, because a chain you cannot open is credit you cannot collect.
Verification
why a stranger should believe any of thisThe 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| Target | Expected steps | Prize | 1,000 GPUs | Status |
|---|---|---|---|---|
| Certicom ECCp-97 | 4.2e14 | solved 1998 by 588 volunteers | ~10 s | opening |
| Certicom ECCp-109 | 3.2e16 | solved 2002 by 10,308 volunteers over 549 days | ~13 min | after the first fast client |
| Certicom ECCp-131 | 6.5e19 | $20,000, open since 1997 | ~19 days | first public round |
| Bitcoin puzzle #140 | 1.7e21 | 14 BTC, bearer | ~480 days | needs a kangaroo walk |
| Certicom ECCp-163 | 4.3e24 | $30,000 | ~3,400 years | out 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 anecdoteA 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.
| Bits | Solves | Mean, in units of √n | 3σ interval of the mean | 10th–90th percentile |
|---|---|---|---|---|
| 28 | 300 | 1.292 | 1.182 – 1.401 | 0.52 – 2.14 |
| 32 | 300 | 1.231 | 1.110 – 1.352 | 0.42 – 2.19 |
| 36 | 300 | 1.332 | 1.213 – 1.451 | 0.48 – 2.27 |
| 40 | 300 | 1.328 | 1.222 – 1.435 | 0.54 – 2.13 |
| 48 | 200 | 1.315 | 1.165 – 1.465 | 0.42 – 2.36 |
| 56 | 60 | 1.270 | 1.020 – 1.520 | 0.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 suiteChecking 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.
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 moneyECCp-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.