Miner FAQ

What do LIVE, APPROVED and PENDING mean?

LIVE

LIVE: in force now and run by the current validator release. APPROVED: decided and announced, takes effect at the date shown. PENDING: the decision is still open; the text says what is being decided, and nothing in it is a rule yet. Times are in UTC with Berlin time in brackets. Berlin moves from summer time (UTC+2) to winter time (UTC+1) on Sunday 25 October 2026, so from then on 14:30 UTC is 15:30 Berlin.

The full rules are on the rules page; the exact files and constants are in the public reax-subnet repository. If this FAQ and the running release seem to differ, tell us in #92. For APPROVED answers the announced rule applies from the date shown, and we fix the code or this page before then.

Where do I ask a rules or status question?

LIVE

Ask in #92 on the Bittensor Discord, so everyone sees the answer. Direct messages are the exception: use them for private matters (keys, ownership proofs, code releases) or if you cannot post in #92. Errors in your own entry: see below. We answer once an hour between 06:30 and 21:30 UTC (08:30–23:30 Berlin until 24 October, 07:30–22:30 Berlin from 25 October).

How is the miner emission split between the tracks?

LIVE

Since 21 October 2026, 13:00 UTC (15:00 Berlin): inference 50%, REAX Engine 20%, generalist decision model 30% of the miner part of the emission. Inside a competition track the share is split 75% / 17% / 8%: the champion, the champion dethroned most recently, and the one dethroned before that. A share that nobody may be paid (no champion yet, award not approved, place expired) goes to the inference miners (except the short keep-share cases in this answer). It never moves up to the next rank and nothing is burned. Rewards are a protocol mechanism, not a promise of any amount, and can be zero.

Are 17% and 8% paid to places 2 and 3 of a ranking?

LIVE

No. 75/17/8 means the champion plus the two most recently dethroned champions (former-champion places), in the order they lost the title, not by score. On the generalist track a former-champion place has no time limit: it ends when newer former champions push it out. On the engine track it also ends 7 days after losing the title. A former champion is paid only while it stays committed by the same hotkey with a valid result and a valid award approval. Runners-up of a crowning are not paid; the one exception is places 2 and 3 of the generalist opening (next answer).

What do places 2 and 3 of the generalist opening get?

LIVE

As a one-time exception for the opening cohort, the next two entries after the three co-champions take the former-champion slots: place 2 (UID 160) the 17% slot and place 3 (UID 113) the 8% slot, if they clear the entry floor, beat their base model by 1.5 points and pass the normal award review, from Friday 23 October 2026, 13:00 UTC (15:00 Berlin), for at most 7 days. Like every former-champion slot they are pushed out by newer former champions (so the 7 days are a maximum), and each is paid only while its award approval is valid. There is no extra emission. Both places are live: they have been paid since the first weight set under the new rules (block 9346668, about 13:55 UTC on 23 October): UID 160 17%, UID 113 8%.

If a new champion is crowned while these places run, UID 116, 199 and 250 take place 2 together (17%, about 5.67% each), UID 160 moves to place 3 (8%) until Friday 30 October, 13:00 UTC at the latest, and UID 113’s opening place ends. If nobody is crowned, UID 160 and 113 keep 17% and 8% until Friday 30 October, 13:00 UTC. Slot rules, section 6.

When did the generalist track open, and what happened to demand forecasting and risk assessment?

LIVE

The generalist track is open since Wednesday 21 October 2026, 13:00 UTC, with no end date. Demand forecasting and risk assessment ended at that same moment (their earlier published end was 30 October 2026, 12:00 UTC) and are no longer paid. Their champions and approved former champions kept a bounded legacy keep-alive for 7 days (details).

Who holds the generalist title now?

LIVE

The opening playoff ended in a practical tie, so UID 116, 199 and 250 are co-champions. They share the 75% champion share in equal thirds (25% of the track share each), and each third is paid only with that entry’s own award approval; an unpaid third goes to inference. The set holds the title until a challenger beats the best of the three by the required margin on the challenger’s own draws (all three are served on every challenger draw). Live status: live queue.

What happens when one entry clearly wins a crowning slot?

APPROVED effective from the slot on Mon 26 Oct 2026, 14:30 UTC (15:30 Berlin)

A clear winner takes the whole 75% champion share (paid once its award is approved). The former-champion shares stay 17% and 8%, and there is no extra emission.

An entry is the clear winner when it is the only entry left in the slot. After each shared round of 900 fresh items, every other entry is compared with the leader and leaves when the leader is ahead of it by at least the margin: the larger of 1.0 point and 2 paired standard errors. If only one entry is in the slot, it is crowned. Slot rules, section 4.

What if the leading entries are practically tied?

APPROVED effective from the slot on Mon 26 Oct 2026, 14:30 UTC (15:30 Berlin)

For close results we test additional shared tasks. Only practically tied leading models share the champion share. All entries in a slot are compared on up to three shared rounds of 900 fresh items. Entries share the 75% champion share equally (two entries 37.5% each, three 25% each) only if both hold: they are still not separated from the leader after round 3, and the leader’s average minus theirs is 0.5 points or less (also under eval v5, which keeps the margin floor of 1.0; the tie gap is half of it). The gap is measured from the leader for each entry, so a chain of entries that are each close to the next cannot pull in a clearly weaker model. Practically tied is not the same as equal: not being separated does not prove that two models are the same. If an entry is not separated but more than 0.5 points behind, the leader is crowned alone; this is announced, not a silent fallback. In a slot one holder (same coldkey or same Hugging Face account or organisation, also through a chain) keeps at most one entry. No one outside the tied group is paid as a runner-up. Slot rules, section 5.

A joint champion group later counts as one former champion: it is dethroned together when a challenger beats its best member by the required margin, and it then shares one former-champion slot equally.

What happens to the three co-champions when a challenger beats them?

APPROVED approved 22 Oct 2026; applies when the co-champions are beaten

The beaten co-champion set becomes one former-champion slot, shared equally by the three (each part paid only with its own approval). It does not take three slots.

Can you show concrete payout examples?

APPROVED effective from the slot on Mon 26 Oct 2026, 14:30 UTC (15:30 Berlin)

These examples show the approved policy from the Monday 26 October slot. All numbers are parts of the generalist track share (30% of the miner part of the emission). Every part is paid only with a valid award approval; anything unpaid goes to inference.

