Miner FAQ

How is the miner emission split?

LIVE

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 (on the engine track the champion gets whatever the held former places leave, see engine title). 17% and 8% are not places 2 and 3 of a ranking: runners-up of a crowning are not paid. A former champion is paid only while the same hotkey stays committed with that entry and a valid award approval. On the generalist track a former-champion place ends when newer former champions push it out; on the engine track also 7 days after losing the title.

A share that nobody may be paid (no champion yet, award not approved, place ended) goes to the inference miners, apart from the short keep-share during an award hold; it never moves up to the next rank. From Friday 30 October 2026 this changes: inference gets 40% and such a share is burned (next answer).

Is any emission burned? (SN92 pays for what it needs)

APPROVED from the first weight set after the engine slot on Fri 30 Oct 2026, 14:30 UTC

Yes, from Friday 30 October 2026: SN92 pays for what it actually uses. Agreed with the subnet owner and announced in #92 on 26 October 2026.

• Inference follows customer demand. The inference share of the miner emission goes from 50% to 40%. From there it follows measured customer demand step by step, at our discretion, and grows again as demand grows; we announce each change in #92. Pools, caps and scoring inside inference do not change.
• Competitions are paid while they bring real improvements. REAX Engine (20%) and generalist (30%) keep their full shares for now, and 75/17/8 inside a track stays. When progress on a track flattens, we pause it until there is new work, for example a new model in our lineup, and say so in #92. During a pause the champion and the former-champion places get the keep-alive, so nobody is pruned because of a pause.
• What is not paid is burned. The 10 points inference no longer gets, a paused track’s share, an unclaimed share, the decayed part of the engine pot and the part of an award that is not approved yet (after the usual keep-share) are burned instead of going to the inference miners. Wherever this FAQ or the slot rules say an unpaid part goes to inference, from then on it is burned.

Shares and pauses are our decisions, not promises; rewards can be zero.

Who holds the titles now?

LIVE

The live page always shows the current champions, former-champion places and pending entries. On the generalist track the opening playoff ended in a practical tie, so UID 116, 199 and 250 hold the title together until a challenger beats them: they share the 75% equally, each part paid only with its own award approval (an unpaid part is never given to the others). A challenger has to beat the best of them on its own draws; all three are served on every challenger draw. When beaten, they become one former champion and share one place equally.

Where do I ask a question or report a problem?

LIVE

