The first research target

An evaluation system
for optimizer research.

Contributors propose an optimizer; the validator measures whether it trains the same model more effectively within the same compute budget.

01From contribution to result

One task, one budget, one number.

The frontier moves only when someone beats it, and it is checked twice before it moves.

Miners contribute optimizer source code. The validator evaluates submissions under a common contract and rewards confirmed advances over the best result so far. Each submission is bound to its author before evaluation begins.

01Commit

Commit a hash

A miner publishes the SHA-256 of its optimizer source during the commit window and pays the round fee. The hash binds the submission before anyone can see it.

02Reveal

Reveal the source

After commits close, the source is revealed and must hash to the commitment. A static gate rejects anything that is not a plain torch update rule.

03Evaluate

Train for twenty hours

A fresh B200 pod trains the production model on pinned data under a sandbox that cannot reach the network. The held-out loss is recomputed from the checkpoint by a process that never ran miner code.

04Confirm

Confirm, then pay

A submission that clears the bar is re-run once at the validator's cost. Only if the second run also clears it does the frontier move, and the worse of the two runs becomes the new bar.

02What is measured

Held-out loss at a fixed compute budget.

Every reward-bearing run gets the same model, the same data, the same compute budget and the same public seed. A slower optimizer does fewer steps inside the budget; a faster one cannot buy steps past the schedule horizon. The learning-rate schedule belongs to the submission.

ModelLlama-style decoder, 360M parameters (RoPE, RMSNorm, SwiGLU, grouped-query attention, tied embeddings)
DataFineWeb-Edu, SmolLM2 tokenizer, 16B training tokens plus a document-disjoint held-out split, pinned by manifest hash
ShapeSequence 2048, batch 32, 188,000-step schedule horizon (at most 12.32B tokens; training stops at this horizon or the time budget)
Budget72,000 seconds on one NVIDIA B200, provisioned fresh for each run
MetricMean loss on 8,192 held-out sequences, recomputed from the saved checkpoint in a clean process
BarBeat the confirmed frontier by more than the adaptive threshold, with a floor of 0.03 nats (about 4.8 standard deviations of measured run-to-run noise on this hardware)
Historical genesisAdamW with a warmup-stable-decay schedule: held-out loss 2.7764 after 200,495 steps
03The payout

Emission tracks verified progress.

No leader bonus, no winner-take-all. A network that stops improving burns more every two weeks.

Every confirmed frontier event carries a credit equal to its improvement in nats, halving every fourteen days. The round pays a share of emission equal to the sum of those credits divided by a full-pay reference, capped at one, and splits the paid part across every contributor pro rata to credit. The reference ramps from 0.03 nats at launch, where a single confirmed floor-clearing win pays in full, to 0.10 nats after eight weeks, where one floor-level improvement a week sustains full pay.

crediti(t) = gi · 0.5(t − ti) / 14 d
payable(t) = min(1, Σ crediti / R(t)) · (1 − burn floor)
weighti = payable · crediti / Σ credit
burn = 1 − payable
R ramps 0.03 → 0.10 nats over 56 days; g in nats of held-out loss

The rule is linear in improvement below the cap, so splitting a discovery into pieces, or submitting it from many hotkeys, earns exactly what the discovery is worth and nothing more. The launch burn floor is 0% from day one: the full miner pool is eligible for verified progress. After six weeks, we will review results and discuss a possible pause; none is scheduled automatically. The dashboard publishes actual settlement.

Share of emission paid, by days since a confirmed event
Three scenarios under the launch ramp, no launch floor applied
one 0.03-nat eventone 0.10-nat eventa 0.03-nat event every week

Evidence accompanies
every result.

Explore verification →