Places 2 and 3 go to the two most recently dethroned champions, in the order they lost the title; a beaten co-champion set or shared group counts as one.

• Clear winner. Entry A wins a slot clearly: A 75%. The most recently dethroned champion 17%, the one before 8%.
• Tied group of two. A and B are still not separated after round 3 and B is 0.5 points or less behind A: A 37.5%, B 37.5%; former slots 17% and 8% unchanged.
• Tied group of three. A, B and C: 25% each; former slots unchanged.
• Beaten co-champions. A beats the best of UID 116, 199 and 250 clearly: A 75%; the three share one former-champion place equally. While the opening places run, that is place 2: UID 116, 199 and 250 about 5.67% each, UID 160 8% (until Friday 30 October, 13:00 UTC at the latest), UID 113 nothing.
• A tied group is beaten later. Challenger X beats the better of A and B by the margin: X 75%; A and B together form one former champion and share its slot equally.
• Today, before any new crowning. UID 116, 199 and 250 25% each; since Fri 23 Oct (weight set of about 13:55 UTC) also UID 160 17% and UID 113 8% (opening places).

Worked examples with round-by-round numbers: slot rules, examples.

When is the next generalist crowning?

APPROVED effective from Mon 26 Oct 2026, 14:30 UTC (15:30 Berlin)

Evaluation runs all the time; only crowning waits for a slot. Every entry gets its first draw in the normal queue (about one cycle per hour, up to 8 evaluations per hour) and its confirmation about 12 hours later; results appear on the live page right away. At the Monday and Thursday 14:30 UTC slots, the entries confirmed by then are crowned (several: up to 3 shared rounds, usually decided within a few hours). So after confirming you wait at most until the next slot. Until Monday 26 October 2026, 19:00 UTC (20:00 Berlin), a confirmed engine winner is still crowned right away; a challenger that confirms from then on waits for the first engine slot, Tuesday 27 October 2026, 14:30 UTC (15:30 Berlin), then every Tuesday and Friday at 14:30 UTC. Announced 25 October, not retroactive. The engine track has its own slots (engine title).

Generalist crowning slots are every Monday and Thursday at 14:30 UTC (15:30 Berlin in winter time), starting Monday 26 October 2026: 26 Oct, 29 Oct, 2 Nov, 5 Nov and so on. There is no Friday slot. A challenger is crowned only at a slot. Submissions stay open all the time.

A slot includes every entry whose confirmation has passed and is shown on the live page with a time before 14:30:00 UTC on the slot day, and every entry whose confirmation was due at or before 13:30:00 UTC (12 hours after its first draw passed) but has not run yet because of our queue; we run those first, on the slot’s evaluation. Slot rules, sections 1 and 2.

Until Monday 26 October 2026, 19:00 UTC (20:00 Berlin), a confirmed engine winner is still crowned right away; a challenger that confirms from then on waits for the first engine slot, Tuesday 27 October 2026, 14:30 UTC (15:30 Berlin), then every Tuesday and Friday at 14:30 UTC. Announced 25 October, not retroactive. The engine track has its own slots and is not tied to these (engine title).

What is a hotfix, and how is it different from a normal rule change?

LIVE

A hotfix is a change to a rule that demonstrably fails: the rule lets results through that it was meant to stop, or blocks results it was meant to allow. It is not a further development of the mechanism. A hotfix applies at once, not after the next crowning.

Every hotfix is published together with a written fairness check for good-faith miners: what changes, who could be affected, and why waiting would be worse. If the check shows that a hotfix would treat honest miners unfairly, we do not just apply it: we look for a fair way to apply it, for example by protecting results that were reached under the old rule.

Normal rule changes keep the announced-in-advance rollout (slot rules, section 1): announced in #92 and here, with their own effective date. Standing principle for both: the shortest window that works. Any window longer than a few hours comes with a one-line reason.

The change log says for every version whether it holds a hotfix, a normal rule change or a clarification.

Is there a commit cutoff before a generalist slot?

APPROVED HOTFIX, effective from the slot on Thu 29 Oct 2026, 14:30 UTC (15:30 Berlin)

Yes, from the Thursday 29 October 2026, 14:30 UTC slot, as a hotfix (first announced for Monday 2 November in version 2.12, brought forward in version 2.13). An entry plays a slot only if its commitment was first seen on chain at least 6 hours before that slot. For Thursday 29 October that is 08:30 UTC (09:30 Berlin); for Monday 2 November it is 08:30 UTC as well. A later entry is evaluated normally, as always, and plays the following slot. It is the block in which the commitment was first seen that counts, not when the repo went public or when we evaluated the entry.

Why 6 hours. It is long enough that a light fine-tune of a just-published leader cannot enter the same slot, and short enough that an honest late entry waits at most one slot.

A confirmed entry held for the next slot keeps its keep-alive until that slot has been decided (keep-alive). The live page shows which slot a held entry will play. If a new champion is crowned in the meantime, the entry has to beat that champion and starts again with a new first draw, as in section 2.

Fairness check (hotfix). Why now: until Monday 2 November the gap lets a light fine-tune of a just-published leader enter the same slot. Who is affected: an entry first seen on chain after Thursday 29 October, 08:30 UTC plays the Monday 2 November slot instead; nobody loses a measured result. A commit-reveal scheme is being designed as the successor to this cutoff; there is no date yet, and it will be announced like any rule change.

I am in the queue under the current evaluation. What happens when eval v5 starts?

APPROVED for the Mon 26 Oct 2026 slot

Entries that confirm under the current evaluation before Monday 26 October, 14:30 UTC are decided at that slot under the current evaluation, and the winner (or a tied leading group) is crowned as earned. Also in that slot: entries whose confirmation was due at or before 13:30 UTC that day (first draw passed at or before 01:30 UTC) but has not run yet because of our queue; we run these confirmations on the current evaluation before the slot rounds start (section 2). Eval v5 binds at 14:30 UTC that Monday: titles are defended on v5 after the slot and new entries are scored on v5, and an entry that is not in Monday’s slot starts again on v5 automatically: a first-draw result from the current evaluation does not carry over; no recommit needed. If Monday’s slot crowns a new champion, an entry that is not in the slot starts again with a new first draw against it.

When does eval v5 become binding?

APPROVED effective from Monday 26 October 2026, 14:30 UTC (15:30 Berlin)