Ask in #92 on the Bittensor Discord, so everyone sees the answer. Use a direct message only for private matters (keys, ownership proofs, code releases) or if you cannot post in #92. We answer during the day, about 06:30–21:30 UTC. An error in your own result: report it. Only the published rules, this FAQ and our announcements in #92 are binding; an automated or AI-written reply can be wrong and never replaces them.

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, or gated with read access for our evaluator (private submissions), and carry an Apache-2.0, MIT or BSD LICENSE file (add one if your base repo does not ship 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", names your hotkey and declares your base model. One hotkey holds one competition entry; a new commitment from the same hotkey replaces the old one. A private or unreachable repo is not evaluated; from the next worker release (hotfix, decided 26 October 2026) such an entry is no longer rejected after about 24 hours but waits until the repo is public or gated with access for us (its keep-alive window stays 24 hours).

Which base model should I use?

LIVE

Any allowed architecture within the limits; you do not have to fine-tune the official base (decisionmodels/reax-1 at revision ca2a0cc5). Your declared base matters: under eval v5 you must beat your own base as well as the champion, and the copy rules compare you with it. Our recommended bases are a starting point, not a rule.

Which base models do you recommend?

LIVE

A recommendation, not a rule: pplx-, REAX- and mammoth-based entries stay fully eligible, and we do not lock the track to any base, including our own. Measure on the public dev set and your own held-out data before you switch. Announced in #92 on 28 October 2026 (#92 post).

Gemma-4-31B line (all Apache-2.0, plain safetensors without auto_map, Gemma 4 architecture, inside the 36B limit), in the order of the HF Decision Index, which now scores only on private tests:

• PelaAI/KnowLine-31B-Gen1 at revision 8f052a81. It serves on our evaluator as published and held up under our fixed chat template in our latest check.
• sthanika-ai/Sieve-31B-v3 at revision eb99cd7e: full fine-tune with no custom code. As published it does not start on our evaluator: its repository has no processor_config.json, which vLLM needs to set up the Gemma-4 processor even for text-only serving. Adding the unchanged processor_config.json from google/gemma-4-31B-it at revision 842da379 (SHA-256 32bdf45d…9813c) to the root of your entry fixes startup in our test; keep config.json as it is (no text_config or RoPE rewrite). Check that your entry serves with plain vLLM before you commit.
• turion-ai/turion-jev-31b at revision 9edd5783.
• tattrongvu/Jeffan-31b-1710 at revision cebfa86c (keep the attribution).
• google/gemma-4-31B-it (Apache-2.0) remains a clean starting point.

Our own first validator runs show smaller gaps between these models than the index does; we are moving our evaluation closer to the index.

baselabs/mammoth-1 (MIT, 27B, Qwen3.5 architecture, pin 03007ab3): still very strong on the public benchmarks, but behind the models above on the index’s private tests, so no longer our first choice.

Staying on Qwen: Qwen/Qwen3.8-27B (Apache-2.0) is a fine base; the training recipe matters more than the base.

For the “I don’t know” items, on any base: train the model to abstain when unsure (how it is scored).

A stronger base raises your own bar: under eval v5 your entry must beat its declared base as well as the champion. Declare the base you really started from (repo@revision).

Not recommended as a base: models whose licence does not let you publish your fine-tune under Apache-2.0, MIT or BSD (for example CC-BY-NC models such as StartLux or Lychee, H2O Lightning’s non-commercial licence, or GLiDE’s community licence); your entry’s own licence must be one of those. Models that ship as custom code (auto_map, for example vLLM-SR d3-ultra or WeMM-JEV as published) cannot be run, because no repository code is ever executed. When the list changes, we update this answer and say so in #92.

What counts as a copy or a derived entry?

LIVE

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

Merges are allowed, but a model close to an earlier entry is checked as derived, and the award review looks at the merge share and the credit: state your recipe and credit in the repo. Training data is not restricted beyond the licence of the model you publish; what protects the evaluation is that every scored item is private.

How many entries can one coldkey hold?

LIVE

At most 2 open submissions per track and 4 new submissions per 7 days per coldkey. In a crowning slot one holder keeps only its best entry: 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; slot rules, section 4). Keep-alive limits per coldkey: keep-alive.

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 does the evaluation measure?

LIVE

Eval v5 (version 0.1) is binding since Monday 26 October 2026, 14:30 UTC, for every new evaluation; the champions are scored on v5 on every challenger draw. It is built to rank models the way the Hugging Face Decision Index and the Artificial Analysis Decision Index do. From Wednesday 28 October 2026, 12:00 UTC, about 80% of the score comes from private tests of the same skills as the public Decision Index benchmarks (knowledge and reasoning, retrieval, tools) and about 20% from private decision tasks in new domains (before that it was 60% and 40%; each draw is scored with the weighting in force when its evaluation cycle started). This tracks the Hugging Face Decision Index more closely and lowers the noise of each draw. The new-domain part has 11 tasks, among them security advisories, EU public tenders, Wikipedia community decisions and games with exact solvers. Every scored item is private. 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.

“I don’t know”. Fact questions offer it as an extra last option: a correct answer scores +1, a wrong one −1, “I don’t know” 0. Your top option is your answer (no threshold or temperature on top), so abstaining when unsure pays.

Public kit (weight 0 in the score, no items or sources shared with the private set): the item format, the 300-item dev set and the reference scorer. Use it to check your pipeline end to end, not to rank models finely. We keep improving v5 and announce each new version here and in #92 before it applies.

Feedback report. After your entry is evaluated, we send you a feedback report: where your model loses points on the Hugging Face Decision Index (public-benchmark aggregates), and a few concrete quick wins. It never contains private evaluation items.

What score do I need to win?

LIVE