Eval v5 binds from Monday 26 October 2026, 14:30 UTC (15:30 Berlin) for new evaluations and title defences. Before v5 could bind, we checked that our private test set ranks about 40 open models the way the public Decision Indexes do. The second check finished on 23 October 2026, on 35 open models that the Hugging Face Decision Index has scored, 21 of them in its top 40. Rank agreement with the Decision Index over all models: 0.90 (bar 0.9, met). Among its top-40 models: 0.65 (bar 0.7, missed). Our new-domain part against the Decision Index new-domain part, top 40: 0.64 (bar 0.6, met; its 80% lower band 0.396 against a bar of 0.40, just missed). For comparison, the public test families of the current evaluation reach 0.18 among the top 40. So the check came close but did not pass. We decided that v5 binds from Monday anyway, because it ranks models far closer to the Decision Indexes than the current evaluation does. Noise is higher than we planned for; the z-gates still apply, which makes crowns rarer rather than easier. We keep improving v5 (version 0.2) and announce every change here and in #92 before it applies. Monday’s slot itself still runs on the current evaluation (slot rules, section 3): entries that confirm under it before 14:30 UTC are crowned there, as earned. Every slot candidate, including the defending group, also gets a v5 score on one common draw (pool version 0.1.1), published next to the current score in the slot result (decision of 23 October, option A). From then on titles are defended on v5 and new entries are scored on v5; the slots from Thursday 29 October use v5. The v5 numbers: next answers.

Which numbers apply under eval v5?

APPROVED with eval v5

• Draw. 900 private items per draw: 540 same-skill tests (60%) and 360 new-domain tasks (40%), plus public items at weight 0. A decision pools your first and your confirmation draw.
• Bar. A challenger has to beat the best current title holder and its own declared base by the margin, on the same items. The minimum margin stays 1.0 point, and the z-gates stay as they are (first stage).
• Floors. The entry floor (36.8) and the non-procedural floor (37.4) of the current evaluation do not apply to v5 scores; the bar above replaces them.
• Ties in a slot. Tie gap 0.5 points from the leader (half the margin floor), separation margin the larger of 1.0 point and 2 paired standard errors, up to three shared rounds: the same numbers as under the current evaluation (tied group).
• No gap penalty. Public items count 0%. Instead there is a gap check: if your gain over your base on public items exceeds your gain on private items by more than the larger of 1.5 points and 2 standard errors, we check the entry for overlap with our private sources before any award. Your score itself does not change.
• Scale. v5 scores are scaled against a fixed panel of untuned stock models, on roughly the Decision Index scale. They cannot be compared directly with scores from the current evaluation.

What does eval v5 measure?

APPROVED with eval v5

Eval v5 is built to rank models the way the Hugging Face Decision Index and the Artificial Analysis Decision Index do; we checked how close it comes before it binds, and the result, including where it fell short, is in when v5 binds. About 60% of the score comes from private tests of the same skills as the public Decision Index benchmarks, and about 40% from private decision tasks in new domains. Version 0.1, which binds from Monday 26 October, covers three skill areas: knowledge and reasoning (code, logic, maths, SQL, probability, and fact questions with an “I don’t know” option), retrieval and tools. The new-domain part has 11 tasks, among them security advisories, EU public tenders, Wikipedia community decisions and games with exact solvers. Language and safety-classification items are not part of version 0.1. Every scored item is private. Public items, including our dev set, count 0%; a public score far above the private score triggers a review. An item with several questions counts only if every answer is right. Up to 26 options are served per question, and there is no thinking.

How does the “I don’t know” option work?

APPROVED with eval v5

Fact questions offer “I don’t know” as an extra last option. A correct answer scores +1, a wrong answer −1, “I don’t know” 0. We read your served probabilities as usual: your top option is your answer, with no threshold or temperature on top. So abstaining when unsure pays on these questions.

Where are the v5 format, dev set and scorer?

LIVE

In the public reax-subnet repository: the exact item format, the 300-item public dev set and the reference scorer. The dev set has weight 0 in the score and shares no items or sources with the private test set; use it to check your pipeline end to end, not to rank models finely.

Will I see my v5 score before v5 binds?

APPROVED at the Mon 26 Oct 2026 slot

Yes, for the slot. Decision (option A, 23 October 2026): the Monday 26 October slot still crowns on the current evaluation, but every slot candidate, including the defending group, also gets a v5 score on one common draw (pool version 0.1.1). We publish it next to the current score in the slot result. The v5 score is information in that slot and does not change who is crowned. From 14:30 UTC every new evaluation and title defence runs on v5. Format, dev set and scorer: public.

Do the co-champions keep their title under v5?

APPROVED with eval v5

Yes. The co-champions keep the title and are re-scored under v5 on every challenger draw. A challenger has to beat the best of them, and its own base, by the margin.

Why is my entry still queued?

LIVE

Our competition worker runs an evaluation cycle about once an hour and evaluates up to 8 models per hour across the tracks; the champion is one of them. New entries wait for the next cycle in the order of their on-chain commitment, except that first evaluations of entries whose hotkey is already past its immunity period go first. From Monday 26 October 2026, 14:30 UTC: confirmations due before a slot run first (slot rules, section 2). The live page explains each status (queued, waiting for repo, waiting for base model, evaluating, pending confirmation).

How large is a generalist draw, and what margin do I need?

LIVE

Since Friday 23 October 2026, 13:00 UTC a generalist draw has 900 items (90 per area) and the minimum margin is 1.0 point; the statistical bar stays the same. Before that, a draw had 300 fresh sealed items (30 per area) and the minimum margin was 1.5 points. Items, draw seeds and the scores on private items are never published.

What do the first stage, z and a close call mean?

LIVE

z is your gain over the champion on the same items divided by its standard error. On the first draw, z ≥ 2 and a gain of at least the minimum margin pass. A close call (1 ≤ z < 2) gets exactly one more first-stage draw, and z < 1 is not better. At confirmation you need a pooled z ≥ 2.75 over all your draws against that champion. Against the co-champions, the bar is the best of the three on your draw.

When does my confirmation draw run?

LIVE

On a fresh draw disjoint from your first draw, at least 12 hours after the first draw (also after a close call). The time on the live page is an estimate that depends on the cycle and the queue.

How is the gap penalty computed?

LIVE

The gap is your score on our generator-family items minus your score on the cross-author items. S_eff = S − min(10, 0.5 × max(0, gap − G_med − A)), with the frozen median gap G_med = 14.84 and A = max(8, 2 × SE). S_eff is the score every decision uses under the current evaluation. The live page does not show the penalty itself, because with the raw score it would reveal the score on the private items.

APPROVED Under eval v5 there is no gap penalty; a gap check takes its place (v5 numbers).

What are the generalist entry floor and the non-procedural floor?

LIVE

The entry floor is 36.8 and the non-procedural keep-alive floor 37.4 under the current evaluation. An entry at or below the entry floor earns nothing from the track. Under eval v5 these floors do not apply to v5 scores; the bar is your base and the best title holder plus the margin (v5 numbers).

Do the per-area scores matter?

LIVE

They are shown with every entry and are information only: a model far below the reference in one area gets a closer look in the award review. Before a generalist award we also compare the new champion with the official base on our private Decision-Index-style evaluation; if it is clearly worse there, the award goes to a manual review.

How is a Decider-style model with a separate readout head run?

LIVE

A Qwen3.5-family backbone with readout.safetensors and decision_config.json is run on our own runtime the way it was trained: your readout head as submitted, on the last prompt position, with our fixed REAX prompt and a fixed temperature of T=2. The temperature in decision_config.json is metadata only, so calibrate your head for T=2.

What may a generalist entry be?

LIVE

Up to 36B parameters and 68 GiB of safetensors weights, dense or MoE: Qwen3 and Qwen3-MoE, Qwen3.5 (including MoE), Gemma 3, Gemma 4 or Llama. The repo must be public and carry an Apache-2.0, MIT or BSD LICENSE file (Google’s Gemma 4 repos do not ship one, so add it). Weights only: no repository code is ever executed. Commit reax-spec/1:generalist:<hf_repo>@<40-hex revision> with a reax-specialist.json that says "category": "generalist".

Do I have to fine-tune the official base?

LIVE

No. The official base is decisionmodels/reax-1 at revision ca2a0cc5; any allowed architecture within the limits works. The base matters for entries above 10B parameters (they must beat their own unmodified base by 1.5 points for the keep-alive) and for the derived-entry rule. Which bases we recommend is in Which base models do you recommend for the generalist track?

Which base models do you recommend for the generalist track?

LIVE

Which base models we recommend for the generalist track, and why. Announced in #92 on 26 October 2026 (link: #92 announcement).

Today about 4 out of 5 generalist entries are fine-tunes of pplx-decider-v1.2 or of REAX 1.x, which is pplx v1.2 underneath. With ordinary fine-tuning, that line tops out around 68 on the HF Decision Index 0.4.1. Every plain Qwen3.8 fine-tune on that board is at or below pplx itself. GLiDE is also Qwen3.8-27B based and sits at 71.5, so the base can go higher. It took a much heavier recipe, though (Fastino’s public training report: soft-target distillation from reasoning teachers, training rows built like the evaluator’s items). Our own REAX 1.2 is level with pplx there too. It is a good AA model, but it is not the road to a higher HF score.

What we watch is the HF Decision Index and the Artificial Analysis Decision Index. They reward different things, so here is what we recommend for each:

HF Decision Index → Gemma-4-31B line

• google/gemma-4-31B-it (Apache-2.0), or as a stronger start tattrongvu/Jeffan-31b-1710. Jeffan moved to Apache-2.0 on 22 Oct; please pin revision cebfa86c and keep the attribution.
• Why: the Gemma line is strong on the new-domain part of the index, which is 40 % of the score. In our internal eval v5 calibration checks, the unmodified Gemma-4-31B-it and Jeffan both score above pplx v1.2 and REAX 1.2 as bases (not as finished entries).
• The generalist open class accepts Gemma 4 architectures up to 36B parameters.
• We ran Jeffan@cebfa86c through the live validator stack (vLLM 0.30.0): it serves and scores cleanly. Your repo needs a reax-specialist.json manifest (reax-specialist/1, category generalist, your hotkey, base_model: google/gemma-4-31B-it@<rev>, licence: apache-2.0); without it the fetch refuses the entry.
• This is a starting point, not a finished entry: un-tuned it scores well below today’s champions on the current evaluation, so it needs your fine-tuning on top.
• Staying on Qwen: Qwen/Qwen3.8-27B itself (Apache-2.0) is a fine base. The recipe matters more than the base here.

Both indices → baselabs/mammoth-1 (new)

• baselabs/mammoth-1 (MIT, 27B, Qwen3.5 architecture, the family most of you already train on). Please pin revision 03007ab3 (the later head 61cec44c, which the engine track pins, only changes the model card; the weights are the same).
• Why: in our own checks it scores above pplx v1.2 and REAX 1 as a base on JevBench capability (85.2) and on our estimates of both Decision Indices (HF about 72.8, AA about 61.6; our replicas, not official scores). Against Jeffan it is higher on our AA estimate and level within noise on our HF estimate.
• Like any base, this is a starting point: it still needs your fine-tuning, and your own measurements decide.

AA Decision Index → the abstention recipe, on any base

• Most of the gap between pplx and the AA leaders is the “I don’t know” option. See quick win 1 in my Friday v5 post: abstain when unsure if “I don’t know” is offered. Training that in moved our own model up about 3.8 points on our AA replica.

Not recommended as a base:

• GLiDE (fastino/GLiDE): strong on HF, but its community licence needs a paid agreement for larger commercial users and applies to derivatives.
• Anything CC-BY-NC (e.g. StartLux, Lychee). The validator only accepts Apache-2.0 / MIT / BSD anyway.

How this list works

• We check both boards daily, plus licences and our internal early measurements of submitted models. When something changes, we publish a new version here and in the FAQ (v2, v3 …).
• This is a recommendation, not a rule. pplx- and REAX-based entries stay fully eligible, and we will not lock the track to any base, including our own.
• Eval v5 (from Mon 26 Oct 14:30Z) scores private same-skill and new-domain tasks, like the HF index. We keep improving it toward both indices and announce each version.
• Nothing here is a ranking or score promise for any model. Measure on the public dev set and your own held-out data before you switch.

Are there limits on what I may train on?

LIVE

The rules do not restrict training data beyond the licence of the model you publish. What we enforce is on the evaluation side: private draws nobody sees, the gap penalty, and from v5 a review when your public score is far above your private score.