• Draw. 900 private items: 540 same-skill tests and 360 new-domain tasks, plus public items at weight 0 (each draw is scored with the weighting in force when it starts). Items, draw seeds and per-item results stay private; aggregate scores are published.
• Bar. Beat the best current title holder and your own declared base, on the same items, by at least the minimum margin of 1.0 point. There are no fixed score floors and no gap penalty under v5. Scores are scaled against a fixed panel of untuned stock models, on roughly the Decision Index scale; they cannot be compared with scores from the earlier evaluation.
• First draw. z is your gain divided by its standard error. z ≥ 2 with a gain of at least 1.0 passes. A close call (1 ≤ z < 2, gain at least 0.5) gets one more first-stage draw; z < 1 is not better.
• Confirmation. A fresh draw, disjoint from your first, at least 12 hours after your first draw (one-time exception for the Friday 30 October 2026, 16:30 UTC slot: 2 hours, fresh items, same margin; hotfix, decided 28 October 2026). You need a pooled z ≥ 2.75 and a pooled gain ≥ 1.0 over all your draws, and the confirmation draw on its own must still be ahead (z ≥ 0.5). If you fall short but your pooled z is at least 1.5 and your confirmation draw is still ahead, you get one extra confirmation draw. Then you wait for the next slot.
• 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, the award review checks the entry for overlap with our private sources. Your score does not change.
• Per-area scores 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.

Why is my entry still queued?

LIVE

Our competition worker evaluates continuously, up to 8 evaluations per hour across the tracks (champion runs count). Confirmations due before a slot run first. Among new entries, hotkeys already past their immunity period go first, then those whose immunity ends soonest, then commitment order. The live page explains each status (queued, waiting for repo, waiting for base model, evaluating, pending confirmation). While you wait, the keep-alive protects your UID.

When is the next generalist crowning?

LIVE

Every Monday and Thursday at 14:30 UTC (15:30 Berlin in winter time); the live page shows the next one. Submissions stay open all the time; a challenger is crowned only at a slot. A slot includes every entry whose confirmation has passed before 14:30:00 UTC that day, and every entry whose confirmation was due by 13:30:00 UTC but has not run yet because of our queue (we run those first). If nobody is in the slot, nothing changes. Full rules: slot rules, sections 1 and 2.

One-time extra slot (hotfix, decided 28 October 2026). The Thursday 29 October 14:30 UTC slot stays unchanged for the entries already stored for it. I add one extra generalist slot on Friday 30 October 2026, 16:30 UTC for every entry confirmed after Thursday’s slot. Its commit cutoff is Friday 30 October, 10:30 UTC (the usual 6-hour rule); for this slot only, the confirmation draw can come 2 hours after the first draw (fresh items, same margin) instead of 12 hours. Entries committed by the cutoff are measured in time; anything we cannot measure plays the next slot, Monday 2 November. See the commit cutoff.

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 slot, as a hotfix: an entry plays a slot only if its commitment was first seen on chain at least 6 hours before the slot (08:30 UTC on the slot day). A later entry is evaluated normally and plays the following slot; it keeps its keep-alive until that slot has decided it. The block in which the commitment was first seen counts, not when the repo went public or when we evaluated it. If a new champion is crowned in the meantime, the held entry starts again with a new first draw against it. If you do not want to publish your weights before they are measured, use a private submission; the cutoff applies to it as well.

In practice you need more than that anyway: to play a slot your confirmation must have passed, and it runs at least 12 hours after your first draw, so commit well over 13 hours before the slot you aim for. Fairness check (hotfix): nobody loses a measured result; an entry first seen after the cutoff simply plays the next slot.

One-time extra slot (hotfix, decided 28 October 2026). The Thursday 29 October 14:30 UTC slot is unchanged for the entries already stored for it. I add one extra generalist slot on Friday 30 October 2026, 16:30 UTC for every entry confirmed after Thursday’s slot. Commit cutoff for it: Friday 30 October, 10:30 UTC (the usual 6-hour rule). For this slot only, the confirmation draw can come 2 hours after the first draw (fresh items, same margin) instead of 12 hours, so an entry committed by the cutoff is measured in time. Anything we cannot measure plays the next slot, Monday 2 November. After that the Monday and Thursday slots and the 12-hour rule apply again.