What counts as a copy or a derived entry?

LIVE

Exact copies (same tensor hash) are refused, and the earliest commitment owns a hash; re-sharding or renaming files does not hide a copy, and for generalist entries the check also hashes the backbone without the readout head. An entry is derived if you declare another entry as your base or our checks find that its weights or answers derive from an earlier entry. It must beat its parent by the full copy margin: the full decision margin and, on competence alone, by at least 1.0 point and 2 standard errors, so a recalibrated copy cannot be crowned. Independent fine-tunes of the official base are not affected.

Clarification (24 Oct 2026, not a new rule): the copy, derived and near-champion checks apply to what a model computes. A function-preserving reparametrisation (e.g. rescaling MLP channels) is judged as the underlying weights.

Change (validator release rc11.post5, not before 26 Oct 2026, 14:30 UTC): the automatic check will undo such rescaling itself (a scale-invariant comparison) before it compares weights. Until then the review applies the clarification above.

I merged other entries into my model. Is that allowed?

LIVE

Yes, but a model close to an earlier entry is checked as derived (previous answer), and the award review looks at the merge share and the credit. State your recipe and the credit clearly in the repo.

May I reuse another engine entry’s code or binaries?

LIVE

Ideas are free. You may reuse code or binaries of other entries if you declare them in the image label ai.reax.engine.parents, a JSON list such as [{"uid": 4, "digest": "<64 hex>", "files": ["/app/engine.py", "/app/kernels/"]}] (at most 8 parents; a path ending in / covers the directory). Your entry must then beat every declared or detected parent by the full challenger margin. Undeclared reuse counts as a copy: the first time the entry is not evaluated, the second time the hotkey is paused for 7 days. Reusing your own earlier entries is free. Details: ENGINE-COMPETITION.md, section 5a.

How to fill the label (clarification, 25 Oct 2026; not a rule change): the label is per file origin. Declare every earlier entry whose files are in your image, and list each file under the entry where that content first appeared. Example: if you take files from entry B, and some of them B itself took from entry A, declare A for those files and B for the files that are new in B. The bars apply to every declared or detected parent. If this would need more than 8 parents, send me a message on Discord before you commit, and we agree how to declare it.