Can I keep my weights private until they are measured (commit-reveal)?

LIVE

Yes, for generalist entries, since Tuesday 27 October 2026, 20:00 UTC (21:00 Berlin), as a hotfix. The first slot a private entry can play is Thursday 29 October 2026, 14:30 UTC. Public repos work exactly as before.

1. Upload the complete model with its reax-specialist.json and an Apache-2.0, MIT or BSD LICENSE, as usual.
2. Make the repo gated with manual approval: HfApi().update_repo_settings(repo_id, gated="manual"). Not auto: with automatic approval anyone, a copier too, can download it. A plain private repo does not work, because it cannot be shared with one account.
3. Give our evaluator account florian-chutes read access: HfApi().grant_access(repo_id, "florian-chutes"), or approve its request. Only this account, not through an organisation; never send anyone a token.
4. Commit repo@revision on chain as today; the revision pins your weights.

Access deadline. To play a slot, your commitment and our first observed access must both be there by the 6-hour cutoff (08:30 UTC on the slot day). We check about every 10 minutes, so grant access at least an hour earlier; a failure on our side is not counted against you. Until access works the entry shows waiting for access: no strike, no rejection, the usual waiting keep-alive. Do not revoke access before your result.

Reveal. Within 24 hours after the slot result the same revision must be public (ungated, not private) with its LICENSE. We check anonymously that its tensor hash equals the one we measured; another revision, a new repo or a rewritten history does not count. This applies to every entry that played, winners or not.

Until the reveal the entry keeps its keep-alive but gets no title, award or place share; the rank-1 place share goes to the most recent former champion meanwhile. No reveal in time (or gated again later and not public within 24 hours): the entry is void, with no title, award or keep-alive; a seat it won stays vacant until the next ordinary decision, and its coldkey cannot submit privately for its next 2 slots (public entries stay allowed).

What we see. Only our evaluator account reads gated entries. Its token is read-only, limited to gated repos and kept only on the evaluation host, never on training hosts. Every gated download is logged (time, UID, repo, revision) and the log is published with the slot result; until the reveal a private entry shows only its UID, score and reveal status. Private copies of void entries are deleted. Fairness check (hotfix): optional for everyone and the same rule for every miner; it removes the need to publish weights before they are measured, so they cannot be copied into the same slot.

How is a slot with several entries decided, and what if they are practically tied?

LIVE

All entries in the slot play up to three shared rounds of 900 fresh items. After each round, an entry leaves when the leader is ahead of it by at least the margin: the larger of 1.0 point and 2 paired standard errors. One entry left: it is the clear winner and takes the whole 75% champion share. Still not separated after round 3: entries whose average is 0.5 points or less behind the leader share the 75% equally (two: 37.5% each, three: 25% each), each part paid only with its own approval; an entry more than 0.5 points behind does not share, and if nobody else is within 0.5 points, the leader is crowned alone. Nobody outside the winning group is paid as a runner-up.

Rounds, checks and worked examples: slot rules, sections 4 and 5.

What were the generalist opening places?

LIVE

A one-time exception for the opening cohort: UID 160 holds the 17% place and UID 113 the 8% place, each paid only with a valid award approval, until Friday 30 October 2026, 13:00 UTC at the latest (earlier if a new champion is crowned: slot rules, section 6). After that, places 2 and 3 go only to dethroned champions.

What does the engine track measure (Engine rules v2.0)?

APPROVED from Tue 27 Oct 2026, 14:30 UTC (15:30 Berlin), right after that slot

Engine rules v2.0 apply from Tuesday 27 October 2026, 14:30 UTC, right after that day’s slot (still decided under Engine rules v1): your engine is measured on the models decisionmodels.io serves. Measurements from the Tuesday 27 October evening worker update use v2.0 (we confirm the time in #92); the first possible crowning under v2.0 is Friday 30 October 2026, 14:30 UTC. Commit reax-eng/1:dm-all:<image>@sha256:<digest>.

• Score. The weighted geometric mean of your per-model speed-ups against our pinned reference engine for each model, measured on the same GPU in the same session, interleaved; only the ratio counts. Declare the models you serve with the image label ai.reax.engine.models (absent = all five); a model you do not declare counts as 1.0x.
• Every declared model must pass. Its answer gates against the reference (logit distance at the model’s temperature, set from the measured drift of our own reference), its speed floor (1 minus the larger of 2% and 3 times its reference noise: one declared model below it fails the whole image, however fast the others are), and its budget for the GPU memory your engine adds next to the loaded reference.
• Items. Scored items, and for s1-vision the images, are generated inside the validator from each session’s secret seed. s1-vision input is the production contract: images is a list of exactly one data:image/png or image/jpeg base64 URL. Reusing the exact model state of an identical token prefix across requests is allowed (as prefix caching does in our references); caching answers or anything that depends on the question is not.
• Hardware and time. One RTX PRO 6000 (96 GB); models run one at a time, each with its own time budget. A fully declared entry takes up to about 3 hours of box time.
• The switch from v1. Commit a dm-all image; an s1-fast commitment is not measured under v2.0. The v1 champion at the switch keeps the champion share until the first v2.0 champion is crowned, at most until the Tuesday 3 November 2026 slot. Then it moves to the 17% place as if beaten, the old 17% place moves to 8% and the old 8% place ends. Approved awards and the decay carry over. A carried place stays with the hotkey only while it keeps its original s1-fast commitment or commits a dm-all image.

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

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

Each model slot uses one pinned Hugging Face snapshot and one pinned reference engine. All repositories are public and ungated; the reference images can be pulled without logging in.

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 serves from the environment variable REAX_MODEL. Measuring locally: the v2.0 validator release in reaxlabs/reax-subnet ships reax-engine-eval --track dm-all --candidate <image>@sha256:<digest> --weights mammoth=…,blink=…,reax1=…,jeffan=… with the validators’ own scoring code and references (--models mammoth measures one slot). A local result is a preview: hardware, noise and the item seed differ, and the submission review and the weight check run only on validators.

How does the engine title work?

LIVE

• Bar. An entry must pass every answer gate and be faster than the reference by the margin; a challenger must beat the champion by the margin, confirmed in a second fresh session. The margin is the larger of 3% and 3 times the measured reference noise; under Engine rules v2.0, with five models combined, that is 7.65%. The title is held at the lowest of the confirming measurements.
• Slots. The title changes only at the Tuesday and Friday 14:30 UTC slots; the live page shows the next one. Measurements do not wait for a slot. A confirmed challenger waits as pending and is crowned at the next slot if it still beats every bar (champion, its declared parents, the copy line); it keeps being re-measured and keeps its place only while every measurement stays above every bar. If several challengers 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.
• Pay. The engine pot starts at the full 20% share at each crowning, falls linearly to 50% of it over 14 days and then stays there; the decayed part goes to inference (from Friday 30 October 2026: burned instead, why). The previous champion gets 17% and the one before 8% of the pot, each for up to 7 days after losing the title and only with its own award approval; the champion gets the rest (75% with both places held, 83% with one, 100% with none).

When is my engine measured?

LIVE

Automatically, once we have reviewed your entry (an image we cannot pull, or an open review question, holds it; the live page shows the status). A check runs every 15 minutes and starts a batch for reviewed entries that are not yet measured, with a limited number of automatic batches per day; a daily batch at 12:00 UTC catches anything left. Every batch runs the isolated pre-run review, then the answer gates and the speed measurement, on a fresh evaluation GPU. Results appear on the live page.

Can my engine use FP8, INT8, NVFP4/MXFP4 or a repack of the weights?

APPROVED from Tue 27 Oct 2026, 14:30 UTC; titles only for compliant images from the Fri 30 Oct 2026 slot

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:

• Derived at start, from /model. Your engine computes every tensor it uses inside the container, at start, from the read-only pinned weights, with code that ships in your image and whose source is published (published source). Start-up, including the conversion, must finish within 15 minutes per model.
• No weight-like data in the image. 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; any non-code file over 64 MiB (.py, .so, .cu, .txt, .yaml are exempt from the size rule, .json is not); and numbered multipart files, which are counted together. Do not ship a tokenizer.json: read the tokenizer from /model. The review also looks for weight data hidden in other files. Precomputed scales and calibration statistics count as weight-like data.
• Calibration only without data, or computed at start from activations your engine produces on the public seed set (0x52454158).

The answer gates are unchanged by this rule. A private holdout set that does not come from the public generator is planned; we announce it here and in #92 before it applies. Entries that already ship weight files keep their titles and awards; from the Friday 30 October 2026, 14:30 UTC slot only compliant images can take the title. Why: a weight file in an image cannot be proven to be the pinned model re-encoded; it could hide a tuned model that matches on generated items and drifts on real traffic.

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/"]}] (a path ending in / covers the directory; under Engine rules v2.0 at most 16 distinct parent UIDs and 64 parent entries). Fill it per file origin: list each file under the entry where that content first appeared (files you took from B that B took from A go under A). Your entry must beat every declared or detected parent by the full challenger margin. Reusing your own earlier entries is free; for another hotkey of the same owner add signed ownership proofs in ai.reax.engine.ownership (the same coldkey needs none). Undeclared reuse counts as a copy: the first time the entry is not evaluated, the second time the hotkey is paused for 7 days.

Parent measured in the same session (from Tuesday 27 October 2026, 14:30 UTC). When your derived entry clears the champion bar but falls short of, or lands within the margin of, its parent’s stored line, the validator tries to run the parent’s best image right after yours, on the same machine with the same items; that session’s line is then the higher of the parent’s same-session score and its lowest valid score, times one plus the margin. If the parent cannot be run or the session’s run budget is used up, the stored line applies. These runs never change the parent’s own scores. Details: ENGINE-COMPETITION.md, section 5a.

Does an engine entry need published source, and how do I make it award-ready?

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. The live page shows any held award. To be award-ready before the crowning:

• Publish the source of every native (every .cubin and .so) in a repository under MIT, Apache-2.0 or the REAX Engine License, before you commit.
• Give the exact build line and toolchain (command, flags, target architecture, working directory, compiler or CUDA image version) in a README or build script. Our private CI rebuilds each native from your public source and compares it byte for byte with your image; build from the same source path as in the image.
• Ship the same files you published, byte for byte. A file that differs, or a native with no source of the same name, counts as unpublished.
• Say where the repository is: a README inside the image, your commitment discussion on Discord, or both (there is no image label for it).
• Labels: ai.reax.engine.parents per file origin (reuse), and ai.reax.engine.hotkey set to the committing hotkey in the final image configuration (“not owner”).
• For titles from the Friday 30 October 2026 slot: no weight-like files, calibration only on the public seed set (quantisation and repacking).

We review the image before its first run; after the crowning we check the rebuild, then the owner signs the award approval (award review). If everything above is in place, there is nothing left to ask you.

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.

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

LIVE

A participation weight so that a UID is not deregistered just because its entry is waiting for us. It is not an award and needs no approval. It is part of the mechanism for every waiting state, from the first weight set after your commitment is on chain until the decision:

• Committed, not evaluated yet: a provisional keep-alive (half the weight of a typical inference miner, any model size), 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 takes (safety limit 96 hours). While we cannot reach a private repo, it lasts 24 hours from the commitment (one such window per hotkey every 72 hours, at most 16 such entries per track; a commitment our evaluator has not recorded yet gets at least 6 hours and does not count against the 16). A commitment that is not a loadable model (the revision does not exist, no safetensors weights, weights identical to the declared base, or a different revision than committed) gets no window, and its coldkey gets no such unverified window for 30 days; two such commitments in 30 days end the coldkey’s provisional keep-alive for that time.
• Pending confirmation, confirmed and waiting for a slot, or held by the commit cutoff: the weight of a typical inference miner until the slot that decides the entry has run. 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.
• Engine entries: half the median inference weight while an image waits for our first measurement, until it is measured, at most 120 hours per image; a pending challenger keeps it through its confirming session and its slot, at most 5 days. Both windows start at the commitment (the challenger: its first session) or, if later, about 5 hours before your hotkey’s immunity ends. It also covers the champion while its award review is pending, and a former champion whose place share is not being paid.
• Switching: a hotkey that commits a new entry is covered by the new entry from the next weight set, so there is no gap. Champions of the ended demand-forecasting and risk-assessment tracks keep a legacy keep-alive until Wednesday 28 October 2026, 13:00 UTC.

Limits: at most 2 open entries per coldkey per track. A waiting keep-alive goes to at most 2 entries per coldkey per track after their first draw (a champion waiting for award approval counts as one of them, the older commitment keeps the other place) and to at most 2 entries not evaluated yet (every coldkey’s first entry before any second one; inside a coldkey a checked entry (or one waiting on our side) first, then a commitment we have not seen yet, then the UID closest to being pruned; across coldkeys checked entries first, then the oldest commitment, which also decides who gets the 16 unverified places), and share caps for all keep-alives of a track together. When a share cap is reached the weight is split evenly, so no waiting entry whose model we have checked is cut to zero by it. A hotkey that also serves a little inference is topped up to the keep-alive level. Not covered: the time until our first weight set after a new commitment counts on chain (our next set, plus one to two epochs for commit-reveal: up to about 3–4 hours, so commit while your hotkey is still immune, at least 4 hours before its immunity ends, or while it still earns), a repo kept private for more than 24 hours, a declared base model that is not on Hugging Face (only the 24-hour window applies), an engine image still unmeasured 120 hours after its window started (see engine entries), an entry under review (it can keep only the provisional keep-alive), 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.

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

LIVE

Not necessarily. If you had passed your first draw and 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.

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

LIVE

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. Tell us in #92 with your UID and the time (slot rules, section 11).

What is an award approval, and how long does it take?

LIVE

A winning entry is paid only after we check and approve it: the champion and every paid former-champion place, 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.

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); 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 most recently dethroned champion with a valid approval keeps the new champion’s part of the 75% for up to 48 hours from the crowning (a co-champion set in equal parts) and gives up its own place share for that time. After 48 hours an unapproved part goes to inference (from Friday 30 October 2026: burned instead, why) 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. The next rank never moves up.

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