Change (validator release rc11.post5, from 27 Oct 2026, 14:30 UTC; published here 24 Oct, announced in #92 26 Oct, not retroactive): the parent is measured in the same session. When your derived entry clears the champion bar but falls short of its parent’s stored line (the parent’s best score ever, times 1.03), or lands within 3 % of it, the validator runs the parent’s best image right after your entry, on the same machine with the same items. For that session the line is the higher of the parent’s same-session score and its lowest valid score, times 1.03. This repeats in each confirmation session, at most 3 parent runs per batch; if the parent cannot be run, the stored line applies. These runs never change the parent’s own scores or ranking.

Does an engine entry need published source?

LIVE

Yes. Nothing without published source is paid: an engine whose kernels or code are not published can be measured, but its award is held until the source is public. No engine award is held for this reason today; the live page shows any that is. For engines that re-encode the weights, see quantisation and repacking. To have an entry ready before the crowning: How to be award-ready before crowning.

How do I make my engine entry award-ready before it is crowned?

LIVE

Clarification, not a rule change: this lists what our award review checks, so you can have it ready before the crowning. The rules are in the answers on published source, reusing another entry and quantisation and repacking.

1. Publish the source of every closed native before you commit. Every .cubin and .so in the image needs public source in a repository under a licence that lets us host, run and publish it: MIT, Apache-2.0 or the REAX Engine License. Publishing all of it before you commit is the safest order; the award is held for anything that is missing.
2. Give the exact build line and toolchain. Our private CI rebuilds each native from your public source and compares it byte for byte with the file in your image. Put the exact command (compiler flags, -D defines, target architecture), the working directory and the toolchain version (for example the nvcc version or the CUDA image tag) in the README or a build script. Compiled modules can carry path-dependent ids, so build from the same source path as in the image (for example /opt/s1eng/s1eng), and say so.
3. Ship the same files you published. The source files in the repository must be identical, byte for byte, to the ones in the image. A file that differs, or a native with no source of the same name, counts as unpublished.
4. Tell us where the repository is. There is no image label for the source link today, and our reviewers do not read one. Put the repository link in a README inside the image, name the repository in your commitment discussion on Discord, or both. A README in the repository that names your UID and the image digest helps us match the two.
5. Fill the parents label per file origin. Declare every earlier entry whose files are in your image in ai.reax.engine.parents (details in reusing another entry). For reuse from another hotkey of the same owner, add signed ownership proofs in ai.reax.engine.ownership; the same coldkey needs no proof.
6. Ship no weight-like files. From Tuesday 27 October 2026, 14:30 UTC the engine derives everything at start from /model (quantisation and repacking). No weights, scales or calibration statistics in the image.
7. Calibrate only on the public seed set (0x52454158), at start, or use a calibration-free conversion.
8. Set the hotkey label. ai.reax.engine.hotkey must be the hotkey that commits the digest, in the final image configuration (see “not owner”).

What we do. We review the image before its first run (labels, parents, files, no weight data). After the crowning we check that your public source rebuilds your natives byte for byte, then the owner signs the award approval. If everything above is in place, nothing is left to ask you. Every award is decided within 6 hours of the crowning, inside our review window (award decision time). So far, two awards with complete source were approved about an hour after the source was public (uid 221 and uid 62, 26 October 2026); that is what we saw, not a promise beyond the 6 hours. If anything is missing, the award is held and the live page says what.

How many entries can one coldkey hold?

LIVE

At most 2 open submissions per track and 4 new submissions per 7 days per coldkey. One hotkey holds one competition commitment; a new commitment from the same hotkey replaces the old one. Paid waiting keep-alives are limited to 2 per coldkey per track, and the provisional keep-alive to one per coldkey per track. From Monday 26 October 2026, 14:30 UTC: in a crowning slot one holder keeps at most one entry (slot rules, section 4): entries with the same coldkey or the same Hugging Face account or organisation in the repo id have the same holder, also through a chain (A shares a coldkey with B, B shares an HF account with C: A, B and C are one holder).

What is the keep-alive, and who gets it now?

LIVE

A participation weight so that an entry is not deregistered just because it is waiting for us; it is not an award and needs no approval. Since 26 October 2026, 16:55 UTC (hotfix) it is part of the mechanism for every waiting state:

• Committed, not evaluated yet. From the first weight set after your commitment is on chain you get a provisional keep-alive (half the weight of a typical inference miner), also before our evaluator has looked at the entry. Once your model has been downloaded and checked it lasts until your first draw has decided the entry, however long our queue or our GPUs take (safety limit 96 hours). If we cannot reach your repo (private, missing revision), it lasts 24 hours from the commitment; one such window per hotkey every 72 hours, and at most 16 such entries per track (the oldest commitments first).
• Pending confirmation, confirmed and waiting for the next slot, or held by the commit cutoff. The keep-alive (the weight of a typical inference miner) runs until the slot that decides the entry has been run, not just 24 hours after the first pass. If that slot does not decide it (voided, or our host failed), it runs on to the next slot, unless your repo has become unreachable (at most 9 days in total).
• A new champion waiting for award approval: 72 hours after crowning (was 24 hours).
• Track switch. A hotkey that moves to a new entry is covered by the new entry from the first weight set after the commitment, so there is no gap.

Limits that stay: entry floor and non-procedural floor for the keep-alive after a draw, one provisional keep-alive per coldkey per track, at most 2 open entries per coldkey per track, and the share caps (all keep-alives of a track together at most a quarter of its share, provisional ones at most 5%). No waiting entry whose model we have checked is cut to zero by a count limit any more: when a cap is reached, it is split evenly. A hotkey that also serves a little inference is topped up to the keep-alive level.

What it cannot cover: the time between a brand-new commitment and our next weight set (about 70 minutes), a repo kept private for more than 24 hours, a declared base model that is not on Hugging Face, an entry under review, and decided entries (not better, rejected). The keep-alive does not reserve a UID; the chain prunes the lowest-emission UID that is not immune.

When does the provisional keep-alive start: at my commitment or after you fetched my model?

LIVE

At your commitment: the window is counted from the block in which your commitment is on chain. It is paid from the first weight set after that block. Until your repo has been reached, it lasts 24 hours from the commitment; once your model is downloaded and checked, until your first draw (at most 96 hours). It ends when the first draw has decided the entry (a passing entry moves on to the normal keep-alive). The 24 hours before we have reached your repo are only for real models: a commitment that is not a loadable model (the committed revision does not exist, no safetensors weights, weights identical to the declared base model, or a Hugging Face revision different from the committed one) gets no such window, and its coldkey gets none for 30 days; two such commitments by one coldkey within 30 days end its provisional keep-alive for that time. A private repo is not affected and keeps its 24 hours. Before version 2.15 this answer said 12 hours from the commitment and the code only paid after our check; both are replaced (keep-alive).

What happened to the demand forecasting and risk assessment champions?

LIVE

For 7 days from the generalist opening (until 28 October 2026, 13:00 UTC, 14:00 Berlin) the champion of each ended track and its approved former champions get a bounded keep-alive, only as pure entrants. It ends if the hotkey commits to anything else; since 26 October 2026, 16:55 UTC a new generalist or engine entry of that hotkey is covered by the waiting keep-alive from its commitment on (keep-alive), so a switch leaves no gap.

My hotkey was pruned while my entry waited for confirmation. Is my first draw lost?

LIVE

Not necessarily. If you commit the same model (identical tensors) again within 72 hours of the prune, under any new hotkey or UID, by the same coldkey or from the same Hugging Face repo, you keep your first-draw score and go straight to the confirmation draw. The repo’s reax-specialist.json must name the new hotkey, and copy checks still apply. A changed commitment while the hotkey stays registered is not a prune and carries nothing over.

If the prune was caused by us, we also refund the registration (slot rules, section 11).

Do I get my registration fee back if I lose or am pruned?

APPROVED effective from 22 October 2026, 19:55 UTC (21:55 Berlin)

No, except in one case. Registration burns TAO and the chain sets the cost, so check it before you register. If your hotkey was pruned because of our wrong weights, our timing or a validator bug, we refund what you paid to register it again, from our own share; this applies to prunes from 22 October 2026, 19:55 UTC on. Tell us in #92 with your UID and the time. In every other case registration fees are not refunded. Slot rules, section 11.

What is an award approval, and what does the review check?

LIVE

A winning entry is paid only after we check and approve it: the champion and every paid former slot, for exactly one entry (track, hotkey, repo@revision or image digest). A new revision or digest needs a new approval. The automatic copy and near-duplicate checks must pass first; then we look at provenance, originality and credit for merged or reused work. Approvals are signed with our owner key and published in approvals.json; validators accept only a valid signature for exactly that entry.

How long does an award decision take?

LIVE

Since Friday 23 October 2026, 13:00 UTC we decide every award within 6 hours of the crowning, counted inside our review window of 10:00–22:00 Berlin time (09:00–21:00 UTC in winter time). Clear cases under the published rules are approved automatically; cases that need a closer look still get a person’s decision within the same 6 hours. The live page shows an estimate. An award on hold (for example, source not published) is decided once the hold is cleared; the live page shows its status.

My entry is champion. Why is its share not paid yet?

LIVE

Its award is pending or on hold (for example: source not published, a copy question, a missing licence). Meanwhile, on the generalist track the champion it beat keeps the new champion’s part of the 75% for up to 48 hours from the crowning. APPROVED From the slot on Monday 26 October 2026, 14:30 UTC (15:30 Berlin): a beaten co-champion set keeps it in equal parts. While it keeps that part, it gives up its own former-champion place share, which goes to inference. After 48 hours an unapproved part goes to inference until the approval exists, and the beaten champion is paid its place share (slot rules, section 8). On the engine track the most recently approved champion keeps the champion share until the new champion is approved. Nothing is burned and the next rank does not move up.

My award is approved. When does my incentive change on chain?

LIVE

A new approval takes effect with the next weight set after validators read it. Weights reach the chain with commit-reveal, so a change becomes visible about one epoch (360 blocks, about 72 minutes) after it is set, and your incentive follows at the next epoch step: in practice about 1–2 hours after the approval. A change that starts at a fixed time (for example the opening places on Friday 23 October, 13:00 UTC, which showed up in the weight set of about 13:55 UTC) shows up the same way. If nothing has changed after a few hours, tell us.

What changes with Engine rules v2.0?

APPROVED effective from Tue 27 Oct 2026, 14:30 UTC (15:30 Berlin)

From Tuesday 27 October 2026, 14:30 UTC, right after that day’s engine slot, the engine track measures your engine on the models decisionmodels.io serves and is preparing as its next lineup, not only on Plumb-4B. The Tuesday 27 October slot is still decided under Engine rules v1. The first crowning under v2.0 is Friday 30 October 2026, 14:30 UTC. Every measurement from Tuesday 14:30 UTC on, including the 15-minute and 12:00 UTC batches, uses v2.0.

• If a current model stays: if our final checks keep a model we serve today instead of one of the new ones, that model takes the slot and weight of the model it replaces. Nothing else changes. The final list is fixed on this page before the Tuesday 27 October 2026, 14:30 UTC slot. For the Friday 30 October crowning only: a model whose reference measurement is not yet stable counts 1.0x for everyone and its weight goes to Blink text; this page says so before Tuesday 14:30 UTC.
• Score: weighted geometric mean of your per-model speed-ups against our reference engine for each model. A model you don’t declare counts as 1.0x. Commit reax-eng/1:dm-all:<image>@sha256:<digest>; declare models with the image label ai.reax.engine.models (absent = all five). s1-vision input is the production contract: images = a list of exactly one data:image/png or image/jpeg base64 URL.
• Why these weights: they follow where our GPU time goes today: mammoth-1 and Blink text carry about 96 % of it, so the two of them hold 0.70 of the weight, split by their GPU-cost share since 23 Oct. Every listed model keeps at least 0.10 so that each counts — including Jeffan-31b, which is new, and the s1-vision image path. Pure traffic or cost share would put REAX 1, Jeffan-31b and s1-vision near zero; the 0.10 floor is a deliberate choice so a winning engine has to run every model we serve.
• Not included: s1-llm-auto-router (a small CPU classifier), Plumb-4B (no longer served), and versions we keep on shared capacity only (e.g. s1-pro-2 Perplexity Decider v1.1).
• Correctness per model: each model has its own answer gate against its reference (mean and per-item distance, top-answer agreement, determinism). Text items and, for s1-vision, the images are generated inside the validator from each session’s seed; there is no fixed or public set.
• Hardware and time: one RTX PRO 6000 (96 GB); models run one at a time. A fully declared entry takes about 3 hours of box time.
• Part of v2.0 (start Tue 27 Oct as already announced): quantisation (quantisation and repacking), the declared parent measured in the same session (reusing another entry), the rescaling-invariant copy check (copies and derived entries). The parent cap counts distinct hotkeys, maximum 16.
• Current champion and v1 commitments: v1 s1-fast commitments don’t carry over. The champion at the switch keeps the champion share until the first v2 champion is crowned, at most until the Tuesday 3 November 2026, 14:30 UTC slot; then it moves to the 17 % former-champion place as if beaten. Approved awards, the 8 % place and the 14-day decay carry over.
• Awards: unchanged (award review).

Which weights, reference engines and release does Engine rules v2.0 use?

APPROVED effective from Tue 27 Oct 2026, 14:30 UTC (15:30 Berlin)

Each v2.0 model slot uses one pinned Hugging Face snapshot and is compared with one pinned reference engine. All repositories are public and ungated, and the reference images can be pulled without logging in.

• How the weights reach your engine: for each run the validator mounts the pinned snapshot read-only at /model (-v <weights>:/model:ro) with HF_HUB_OFFLINE=1. Your engine learns which model it is serving from the environment variable REAX_MODEL. s1-vision uses the Blink weights with one image per item.
• Validator release: v2.0 runs on reax-subnet v1.2.0-rc11.post8, built on Tuesday 27 October 2026 around 18:00 UTC and published with its images on reaxlabs/reax-subnet.
• Measuring an image locally: from v1.2.0-rc11.post8, reax-engine-eval --track dm-all --candidate <image>@sha256:<digest> --weights mammoth=…,blink=…,reax1=…,jeffan=… measures your image with the validators’ own scoring code, the published reference per slot and the per-model time budgets (vision uses the blink weights; --models mammoth measures one slot only, the others count 1.0x). A local result is a preview: hardware, noise and the item seed differ, and the submission review and the weight check of the quantisation rule run only on validators.

How does the engine title work?

LIVE

Every submission is measured against the reference engine on the same GPU in the same session. It must pass the correctness gate and be at least 3% faster than the reference; a challenger takes the title only with at least 3% more than the champion, confirmed in a second fresh session. The champion’s share halves linearly over 14 days; the previous champion gets 17% and the one before 8%, each for up to 7 days after losing the title and after its own award review. Current holders and measured speeds: live queue.

Crowning switch (announced 25 October, not retroactive): Until Monday 26 October 2026, 19:00 UTC (20:00 Berlin), a confirmed winner is still crowned right away. A challenger that confirms from then on waits for the first engine slot, Tuesday 27 October 2026, 14:30 UTC (15:30 Berlin); then the title changes only at slots, every Tuesday and Friday at 14:30 UTC (the same time of day as the generalist slots, which are Monday and Thursday): Tuesday 27 October, Friday 30 October, Tuesday 3 November, Friday 6 November and so on. Measurements do not wait for a slot: they keep running automatically after review and in the daily 12:00 UTC batch (When is my engine measured?). A challenger confirmed between two slots waits as pending and is crowned at the next slot if it is still valid and still beats every bar: the champion bar (the margin of at least 3 %, or 3 times the reference noise where that is larger), the bars of its declared parents and the copy line (engine reuse). If several challengers are confirmed since the last slot, the best confirmed result wins; a later entry displaces a pending one only by the margin over its pooled score, as before. The winner’s curse rule, the decay and the award approval gate are unchanged. The live page shows the next engine slot.

A pending challenger keeps being re-measured in later batches and keeps its place only while every measurement stays above every bar; the title is held at the lowest of its confirming measurements.

When is my engine measured?

LIVE

Automatically, as soon as the release owner has reviewed your entry. A check runs every 15 minutes and starts a measurement batch for every entry that is reviewed, committed and not yet measured. On top of that, a batch runs every day at 12:00 UTC (14:00 Berlin until 25 October, 13:00 Berlin from 25 October, winter time) for every reviewed entry that is still unmeasured; it leaves a receipt even when there was nothing to measure. The first fixed daily run is Saturday 24 October 2026, 12:00 UTC. The same gates apply as before (isolated pre-run review, then the correctness gate and the speed measurement), on the same kind of fresh evaluation GPU. Once a GPU is up, a batch takes about 25 to 40 minutes. Results appear on the live queue, which also shows the next scheduled batch. Measuring is separate from crowning. Until Monday 26 October 2026, 19:00 UTC (20:00 Berlin), a confirmed engine winner is still crowned right away; a challenger that confirms from then on waits for the first engine slot, Tuesday 27 October 2026, 14:30 UTC (15:30 Berlin), then every Tuesday and Friday at 14:30 UTC. Announced 25 October, not retroactive. See how the engine title works.

Can my engine use FP8, INT8, NVFP4/MXFP4 or a repack of the weights? (quantisation and repacking, engine track)

APPROVED effective from Tue 27 Oct 2026, 14:30 UTC (15:30 Berlin)

Yes. Any re-encoding of the pinned model is allowed: lower precision (FP8, INT8, NVFP4, MXFP4), lossless repacks, layout changes, fused or packed matrices, and an approximate path with an exact recheck. Three conditions apply.

1. Derived at start, from /model. Your engine computes every tensor it uses inside the container, at start, from the read-only pinned weights at /model, with code that ships in your image; its source is published for the award, as today (published source). Images that ship weight-like data are not admitted. The file screen rejects, anywhere in the image: files ending in .pt, .pth, .safetensors, .bin, .npy, .npz, .gguf, .ckpt, .pkl, .onnx, .h5, .tflite, .msgpack or .pte, and compound forms such as .pt.1 or .safetensors.0; any non-code file over 64 MiB (code, text and configuration files such as .py, .so, .cu, .txt and .yaml are exempt from the size rule, .json is not); and numbered multipart files (name.1, name-00002-of-00004), which are counted together, so splitting a file does not get it under 64 MiB. The only exception is /model/tokenizer.json with exactly the pinned content; a different tokenizer.json, or one at another path, is rejected. The review also checks for weight data hidden in other files, renamed or embedded (for example embedded in a source file or a library); an image where it finds such data is not admitted. Precomputed scales and calibration statistics count as weight-like data. Start-up, including the conversion, must finish within the existing 15-minute start limit (900 seconds); one evaluation stays at most 45 minutes.
2. Calibration only without data or from the public seed set. Use a calibration-free conversion, or compute the calibration at start from activations your engine produces itself on the public seed set (0x52454158).
3. Same correctness gate, plus a private holdout set. The gate is unchanged: mean distance at most 0.10, every item at most 1.0, top choice agreeing on at least 99 % of items, determinism within 0.05. With the Friday 30 October 2026 release each session also scores a private holdout set of 64 items that does not come from the public generator, against the same gates. The holdout set is not part of the Tuesday 27 October change: until the Friday release the gate runs on the generated items only.

Entries that already ship weight files. Their titles and awards stay; this is not retroactive. They have until the Friday 30 October 2026, 14:30 UTC engine slot to submit a compliant version. From that slot on only compliant entries can take the title; a sitting champion keeps it.

Why. A weight file inside an image cannot be proven to be the pinned model re-encoded: it could hide a fine-tuned or distilled model that matches on generated items and drifts on real traffic. Deriving everything at start from /model rules that out, and the private holdout set catches tuning to the generator. Crowning for engines happens at the Tuesday and Friday slots (engine title).

What reference speed is the engine measured against?

LIVE

Only the ratio counts. Every submission is measured against the reference engine on the same GPU in the same session, interleaved. On our evaluation GPU (RTX PRO 6000 Blackwell Server Edition) the reference runs at about 100 decisions/s.

My engine entry is marked “not owner”. What do I do?

LIVE

The image label ai.reax.engine.hotkey must name the hotkey that committed the digest. Rebuild the image with the label set to your committing hotkey, push it, and commit the new digest.

How do waiting engine entries avoid being pruned?

LIVE

Every engine entry waiting for its measurement gets half the median inference weight, from its commitment, for 24 hours per image (was 12 hours per hotkey); the pending challenger (its first session beat the bar) keeps it while it waits for its confirming session, its Tuesday/Friday slot and the finalisation, at most 5 days after its first session. It is also paid to the champion while its award review is pending and to former champions that hold a slot. All engine keep-alives together stay within 5% of the engine share; no waiting entry is cut to zero by a count limit.

Can one hotkey serve inference and compete at the same time?

LIVE

Yes, since block 9331987 (about 13:00 UTC on 21 October 2026): one hotkey can serve inference and hold one competition entry. Serving and competition pay add up per UID; the keep-alive of a dual-role entry is a top-up over what it earns from serving.

Can one hotkey carry several models?

LIVE

Yes, since the same block: 2 to 4 inference models per hotkey (commitment reax-s1m/1), each with the same per-model cap as a separate hotkey. You publish one axon per hotkey; it still holds only one competition commitment.

Why is there a per-hotkey cap, and how do I run 8 GPUs?

LIVE

Validators verify each hotkey’s throughput with their own probes, and that has a limit: 1,280 decisions/s for s1-fast, 320/s for s1-pro, 32/s for s1-lite and 4/s for s1-cpu. Pay stays linear in verified throughput, so above the cap use more hotkeys or more models per hotkey.

I think my entry was scored or paid wrongly. Where do I report it?

APPROVED effective from 22 October 2026, 19:55 UTC (21:55 Berlin)

Report it in #92 within 24 hours of the result post, with evidence: your UID, the entry (repo@revision or image digest), what you expected, what you see, and links or timestamps. Grounds are a wrong number, the wrong entry, a rule applied differently from this page, or code that does not do what this page says. Use a direct message only for private details such as keys or ownership proofs.

I re-check it against the logs and the code, separately from the run that produced the result, and answer once in #92 within 24 hours; the decision applies in the meantime. If the report is upheld, we correct it from the next weight set and pay the measured loss from our own share; if the error changed who was crowned, we decide the slot again, and amounts already paid are not taken back. The rules themselves, the thresholds and normal measurement noise are not grounds; suggestions go to our weekly rule review. Slot rules, section 10.

Are answers from a bot or an AI assistant binding?

LIVE

No. Only the published rules, this FAQ and our announcements in #92 are binding. An automated or AI-written reply can be wrong; it never replaces the rules and never stops you from reporting a real problem.