LIVE

The next weight set after validators read the approval includes it (sets come about every 72 minutes), and with commit-reveal it counts on chain one to two epochs later (360 blocks, about 72 minutes each): in practice about 2–4 hours after the approval. If nothing has changed after about 4 hours, tell us.

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

LIVE

Yes: 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. One hotkey can also carry 2 to 4 inference models (commitment reax-s1m/1), each with the same per-model cap as a separate hotkey; you publish one axon per hotkey.

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

LIVE

Validators verify each hotkey’s throughput with their own probes, and that has a limit: 2,560 decisions/s for s1-fast, 640/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.

How do rules change? What is a hotfix?

LIVE

Normal changes are announced in #92 and here before they apply; the next generalist slot after the announcement still runs on the current rules (slot rules, section 1). We keep rules simple and decide details at our discretion where a fixed number would not help anyone. A hotfix fixes a rule that demonstrably fails (it lets through what it should stop, or blocks what it should allow) and applies at once, published with a written fairness check: what changes, who could be affected, why waiting would be worse. If honest miners would be treated unfairly, we find a fair way to apply it, for example by protecting results reached under the old rule. The change log says for every version whether it holds a hotfix, a rule change or a clarification.

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

LIVE

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, links or timestamps. We re-check it against the logs and the code and answer once in #92 within 24 hours; the decision applies in the meantime. If upheld, we correct it from the next weight set and pay the measured loss from our own share. Grounds and what happens to a slot: slot rules, section 10.

What do LIVE, APPROVED and PENDING mean?

LIVE

LIVE: in force now. APPROVED: decided and announced, takes effect at the date shown. PENDING: still open, not a rule yet. Times are in UTC (Berlin is UTC+1 in winter). The full rules are on the rules page; files and constants are in the public reax-subnet repository. If this FAQ and the running release seem to differ, tell us in #92. Earlier versions and the full change log: FAQ history.