# REAX developer documentation

> REAX is a Bittensor subnet in development: miners serve fast, calibrated, Jev-compatible finite-answer decision models and validators score faithful serving. Operated by productivity-boost.com, Germany.

Status, 2026-10-05: launching soon, pre-release. No REAX subnet is registered on testnet or mainnet and there is no netuid; the netuid is announced at launch. Release 1.1.0rc1 (pre-release) is built and tested on a local chain with the real production runtimes (miners serve exactly the System1 models s1-fast or s1-pro; competition mining is planned and switched off). Design specification revision 0.6 is provisional and not frozen; all rollout gates G0 to G6 are closed. Source code is private until launch; prospective operators can request access at https://reax.co/apply/.

## Start mining

- Human guide: https://reax.dev/mine/ (Mine REAX in 30 minutes: requirements, wallet, TAO, registration, Docker, health checks).
- Machine-readable onboarding: https://reax.dev/miner.json (requirements, images, ports, env, steps, scoring).
- Full docs as one text file: https://reax.dev/llms-full.txt
- WebMCP tools on every page: get_launch_status, get_requirements, get_registration_steps, get_run_instructions, check_miner_health_instructions.
- Agent rules: never ask for or handle recovery phrases, seeds or coldkeys; a human approves every payment in their own wallet; make no earnings or token-value statements.

This file contains every page of https://reax.dev as plain text, generated 2026-10-05.

---

URL: https://reax.dev/mine/

Miner onboarding · release 1.1

# Mine REAX in 30 minutes

A step-by-step guide for people who have never mined on Bittensor before, and a fast lane for those who have. You will create a wallet, register a miner key, start the miner next to its model on a GPU server and check that validators score it.

Launch status · Launching soon

REAX is not live yet. The subnet is not registered on Bittensor mainnet or testnet, so there is no netuid. Wherever this guide shows `<NETUID>`, the number will be announced at launch. The miner code and container images become public at launch too. Until then you can read the whole guide, prepare a wallet and a GPU server, and practise every step on a local chain (see below (#practice)). Nothing on this page means that mining is possible today or that it will pay anything.

What "30 minutes" means

About 30 minutes of hands-on work once you have a GPU server and some TAO. Two things can take longer and are outside our control: identity checks at an exchange when you buy TAO for the first time (minutes to days), and the first start of the model, which downloads about 9 GB and checks every weight file (typically 5 to 10 minutes).

## The six steps at a glance

[Figure] Steps 2 to 4 are the Bittensor part. If you already mine on another subnet, skip to step 4 (#step-4).

## What you need

| Item | s1-fast (open at launch) | s1-pro (later) |

| Model you serve | Plumb-4B, public weights, Apache-2.0 | Surogate Rune 26B-A4B v3, gated weights (accept the gate with your own Hugging Face account), Apache-2.0 |

| GPU | one NVIDIA GPU with at least 24 GB. Measured: RTX 4090, RTX PRO 6000 Blackwell, H100 80 GB | one NVIDIA GPU with 80 to 96 GB. Measured: RTX PRO 6000 (96 GB), H100 80 GB |

| NVIDIA driver | supports CUDA 13 (R580 or newer), plus Docker with the NVIDIA Container Toolkit |

| CPU, RAM, disk | 4 cores, 32 GB RAM, about 20 GB free disk (9 GB weights + images) | 4 cores, 32 GB RAM, about 80 GB free disk (52 GB weights + images) |

| Network | a public IPv4 or IPv6 address and one open TCP port (default 8091) that validators can reach; correct clock (NTP), because signed requests older than 10 seconds are refused |

| Operating system | Linux x86_64 on the server. Your own laptop can be Windows, macOS or Linux |

| Pool status | planned on at launch | off — switched on in a later release |

Other cards (L4, L40S, A100, H200, RTX 5090 and more) should work but have not been measured. Run the calibration script from the repository on them before you serve; see Verification & calibration (https://reax.dev/verification/).

Renting a GPU? Choose a virtual machine or bare-metal server where you control Docker and can open a port. Many cheap "GPU container" offers run your code inside their container and do not let you start Docker yourself or publish a port; the REAX setup does not work there.

You also need: a laptop with Google Chrome (for the beginner wallet), an SSH client (built into Windows 10/11, macOS and Linux), and a small amount of TAO for the registration fee.

## Two keys, two places

[Figure] The coldkey never goes to the server. The server only ever holds the hotkey file.

Bittensor uses two keys. The coldkey holds your TAO and signs money operations such as paying the registration fee. The hotkey is your miner's identity on the subnet: it gets the UID (your slot) and signs every answer. A stolen hotkey cannot spend your TAO; a stolen coldkey can. That is why the coldkey stays in your wallet app and only the hotkey goes to the server. More detail: Wallet & registration (https://reax.dev/wallet/#keys).

## Step 1 · Prepare the GPU server

Log in to your server and check the GPU, the driver and Docker:

```
nvidia-smi                                   # shows your GPU and "CUDA Version: 13.x" or newer
docker --version && docker compose version  # Docker Engine with the compose plugin
docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi   # GPU visible inside Docker
timedatectl | grep -i synchronized           # "System clock synchronized: yes"
```

If the last `docker run` fails, install the NVIDIA Container Toolkit (NVIDIA's install guide for your distribution) and restart Docker. Open the miner port in your firewall and in your provider's panel: TCP 8091 inbound. Never open port 8101; that is the model's private port.

Install the Bittensor command line tool (`btcli`) in its own Python environment. It ships inside the official `bittensor` package:

```
python3 -m venv ~/btcli-venv
~/btcli-venv/bin/pip install "bittensor==11.1.0" "typer<0.27.2"
echo 'alias btcli=~/btcli-venv/bin/btcli' >> ~/.bashrc && source ~/.bashrc
btcli wallet list                # prints "0 coldkeys · 0 hotkeys" on a fresh server
```

The `typer` pin matters: typer 0.27.2 (released 28 August 2026) breaks btcli 11.1.0 with `AttributeError: module 'typer._click.exceptions' has no attribute 'Exit'`.

## Step 2 · Create your wallet (coldkey)

Beginner: Talisman in ChromeA browser wallet with a normal app-like interface. Your coldkey stays in the browser; you approve each payment in a pop-up. About 5 minutes. (https://reax.dev/wallet/#talisman)
Experienced: btcli onlyCreate the coldkey with `btcli wallet create` on a trusted machine (never on the GPU server) and sign from the terminal. (https://reax.dev/wallet/#btcli)

Short version for Talisman: install it from `talisman.xyz`, set a password, add a New Substrate Account (Bittensor is built on Substrate), write the recovery phrase on paper, then copy the account's Bittensor address. It starts with `5`. The wallet page (https://reax.dev/wallet/#talisman) walks through every screen.

## Step 3 · Get some TAO

You pay a one-time registration fee in TAO when you register a hotkey (step 4). How much depends on demand and changes over time; you read the live number with one command just before registering (how the fee works (https://reax.dev/wallet/#cost)). Leave a small margin on top for transaction fees.

- Buy TAO on an exchange that lists it and serves your country (for example Kraken, Coinbase, Binance, KuCoin, Gate or Bitget; availability differs by country, so check while logged in).

- Withdraw to your Talisman address. Choose the network called Bittensor or TAO, never a "wrapped TAO" on Ethereum or BNB Chain. Paste the full `5…` address and compare all characters, not only the first and last few.

- Send a small test amount first, wait until Talisman shows it, then send the rest.

Talisman also has a built-in "Buy" button (a card payment provider); fees there are usually higher than on an exchange.

## Step 4 · Create and register your hotkey

On the GPU server, create the hotkey. It is a small file; the command prints its 12-word recovery phrase once, so write that down too (it lets you restore the miner identity later).

```
btcli wallet new-hotkey -w reax -H miner1
btcli wallet list                         # the address under "miner1" (starts with 5) is your hotkey
chmod 600 ~/.bittensor/wallets/reax/hotkeys/miner1
```

Check the current registration fee once the netuid is announced: `btcli subnets burn-cost <NETUID>`.

Now pay the fee from your Talisman wallet. On your laptop, open reax.dev/register (https://reax.dev/register/):

- Click Connect Talisman and allow your funded account.

- Paste the hotkey address from the server and click Check fee and status.

- Tick the confirmation, click Register hotkey. Talisman shows `SubtensorModule: register_limit` with your netuid, hotkey and the price cap; click Approve.

- The page shows your UID. On the server you can check it too: `btcli query uid --netuid <NETUID> --hotkey reax/miner1`.

The registration page opens for mainnet at launch; its practice mode works today with a local chain.

Prefer the terminal? With a btcli coldkey on a trusted machine it is one command: `btcli tx burned-register --netuid <NETUID> -w reax -H miner1`; then copy only the hotkey file to the server (details (https://reax.dev/wallet/#btcli)).

Registration is final

The fee is burned, not refunded, also if you stop mining or get replaced. A new miner is protected for a while (the immunity period); after that, when all slots are full, the lowest-ranked miner is replaced by the next registration. A miner that is offline or wrong ranks lowest.

## Step 5 · Run the miner

An s1-fast miner is two containers on the same server: the model sidecar runs Plumb-4B exactly as System1 production does and listens only on `127.0.0.1:8101`; the reax miner answers validators on the public port 8091 and asks the sidecar. They share a random token.

Available at launch

The repository `github.com/fstandhartinger/reax-subnet` and the images `ghcr.io/fstandhartinger/reax-miner` and `ghcr.io/fstandhartinger/reax-s1-fast-runtime` are private until launch. The commands below are the release 1.1 commands; the tag will be named in the launch announcement.

```
# 1. Get the code (public at launch)
git clone https://github.com/fstandhartinger/reax-subnet.git && cd reax-subnet

# 2. Download the pinned model weights into a plain folder (about 9 GB)
python3 -m venv ~/hf-venv && ~/hf-venv/bin/pip install -U "huggingface_hub[cli]"
~/hf-venv/bin/hf download crh225/plumb-4b --revision 55de037801a8a9b9de3db5c0e16cef86210c2186 \
  --local-dir /srv/reax/plumb-4b

# 3. Shared secret between miner and sidecar
mkdir -p deploy/secrets && openssl rand -hex 32 > deploy/secrets/runtime-token
chmod 0600 deploy/secrets/runtime-token

# 4. Settings
cp deploy/miner.env.example deploy/miner.env
nano deploy/miner.env      # see the table below

# 5. Start both containers
REAX_UID=$(id -u) REAX_GID=$(id -g) REAX_S1_FAST_WEIGHTS=/srv/reax/plumb-4b \
  docker compose -f deploy/docker-compose.s1.yml up -d --build
```

Settings to fill in `deploy/miner.env` (the compose file sets mechanism, model and sidecar URL for you):

| Variable | Value |

| `REAX_NETWORK` | `finney` (mainnet) |

| `REAX_NETUID` | the netuid announced at launch |

| `REAX_WALLET_NAME` / `REAX_WALLET_HOTKEY` | `reax` / `miner1` (the names from step 4) |

| `REAX_EXTERNAL_IP` | the public IP address of the server (an IP, not a host name); `curl -4 ifconfig.me` shows it |

| `REAX_EXTERNAL_PORT` / `REAX_MINER_PORT` | `8091` unless you changed the open port |

Delete the lines `REAX_MECHANISM=mpm1`, `REAX_MODEL=…` and `REAX_DEVICE=…` from the copied example: they belong to the older fallback mechanism, and the compose file already sets the right values. The full list of settings is in the repository's `docs/CONFIG.md`.

What happens on the first start: the sidecar checks every weight file against the release manifest and loads the model (up to 10 minutes). Only when it is healthy does the miner start. The miner then checks the sidecar with a test decision, confirms that your hotkey is registered, publishes your IP and port on chain, publishes your commitment `reax-s1/1:s1-fast:ff6e01b983d48024` (this tells validators which model you serve) and starts answering.

## Step 6 · Check that you are scored

1. Health. On the server:

```
curl -s http://127.0.0.1:8091/health
# {"protocol": "reax-s1/1", "version": "1.1.0rc1", "model": "s1-fast", "manifest_id": "ff6e01b983d48024"}
```

From another machine, `curl http://<YOUR_PUBLIC_IP>:8091/health` must give the same answer; if it does not, the port is closed.

2. Logs. `docker compose -f deploy/docker-compose.s1.yml logs -f miner` should show, in this order:

```
REAX miner 1.1.0rc1 (mechanism s1, protocol reax-s1/1, ...) netuid=... model=s1-fast hotkey=5...
published endpoint 203.0.113.7:8091 for uid 42
published commitment reax-s1/1:s1-fast:ff6e01b983d48024
miner uid 42 listening on 0.0.0.0:8091
metagraph block 123456: 64 neurons, 5 accepted validators; served ok=16 rejected=0 {} errors=0
```

Each real line starts with a timestamp and the logger name. The last line repeats every 5 minutes. `served ok` going up means validators are asking you and you answer. (The endpoint and commitment lines only appear when something changed on chain.)

3. On chain. Validators score in rounds of 2 minutes and submit weights roughly every 72 minutes. Your score starts at 0 and rises with every good round: about a third of the maximum after 4 rounds, about 93 % after an hour without misses. Check your incentive with:

```
btcli query metagraph --netuid <NETUID> --json | python3 -c 'import json,sys; d=json.load(sys.stdin); i=d["hotkeys"].index(sys.argv[1]); print("uid", i, "incentive", d["incentives"][i])' <HOTKEY_ADDRESS>
```

A new miner shows `incentive` 0 until the first weight submission that includes it. If `served ok` stays at 0 for more than 15 minutes, see troubleshooting (https://reax.dev/miner-faq/#troubleshooting).

## How you are scored, in one paragraph

Every 2 minutes each validator sends you 8 freshly generated decisions and computes the same 8 on its own copy of the model. If your answers match (an average logit distance of at most 0.20), the round scores 0.8 plus up to 0.2 for speed. A clear mismatch loses the round; a large one (above 0.50, or any single answer above 2.0) resets your score to zero. Missing a round counts as zero. There is nothing to tune: run the pinned images unchanged and stay online. A quantised (FP8) build, a different model or a changed prompt drifts too far and loses. Details: Verification & calibration (https://reax.dev/verification/).

## Costs and earnings, honestly

- Your costs: the registration fee (burned, not refundable), GPU server rent for 24/7 operation (hourly price × about 720 hours a month), and your time to keep it updated.

- What a miner receives is a share of the subnet's emission in the subnet's own token (alpha), credited as stake on your hotkey, not TAO. Its amount depends on validator weights, on how many miners compete, and on subnet settings that can change. Alpha can be converted to TAO through the chain's exchange pool, and that rate moves.

- Pay is expected to go down over time. The subnet plans to reduce miner pay by directing part of the miner emission away from miners (to the subnet owner or recycled, depending on the chain) and by admitting many miners. Plan with that in mind.

- We make no promise about earnings, about covering your costs, or about the value of any token. You can lose the registration fee and your server costs.

## Can I forward requests to an API instead of running the model?

Yes, the rules allow it. Validators judge answers by correctness and speed only, so a miner may also obtain the exact answers from an API that serves the same model (for example the paid System1 API), at its own expense. The subnet does not block this. It reacts through economics instead: as described above, miner pay is expected to fall over time, which favours miners who run the open weights efficiently on their own hardware.

## Practise on a local chain (no real TAO)

You can rehearse steps 2 to 4 with test money on your own machine, today. This uses a local Bittensor chain in Docker with a pre-funded test account. Every command needs `--network local`; without it btcli talks to mainnet. The `--seed` below is the public "Alice" development key: never type your own recovery phrase or seed into a command line.

```
docker run -d --rm --name local_chain -p 9944:9944 -p 9945:9945 ghcr.io/raofoundation/subtensor-localnet:devnet
btcli wallet regen-coldkey -w alice --no-password \
  --seed 0xe5be9a5092b81bca64be81d212e7f2f9eba183bb7a90954f7b76361f6edb5c0a   # public test key, local chain only
btcli wallet create -w practice -H miner1 --no-password
btcli tx transfer --dest practice --amount-tao 100 -w alice --network local -y
btcli wallet new-hotkey -w alice -H default               # a subnet owner needs a hotkey
btcli tx register-subnet -w alice --network local -y        # creates a practice subnet (netuid 2)
btcli tx start-call --netuid 2 -w alice --network local -y
btcli subnets burn-cost 2 --network local
btcli tx burned-register --netuid 2 -w practice -H miner1 --network local   # read the summary, then confirm
btcli query uid --netuid 2 --hotkey practice/miner1 --network local
```

To rehearse the Talisman route instead, fund your Talisman address from Alice (`btcli tx transfer --dest <TALISMAN_ADDRESS> --amount-tao 10 -w alice --network local -y`), add the local chain in Talisman (Settings → Networks & Tokens → Add network → Substrate, RPC URL `ws://127.0.0.1:9944`) and use practice mode on reax.dev/register (https://reax.dev/register/).

The Alice key above is a published development key; anything sent to it on mainnet is lost. When you are done: `docker stop local_chain`.

## For AI agents

This guide is also available as plain data: /miner.json (https://reax.dev/miner.json) (requirements, image names, ports, environment variables and steps), /llms.txt (https://reax.dev/llms.txt) and /llms-full.txt (https://reax.dev/llms-full.txt) (all docs as text). Browsers with WebMCP support expose the tools `get_launch_status`, `get_requirements`, `get_registration_steps`, `get_run_instructions` and `check_miner_health_instructions` on this page. Agents must never ask for or handle a seed phrase or coldkey; a human approves every payment in their own wallet.

Next: Wallet & registration in detail (https://reax.dev/wallet/) · FAQ & troubleshooting (https://reax.dev/miner-faq/)

---

URL: https://reax.dev/wallet/

Miner onboarding

# Wallet & registration

Everything about keys, TAO and registration for people who have never used Bittensor. Two paths: Talisman in Chrome for beginners, btcli in a terminal for experienced users. Both end with a registered hotkey file on your GPU server.

Status · checked 5 October 2026

REAX is launching soon and has no netuid yet; `<NETUID>` is announced at launch. The wallet steps work today on any Bittensor network. Commands use `btcli` from `bittensor` 11.1.0, the current official command line tool. Wallet apps change their screens from time to time; the screenshots below are from Talisman 3.10.1.

## Coldkey and hotkey

|  | Coldkey | Hotkey |

| Think of it as | your bank account | your miner's ID badge |

| Does | holds TAO, pays the registration fee, owns your miner's stake, can move funds | gets the UID (slot) on the subnet, signs every answer, publishes the miner's address and commitment |

| Lives | in Talisman, a hardware wallet, or an encrypted btcli file on a trusted computer | as a file on the GPU server: `~/.bittensor/wallets/<wallet>/hotkeys/<hotkey>` |

| If it leaks | the thief can take your TAO and stake. Move funds to a new wallet immediately | someone can impersonate your miner but cannot spend TAO. Swap it: `btcli tx swap-hotkey` |

| Never | copy it to a server, type its phrase into a website, chat or form | commit it to git or share the server with untrusted users |

Both keys have an address starting with `5`. Addresses are public and safe to share. The recovery phrase (12 or 24 words) is the key itself: whoever has it controls the account. Nobody legitimate, including REAX, Talisman, an exchange or "support" in a Discord DM, will ever ask for it.

The REAX miner reads only the hotkey file. It does not need your coldkey, and you should never give it one.

## Which wallet?

| Wallet | Good for | Can it register a miner? |

| Talisman (Chrome, Firefox, Brave extension) | beginners; holding, sending and staking TAO; Ledger support | yes, through reax.dev/register (https://reax.dev/register/) (recommended below) |

| Polkadot.js extension, SubWallet | same role as Talisman | yes, through reax.dev/register (https://reax.dev/register/) |

| Nova Wallet, TAO.com app (mobile) | holding and staking TAO on your phone | not that we found: no subnet registration feature |

| btcli (official command line tool) | experienced users, automation, Ledger and Polkadot Vault signing | yes, directly |

| Ledger hardware wallet | the safest place for a coldkey | yes, through Talisman (Ledger account) on the registration page, or `btcli --ledger` |

No browser wallet creates the hotkey file the miner needs, so one short btcli step on the server is always required. Everything that involves money stays in your browser wallet.

## Beginner path: Talisman in Chrome

Tested on 5 October 2026 with Talisman 3.10.1 in Chromium; the screenshots below are from that test (a throwaway test account).

### 1. Install Talisman and set a password

- Open `talisman.xyz` in Chrome and click Download. It takes you to the Chrome Web Store. Check that the publisher is Talisman before you click Add to Chrome: fake wallet extensions with similar names exist. Pin it: puzzle icon in the toolbar, then the pin next to Talisman.

- Talisman opens a welcome page. Click Get Started, enter a strong password twice and click Continue. The password only unlocks Talisman on this computer; it is not your recovery phrase.

- Choose whether to share anonymous usage data (No thanks is fine), then Enter Talisman.

[Figure] Setting the Talisman password.

### 2. Create a Substrate account (your coldkey)

- On the Portfolio page click Add account (later: Settings → Manage Accounts → Add). Stay on the New tab and choose New Substrate Account, not Ethereum: Bittensor is built on Substrate, the same technology as Polkadot.

- Name it, for example `reax-coldkey`, and click Create. Leave "Advanced" (custom derivation path) empty.

- Read the warning and click Acknowledge and Continue. Click the eye icon to reveal the 12 words. Write them on paper, in order, and keep the paper safe; a second copy in another place is wise. No photo, no cloud, no e-mail, no chat.

- Click Verify recovery phrase and complete the check. (If you chose "Skip Verification", Talisman reminds you later under Settings → Recovery Phrases.)

[Figure] Choose New Substrate Account.

[Figure] The recovery phrase stays blurred until you click the eye. Write it on paper.

### 3. Copy your Bittensor address

Click Receive, type `Bittensor` in the search box and click the copy icon next to Bittensor (not "Bittensor Testnet"). The address starts with `5`. This is where you receive TAO. Always paste it, never retype it.

[Figure] Receive → search "Bittensor" → copy.

### 4. Put TAO on it

See Buying TAO (#buy) below. Talisman shows the balance once the transfer arrives.

### 5. Register the hotkey on reax.dev/register

- On the server, create the hotkey (step 4 of the guide (https://reax.dev/mine/#step-4)): `btcli wallet new-hotkey -w reax -H miner1`, and write its recovery phrase down too. `btcli wallet list` shows its address under `miner1`.

- Open reax.dev/register (https://reax.dev/register/) in Chrome on your laptop, click Connect Talisman and allow your `reax-coldkey` account (click the account so its dot turns green, then Connect 1).

- Paste the hotkey address, click Check fee and status, tick the confirmation and click Register hotkey.

- Talisman shows Approve Request with `SubtensorModule: register_limit`. Under View Details check `netuid`, `hotkey` and `limit_price` (the price cap) against the page, then click Approve. The page shows your UID.

[Figure] The approval pop-up. Approve only a `register_limit` with your netuid, hotkey and price cap.

Why a web page and not btcli?

btcli 11.1.0 can let a browser wallet sign most transactions (`--signer extension`), but not registration: it insists on sending registrations "MEV-shielded" (encrypted until included), which it cannot combine with an extension signer (`error: MEV shielding cannot wrap the extension signer`). The registration page instead sends `register_limit` with a price cap 10 % above the price it shows you, so a sudden price jump cannot make you pay more than that. If a subnet locks part of the fee as collateral, the page refuses and points you to btcli.

## Experienced path: btcli only

Create the wallet on a trusted computer that is not the GPU server, register from there, and copy only the hotkey file to the server.

```
python3 -m venv ~/btcli-venv && ~/btcli-venv/bin/pip install "bittensor==11.1.0" "typer<0.27.2"
alias btcli=~/btcli-venv/bin/btcli

btcli wallet create -w reax -H miner1        # coldkey (encrypted with a password) + hotkey; note both phrases
btcli wallet balance -w reax                 # after funding the coldkey address
btcli subnets burn-cost <NETUID>
btcli tx burned-register --netuid <NETUID> -w reax -H miner1 --dry-run
btcli tx burned-register --netuid <NETUID> -w reax -H miner1

# copy ONLY the hotkey to the server
ssh you@your-server 'mkdir -p ~/.bittensor/wallets/reax/hotkeys && chmod 700 ~/.bittensor/wallets'
scp ~/.bittensor/wallets/reax/hotkeys/miner1 you@your-server:~/.bittensor/wallets/reax/hotkeys/
ssh you@your-server 'chmod 600 ~/.bittensor/wallets/reax/hotkeys/miner1'
```

Hardware wallet: add `--ledger` (Polkadot generic app) or `--signer vault` (Polkadot Vault via QR) to any `btcli tx` command. Older guides use the btcli 9 spelling (`btcli subnets register --wallet.name …`); btcli 11 still accepts many old names, but the commands on this page are the current ones.

## Buying TAO

- Pick an exchange that lists TAO and accepts customers from your country. On 5 October 2026 TAO was listed, among others, on Kraken (also against EUR), Coinbase, Binance, KuCoin, Gate, Bitget and MEXC. Listings and country rules change; first-time identity checks can take a while.

- Buy the amount you need for registration plus a margin. We do not comment on prices.

- Withdraw to your coldkey address. Select the network Bittensor or TAO. Never pick ERC-20, BEP-20 or any "wrapped" TAO. Paste the `5…` address, then compare every character.

- Test first. Send a small amount, wait until your wallet shows it, then send the rest. Exchanges have minimum withdrawals and a fee.

- Send TAO only to a coldkey address, never to a hotkey address.

Watch out for "address poisoning": scammers send tiny amounts from look-alike addresses so that one appears in your history. Always copy the address from Talisman, never from your transaction history.

## How the registration fee works

- Registration is a burn: the TAO is destroyed (recycled), not paid to anyone and not refundable.

- Each subnet has one floating price. It goes up after every registration and slowly falls back while nobody registers, within a minimum and maximum the subnet sets. On a quiet subnet it can be very low; right after a launch, when many people register, it can be much higher.

- Read it right before you register: `btcli subnets burn-cost <NETUID>`. btcli shows the fee again in the transaction summary, and the amount actually charged is the price when the transaction lands.

- After registering, a new miner has an immunity period; check it with `btcli query immunity-period --netuid <NETUID>`. When the subnet is full, each new registration replaces the lowest-ranked miner that is no longer immune. If that is you, you need to register (and pay) again.

## Where earnings go

On Bittensor today each subnet has its own token called alpha. Miner rewards arrive as alpha staked on your hotkey, owned by the coldkey that registered it. See them in Talisman (Portfolio and Earn), or with `btcli stake list` / `btcli wallet overview -w reax` on the machine that holds your btcli coldkey. (On the GPU server, which has only the hotkey, `wallet overview` fails because there is no coldkey file; that is expected.) To turn alpha into TAO you unstake it, which swaps it through the subnet's pool at the current rate, with a fee; preview first with `--dry-run`. REAX makes no statement about the amount or value of any reward.

## Safety checklist

- Recovery phrases only on paper (or a metal backup), never typed into a website, chat, form, cloud document or AI assistant.

- Nobody from REAX will DM you first, ask for a phrase, or ask you to "validate" or "sync" your wallet. Ask for help only in public channels.

- Install wallets only from links on their official sites. Check the publisher.

- The GPU server holds only the hotkey (`chmod 600`). Never copy a coldkey file or phrase to it.

- Pin software versions (`bittensor==11.1.0`) and install only from official sources. A compromised Bittensor package once stole keys (2024).

- Larger balances belong on a hardware wallet (Ledger works with Talisman and btcli).

## Sources

Checked 5 October 2026: Bittensor documentation at `bittensor.com/docs` (wallets, mining, registration burn, signing with a browser extension, Ledger, local development, migration from btcli 9), Talisman documentation at `docs.talisman.xyz` (creating a Bittensor account, backup, copying addresses), and the public APIs of the exchanges named above. Wallet apps and exchange listings change; check the current state yourself.

Next: run the miner (https://reax.dev/mine/#step-5) · FAQ & troubleshooting (https://reax.dev/miner-faq/)

---

URL: https://reax.dev/register/

Miner onboarding

# Register your miner with Talisman

Pay the registration fee for your miner's hotkey from your Talisman wallet, without a terminal on your laptop and without putting your coldkey anywhere else. This page builds one registration transaction with a price cap; Talisman shows it to you and only sends it when you click Approve.

Status · Launching soon

REAX has no netuid yet, so registration on mainnet opens at launch. Practice mode works today against a local Bittensor chain on your own computer (see the practice section (https://reax.dev/mine/#practice)); Chrome may ask you to allow access to your local network. Tested on 5 October 2026 with Talisman 3.10.1 on a local chain.

## Before you start

- Talisman is installed and has a Substrate account with enough TAO (wallet guide (https://reax.dev/wallet/#talisman)).

- Your hotkey exists on the GPU server: `btcli wallet new-hotkey -w reax -H miner1`. Copy its address from `btcli wallet list` (the line under `miner1`, starting with `5`).

## Registration

This tool needs JavaScript and a wallet extension. Without it, use the btcli command in the wallet guide (https://reax.dev/wallet/#btcli).

1 · Network
 REAX on Bittensor mainnet
 Practice on a local chain

Local chain endpoint

Practice subnet (netuid)

2 · Wallet (coldkey, pays the fee)
Connect Talisman

Paying account

3 · Hotkey (from your server)
Hotkey address

Check fee and status

4 · Register
 I understand that the fee is burned and not refundable, that it can be up to 10 % higher than shown if someone registers at the same moment, and that REAX promises no earnings.
Register hotkey

## What you approve in Talisman

Talisman opens a window titled Approve Request with the content `SubtensorModule: register_limit`. Under View Details it shows three arguments: `netuid` (the REAX subnet), `hotkey` (the address you pasted) and `limit_price` (the most you pay, in RAO; 1 TAO = 1,000,000,000 RAO). Approve only if all three match this page. The estimated fee Talisman shows is the transaction fee; the registration fee itself is shown on this page. If anything else appears in the pop-up, click Cancel.

[Figure] The Talisman pop-up (practice run on a local chain, 5 October 2026).

[Figure] This tool after a successful practice registration.

## Safety

- This page never asks for a recovery phrase, password or private key, and it cannot read them. If any page does, close it.

- It connects only to the public Bittensor mainnet endpoint, which it checks by its genesis hash, or to your own local chain in practice mode, and it stores nothing.

- The registration fee is capped: the page asks the chain to register only if the price is at most 10 % above the price it showed you. If many people register at the same moment and the price passes the cap, the chain refuses and you only lose the small transaction fee.

- Check the address bar: `https://reax.dev/register/`. Links in DMs claiming to be a "REAX registration" elsewhere are scams.

- Prefer the terminal? An equivalent registration is `btcli tx burned-register --netuid <NETUID> -w reax -H miner1` with a btcli coldkey (details (https://reax.dev/wallet/#btcli)).

---

URL: https://reax.dev/miner-faq/

Miner onboarding

# Miner FAQ & troubleshooting

Short answers to the questions new miners ask most, and what to do when the miner does not start or is not scored.

Status · 5 October 2026

REAX is launching soon. It is not registered on testnet or mainnet and there is no netuid yet. Answers describe release 1.1 (pre-release 1.1.0rc1); details can change before launch.

## FAQ

### Is REAX live? Can I mine today?

Not yet. There is no netuid, and the code and images become public at launch. You can prepare a wallet and a server and rehearse registration on a local chain (https://reax.dev/mine/#practice).

### What does a REAX miner actually do?

It runs one of the System1 decision models (s1-fast, Plumb-4B, at launch) exactly as production runs it and answers short decision questions from validators: a situation plus a fixed set of options, answered with a probability for each option. Validators check the answers by computing them themselves.

### I have never used Bittensor. Can I still do this?

Yes, if you can rent a Linux GPU server and copy commands into a terminal. The Talisman path (https://reax.dev/wallet/#talisman) keeps your money key in a normal browser wallet, you register on reax.dev/register (https://reax.dev/register/) with a click, and the guide (https://reax.dev/mine/) has every command for the server.

### Which GPU do I need?

For s1-fast one NVIDIA GPU with at least 24 GB. Measured and within tolerance: RTX 4090, RTX PRO 6000 Blackwell, H100 80 GB. Other cards are likely fine but unmeasured; run the calibration script first. s1-pro (later) needs 80 to 96 GB.

### Can I bring my own model or a faster quantised version?

No. Validators compare your answers with the pinned model to within a small tolerance. An FP8 build, a different model or a changed prompt drifts too far, loses rounds and can reset your score. Speed only counts for 20 % of a round and is capped, so a cheaper substitute gains nothing. A separate competition track for better models is designed but switched off; see Competition mining (https://reax.dev/competition/).

### May I forward validator requests to an API instead of running a GPU?

The rules allow it; answers are judged on correctness and speed only. Expect miner pay to fall over time (directing part of the miner emission away from miners and many admitted miners), which favours miners who run the open weights efficiently themselves. See the guide (https://reax.dev/mine/#relay).

### Can I run several miners?

Each hotkey needs its own registration (and fee) and serves one model. One s1-fast GPU answers about 30 (RTX 4090) to 60 (H100) decisions per second, far more than the validators send to one miner, so several hotkeys can share a GPU technically. Each needs its own port and its own commitment.

### How much will I earn?

We do not know and we make no promise. Rewards are a share of the subnet's emission, paid as the subnet's alpha token staked on your hotkey. The amount depends on validator weights, the number of miners and subnet settings, all of which change. Plan for miner pay to decrease over time. Read costs and earnings (https://reax.dev/mine/#costs).

### Is there a REAX token or sale?

No sale. Like every Bittensor subnet, the subnet has an alpha token created by the chain. REAX makes no statement about its value.

### What happens when my miner is offline?

Every missed round counts as zero in your moving average, so your score drops quickly and recovers within about an hour after you return. Long downtime makes you the lowest-ranked miner, and once your immunity has ended the next registration can replace you.

### How do I update?

Follow the release announcements. When the protocol or the model manifest changes, update before the announced switch time. A new manifest means a new commitment, and your score restarts from zero.

### Do miners see customer data?

No. In release 1.1 miners receive only freshly generated synthetic test decisions from validators. Customer traffic to miners is switched off.

### What about the GDPR tier?

The EU (GDPR) tier is a separate, contracted operator programme with its own admission. Business inquiries: reax.co/apply (https://reax.co/apply/).

## Troubleshooting

| You see | Cause and fix |

| `AttributeError: module 'typer._click.exceptions' has no attribute 'Exit'` from any btcli command | typer 0.27.2 is incompatible with btcli 11.1.0. Run `~/btcli-venv/bin/pip install "typer<0.27.2"`. |

| Sidecar stays "starting" or "unhealthy", logs mention a weights or hash mismatch | The weights folder is not the pinned revision, or you mounted a Hugging Face cache path (its files are symlinks that break inside the container). Download with `hf download … --revision 55de037801a8a9b9de3db5c0e16cef86210c2186 --local-dir /srv/reax/plumb-4b` and point `REAX_S1_FAST_WEIGHTS` at that folder. |

| Sidecar fails with a CUDA or driver error | The driver is too old for CUDA 13 (needs R580 or newer), or the NVIDIA Container Toolkit is missing. Test with `docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi`. |

| `the s1-fast runtime at http://127.0.0.1:8101 did not answer an authenticated test decision` | The sidecar is not up yet, or the two containers read different token files. Both mount `deploy/secrets/runtime-token`; recreate it, `chmod 0600`, and start both with the same `REAX_UID`. |

| `configuration error: … REAX_RUNTIME_TOKEN_FILE …` or permission denied on the token or hotkey | The containers run as your user id. Start with `REAX_UID=$(id -u) REAX_GID=$(id -g)` and make sure the files belong to you. |

| `hotkey 5… is not registered on subnet N` | Registration did not go through, or `REAX_NETUID`, `REAX_WALLET_NAME` or `REAX_WALLET_HOTKEY` does not match. Check with `btcli query uid --netuid N --hotkey <HOTKEY_ADDRESS>`. If you were replaced after your immunity period, register again. |

| `cannot load hotkey reax/miner1 from /wallets: …` | The miner reads `~/.bittensor/wallets/<REAX_WALLET_NAME>/hotkeys/<REAX_WALLET_HOTKEY>` of the user who starts compose (mounted read-only at `/wallets`). Check names and location. |

| `REAX_EXTERNAL_IP is required to publish the miner endpoint` | Set `REAX_EXTERNAL_IP` to the server's public IP address in `deploy/miner.env` (or `REAX_SERVE_AXON=0` if your endpoint is already published on chain and you do not want the miner to update it). |

| `could not publish commitment …` | The chain limits how often a hotkey may write. The miner retries every 10 minutes; nothing to do unless it keeps failing for hours. |

| `served ok=0` for more than 15 minutes | Validators cannot reach you. Test `curl http://<PUBLIC_IP>:8091/health` from another network; open TCP 8091 in the server firewall and your provider's panel. Make sure the log shows `published endpoint <your current IP>:8091` (after an IP change, restart the miner so it republishes). A home connection behind NAT needs port forwarding. |

| `rejected a request with 401` in the logs | Usually a wrong clock: signed requests older than 10 seconds are refused. Enable NTP (`timedatectl set-ntp true`). |

| Answers are served but the score stays at 0 or keeps resetting | Your answers do not match the reference: a modified image, a different model or quantisation, or an unmeasured GPU that drifts. Run the pinned images unchanged; on an unmeasured GPU run the calibration script. |

| Registration fails with "insufficient balance", `MEV-shielded submission needs free TAO …` or a spending limit | The fee plus transaction fee is more than your free balance, or the price rose between reading and sending. Check `btcli subnets burn-cost` again and top up. |

| `BadProof` or `AncientBirthBlock` from `btcli tx burned-register` | The shielded registration took too long to be included (seen on fast local practice chains). Nothing was charged; run the same command again. |

| The Talisman pop-up never appears on reax.dev/register | Unlock Talisman first. If you clicked away the connection request, open Talisman → Settings → Connected Sites and allow reax.dev, then reload the page. The account must be a Substrate (not Ethereum) account. |

| `error: MEV shielding cannot wrap the extension signer` from `btcli tx burned-register … --signer extension` | btcli 11.1.0 does not let a browser wallet sign registrations. Use reax.dev/register (https://reax.dev/register/) with Talisman, or a btcli coldkey without `--signer extension`. |

Still stuck? Collect the output of `docker compose -f deploy/docker-compose.s1.yml logs --tail 100` (it contains no secrets; still check before you share) and ask in the public REAX channel announced at launch. Never share a recovery phrase, a hotkey file or the runtime token.

---

URL: https://reax.dev/

Developer documentation

# Build on REAX

REAX is a Bittensor subnet in development. Miners serve fast, calibrated, finite-answer decision models that are Jev-compatible, and validators measure whether those models are served faithfully. These docs describe the design and the private reference implementation as they stand today.

Status · 3 October 2026

Pre-release. Nothing runs on testnet or mainnet. No REAX subnet is registered and there is no netuid. The only running system is a local loopback harness: three simulated miners, one validator, synthetic traffic, no chain. The design specification is provisional and changes often. These docs follow revision 0.6; newer working revisions are in review, and every rollout gate is closed. Source code is private; prospective operators can request access through reax.co/apply (https://reax.co/apply/).

Release 1.1.0rc1 (pre-release)

The current mechanism is inference mining on the exact System1 models: Inference mining (1.1) (https://reax.dev/mining/), Verification & calibration (https://reax.dev/verification/), and the planned, switched-off Competition mining (https://reax.dev/competition/). Pages written for spec revision 0.6 describe the earlier design.

## What REAX does

A REAX request carries a question with a finite candidate set: yes or no, one option out of several, or a level on an ordered scale. A miner answers with a complete probability distribution over that set, signed with its serving key. The network is built for decisions that must come back quickly and with calibrated probabilities, not for free-form text generation.

- Miners serve approved models only. The v1 model catalog is closed: each public `model` alias maps to a signed list of approved model manifests, and miners compete on faithful, available, verified-capacity serving of those models. They do not bring their own models.

- Validators measure faithful serving: identity and quality fidelity to the reference manifest, availability, latency (capped at the reference) and verified serving capacity. These sit behind hard eligibility gates for tier, identity and integrity. Validators convert the result into miner weights.

- Chain emissions are an incentive mechanism. They are not customer billing and not a service guarantee. Customer charges and any operator settlement are fiat-accounted and kept separate from the score ledger.

## Architecture

Customer requests never reach a miner directly. They enter through System1's API, are authenticated and projected by the REAX gateway, and are dispatched to an eligible miner in the right tier. Validators inject their probes through the same gateway, so a probe travels the same path as any other request.

[Figure] Solid outlines: components that exist in the private reference code and run in the local harness. Dashed outlines: external or designed components that are not connected today. The harness uses a mocked chain snapshot and a synthetic engine.

Every miner calls its own co-located inference engine. The gateway strips caller identity and replaces the request ID and nonce with fresh per-dispatch values before anything reaches a miner. See the protocol reference (https://reax.dev/protocol/) for the exact envelopes.

## Roles

| Role | Responsibility | Trust boundary |

| Miner (GDPR tier) | Serves admitted EU requests under contract and DPA | Sees plaintext while inferring; admitted through an off-chain process and a signed admission snapshot |

| Miner (permissionless) | Serves authorized synthetic traffic only | Assumed to be able to log, copy or retain payloads, so it never receives personal or GDPR-tier data |

| Validator | Private schedules, labelled items, identity items, verification, epoch scoring, weight submission | Receives no customer content and no organic metadata; injects probes only through the gateway; must be independent of other validators |

| Gateway / router | Authenticates callers; enforces tier, eligibility and capacity; projects payloads; dispatches; measures latency; records receipts | Customer API keys and chain keys never reach miners; never reads the emission score |

| Reference processor | Computes reference outputs `p_ref` on byte-identical payloads | Never stores payloads; must be admitted like a GDPR operator for any tier whose organic traffic it shadows |

| System1 (external owner) | Customer ingress, tenant policy, legal notices, billing | Owns the decision to send real traffic; REAX cannot override that gate |

| Subnet owner / trust root | Chain hyperparameters, signed trust root, policy, catalog and chain profile | Owner and coldkey are not yet decided; offline owner key signs issuer keys |

The chain provides hotkey registration, validator permits and stake-weighted consensus over weights. It does not inspect models, prove EU location, bind a company to a DPA, or judge whether answers are correct. Those are the jobs of admission, the gateway and validators.

## Tiers

|  | GDPR tier | Permissionless tier |

| Wire value | `gdpr_eu` | `global_permissionless` |

| Who can serve | EU-established legal operators processing data in admitted EU countries | Any chain-registered hotkey that passes conformance |

| How you get in | Off-chain KYB, contract and DPA, then a signed admission snapshot; chain registration is necessary but never sufficient | Chain registration plus a signed miner record and conformance |

| Traffic today | None outside the local harness | Synthetic only, and only in the local harness |

| Real traffic requires | A signed acceptance record from the System1 owner, legal review, DPA and subprocessor workflow, and the organic identity shadow enabled. None of these exist yet. |

System1 currently routes both of its customer tiers only to verified EU capacity, and routing outside the EU is hard-disabled. The permissionless route therefore carries synthetic traffic only until the System1 production owner signs an acceptance record. No REAX setting can override that gate.

## Current status

| Area | State | Detail |

| Design specification | Provisional | Docs follow revision 0.6; newer working revisions (0.7, 0.8) are in review. Not frozen; constants are provisional and several measurements (M1–M4) and simulations (S1–S4) have not run |

| Rollout gates G0–G6 | All closed | From spec freeze through mainnet; see the roadmap (https://reax.dev/roadmap/) |

| Local harness | Runs locally | Loopback only: 3 simulated miners, 1 validator, synthetic traffic, mocked chain snapshot |

| Testnet | Not registered | No REAX subnet, no netuid; read-only chain checks exist |

| Mainnet | Not registered | Requires explicit approval of a stated cost and coldkey |

| Customer traffic | None | No System1 acceptance record exists |

| Images | Disabled | Disabled at the network miner pending isolated decode validation |

| Capacity measurement | Not built | Capacity is fixed at 1 in code; no weight to external miners on any non-local network until it exists |

| Organic identity shadow | Designed, off | Disabled by default; mandatory before real traffic |

| Source code | Private | Pre-release; access by request for prospective operators |

## Where to go next

Local quickstartInstall the reference package and run the three-miner loopback harness. (https://reax.dev/quickstart/)
Miner guideWhat a miner serves, the signed contract, and tier requirements. (https://reax.dev/miners/)
Validator guidePrivate schedules, probes, the epoch pipeline and weight submission. (https://reax.dev/validators/)
Protocol referenceConstants, request schema, question types, envelopes and errors. (https://reax.dev/protocol/)
Scoring & incentivesGates, gain formula, capped latency, capacity and operator groups. (https://reax.dev/incentives/)
Testnet guideWhat participation will require once a test subnet exists. (https://reax.dev/testnet/)

---

URL: https://reax.dev/quickstart/

Get started

# Local harness quickstart

Install the private REAX reference package, run its tests, and run the three-miner loopback harness. The harness exercises the signed serving path and the validator epoch pipeline end to end on your own machine.

Local only

Everything on this page runs on `127.0.0.1` with synthetic data and a mocked chain snapshot. It does not connect to Bittensor, register anything, or move TAO. The reference source is private pre-release; prospective operators can request access through reax.co/apply (https://reax.co/apply/).

## Requirements

- Python 3.10 or newer. CI covers Python 3.10 to 3.13.

- Access to the private `reax-subnet` reference repository.

- An isolated virtual environment. Do not install into a shared or global Python.

Core dependencies are pinned in `pyproject.toml`: `cryptography==50.0.1` for Ed25519, `Pillow==12.3.0` and `rfc8785==0.1.4` for RFC 8785 canonical JSON. The harness also needs the `server` extra, which pins `uvicorn==0.54.0`. The Bittensor SDK (`bittensor==11.1.0`, extra `chain`) is not needed for anything on this page.

## Install

From the repository root, create a virtual environment and install the package with the server extra:

```
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install -e '.[server]'
```

For a fully hash-locked development environment, install from the lock file instead. It pins every package in scope and verifies published wheel SHA-256 values; source distributions are disabled:

```
python3 -m pip install --only-binary=:all: --require-hashes -r requirements/dev.lock
```

## Run the tests

```
python3 -m unittest discover -s tests -v
python3 -m compileall -q src tests
```

The `Makefile` wraps the same commands as `make test` and `make compile`, plus `make typecheck` (mypy on Python 3.10). Suites cover the protocol, transport, admission, router, gateway, miner, receipts, scoring, validator epoch and chain guards. Three SDK compatibility tests are skipped unless the pinned Bittensor SDK is installed in an isolated environment.

## Run the three-miner harness

Pass an absolute output path in a directory that already exists and that you keep private:

```
PYTHONPATH=src python3 -m reax_subnet.harness --output /path/to/private/evidence/local-harness.json
```

The wrapper script does the same thing (despite its name, it does not touch testnet):

```
scripts/testnet_harness.sh --output /path/to/private/evidence/local-harness.json
```

With `--output`, the harness writes the full JSON receipt to that file and prints a one-line summary. Without it, the receipt is printed to standard output. The exit code is `0` when the receipt says `"passed": true` and `1` otherwise.

```
{"passed": true, "receipt": "/path/to/private/evidence/local-harness.json"}
```

--outputReceipt path. Its parent directory must already exist.
--count-per-sourceScheduled probes per miner, default `288` (six synthetic epochs of 48). A short cold start such as `--count-per-source 1` intentionally produces no weight vector and exits with `1`.

## What the harness runs

- Three miners on ephemeral loopback ports, each a real `MinerApp` behind Uvicorn: two simulated EU miners admitted by a signed local admission fixture (`gdpr_eu`) and one simulated permissionless miner (`global_permissionless`). Their engine is a synthetic arithmetic engine, not a model.

- Three gateway fixtures (one per miner, same ingress identity) serving signed HTTP. Every scored dispatch goes signed gateway HTTP, then signed miner HTTP.

- One validator with its own caller key. It generates fresh arithmetic tasks with known answers from a registered deterministic checker, balanced across outcomes, and hashes the entire schedule before any output is inspected.

- Six synthetic ledger epochs of 48 probes per miner: 864 scheduled inference requests in total at the default count. Epoch boundaries are wall-clock, not chain tempos.

- Scoring and weights through the typed `score_epoch` and `weights_from_epochs` pipeline, with signed policy and epoch documents verified against separate ephemeral owner and ingestor keys, and a dry-run weight plan against a mocked chain snapshot.

## What a passing receipt shows

- Signed Ed25519 requests and responses work over real loopback HTTP through both hops, with RFC 8785 canonical JSON.

- Replays are rejected at both the gateway and the miner before inference.

- Tier isolation holds: a GDPR-tier request cannot be routed to the permissionless miner, and a cross-tier request to it returns `403`.

- Payload-free gateway receipts verify.

- Complete 288-cluster fidelity windows reach support, the first supported epoch applies the half-gain ramp, and operator-capped weights are produced.

- An unsigned policy abstains, a non-local network profile abstains, and the owned-only `testnet_mechanics` profile is exercised without connecting to any chain.

## What it does not prove

Read before quoting results

The receipt establishes signed loopback serving and synthetic epoch-to-weight computation. It establishes no Bittensor connection, SDK compatibility, registration, on-chain weights, real model performance, independent operator identity or legal EU admission.

- The chain snapshot and commit plan are mocks (`"chain_snapshot": "mocked only"`, `"chain_connection_proven": false`).

- Reference latency comes from 16 unscored local calls on the host. It is not a reference-hardware or serving-region measurement.

- The capacity prober is not implemented (`"capacity_prober_implemented": false`); capacity is fixed at 1.

- Probe indistinguishability is not tested: the gateway fixtures prove the signed path, not production routing.

- The receipt's `"design_status"` states that the known constant-substitute and max-group merge counterexamples are unresolved in the current scoring code.

## Receipt fields worth checking

The receipt schema is `reax.local-harness.v2`. These keys are the quickest way to confirm what was and was not exercised:

| Key | Meaning |

| `passed` | All harness assertions held |

| `network` | `"actual signed loopback gateway HTTP to miner HTTP"` |

| `miner_count`, `validator_count`, `gateway_count` | 3, 1 and 3 |

| `scheduled_inference_count` | 3 × `--count-per-source` |

| `replay_status`, `gateway_replay_status` | HTTP status of the replayed request at miner and gateway |

| `eu_route_to_global_denied`, `cross_tier_status` | Tier isolation checks |

| `weights` | The weight decision, including status, applied gains and fidelity states |

| `external_weight_gate_open`, `customer_gate_open` | Always `false` |

| `chain_connection_proven`, `sdk_weights_proven` | Always `false` |

Keep receipts private. They contain signed policy and epoch document hashes and per-miner scores from your local run.

---

URL: https://reax.dev/mining/

Release 1.1 (pre-release)

# Inference mining (1.1)

In release 1.1 a miner serves exactly one of the System1 production models: the same weights, the same prompt, the same one-pass readout and the same answer schema as production. A validator can then check a miner by recomputing the answer on its own copy of the same model.

Status · 3 October 2026

Release candidate 1.1.0rc1, pre-release. It was built and tested on a local chain with the real production runtimes. It has not been run on testnet or mainnet, no REAX subnet is registered and there is no netuid. Numbers on this page come from the repository documents named in each section.

## Roles

- Miner. One model per hotkey. The miner answers signed `reax-s1/1` requests with production's answer objects, using a model runtime on loopback that reproduces production exactly.

- Validator. Runs the reference runtime of every enabled model on its own GPU, sends fresh items to miners each round, and recomputes the answers to compare them. See Verification & calibration (https://reax.dev/verification/).

- Owner. Any pool share without an enrolled miner goes to the owner UID, so a subnet with no miners is safe.

## The two models

|  | s1-fast | s1-pro |

| Model | Plumb-4B | Surogate Rune 26B-A4B v3 |

| Weights | `crh225/plumb-4b` at revision `55de037`, public | `surogate/rune-26b-a4b-GGUF` at revision `c6b360d` (bf16 safetensors despite the repository name), Hugging Face gated |

| Licence | Apache-2.0 | Apache-2.0 |

| GPU | one NVIDIA GPU with 24 GB or more | one GPU with 80 to 96 GB |

| Pool at first | on | switched off |

| Readout temperature | 2.07 | 2.0 |

| Options per question | 2 to 16 (the subnet generator uses 2 to 8) | 2 to 64 (the subnet generator uses 2 to 8) |

Commercial serving by third-party miners is allowed by both licences. Rune requires every operator to accept the Hugging Face gate with their own account; REAX never mirrors the weights. Limits for both models: state of at most 16 KiB and at most 4,096 input tokens.

## On-chain commitment

A miner publishes a plaintext commitment through the Commitments pallet:

reax-s1/1:<model>:<manifest_id>

`model` is `s1-fast` or `s1-pro`. The `manifest_id` is the first 16 hex characters of the sha256 of the canonical manifest bytes (s1-fast `ff6e01b983d48024`, s1-pro `5b11440bf57b5434`). A hotkey without a valid commitment for an enabled model is not queried and earns nothing. Changing the commitment resets that UID's score: state is keyed by hotkey, model and manifest.

## Manifests and runtimes

A versioned manifest in the repository pins the Hugging Face revision and the sha256 of every weight file the runtime reads (miners verify them before serving), the runtime base image by digest, package pins, the readout settings and the limits. The s1-pro runtime is vLLM 0.30.0 with deterministic flags (`VLLM_BATCH_INVARIANT=1`, no chunked prefill, `-O0`); stock vLLM without them loses about a third of its rounds in the calibration. The s1-fast runtime uses the production CUDA-graph, batch-1 path.

## Request and answer

Requests are `POST /v1/s1/decide`, signed in both directions as in the earlier mechanism. Each decision is a System1 body without `model`: one question, no images. An answer is production's normalized answer object: `type`, the probability of every option, plus `choice` and `confidence`, `noul`, or `score`, `confidence` and `legend`. A response whose derived fields disagree with its own probabilities is rejected.

## Hardware measured

| GPU | s1-fast | s1-pro |

| RTX PRO 6000 Blackwell (96 GB) | measured, 55.6 decisions/s | measured, 17 decisions/s at concurrency 1 |

| H100 80 GB | measured, 60.5 decisions/s | measured, 15 decisions/s at concurrency 1 |

| RTX 4090 (24 GB) | measured, 30.4 decisions/s | not applicable (too small) |

Throughput is the production path, one decision at a time. The deterministic s1-pro build gave bit-identical answers on the RTX PRO 6000 and the H100. A100, L4, L40S, H200, RTX 5090 and other cards should work but are not measured: run `scripts/calibration_s1` in the repository first.

## Switches and defaults

| Setting | Default in 1.1.0rc1 |

| `REAX_MECHANISM` | `s1`; `mpm1` selects the earlier mechanism (Qwen3-4B) as a fallback |

| s1-fast pool | on; share 1.0 when alone |

| s1-pro pool (`REAX_FEATURE_S1_PRO_POOL`) | off. Every validator would need an 80 to 96 GB reference GPU, and turning it on changes weights for all validators, so it is a release plus owner decision. When on: shares s1-fast 0.35 and s1-pro 0.65 |

| Images, multi-question requests, customer traffic, capacity audits | off; startup refuses them |

Scoring constants are release constants, and validators refuse overrides on finney. The pool shares are not a statement about the value of anything; they only split the weights.

## Open points

- API relay. A miner without a GPU could relay validator items to the public System1 API and pass. This is an accepted risk pending an owner decision before miners are told about the subnet (repository `docs/THREAT-MODEL.md`, S15).

- Many hotkeys on one GPU is an accepted, documented risk.

- Peer-to-Peer tier routing is design only; see the roadmap (https://reax.dev/roadmap/).

Repository documents: `READINESS.md`, `docs/DESIGN-v1.1.md`, `docs/MINER.md`, `docs/VALIDATOR.md`, `docs/CALIBRATION.md`, `docs/THREAT-MODEL.md`. The repository is private.

---

URL: https://reax.dev/verification/

Release 1.1 (pre-release)

# Verification and calibration

A validator checks a miner by asking it fresh questions and recomputing the same answers itself on the same pinned model. The two sets of probabilities are compared in logit space, and the thresholds were set from measurements on three GPU types.

Status · 3 October 2026

Release candidate 1.1.0rc1, pre-release; calibrated on rented GPUs and tested on a local chain, not on testnet or mainnet. All numbers below are from `docs/CALIBRATION.md` and `docs/DESIGN-v1.1.md` in the private repository.

## Fresh items, no answer key

Items come from a cryptographically seeded generator per miner and round, so there is no answer key to leak. Each is a typed decision: a short text or JSON state and one `choice` (2 to 8 options), `noul` or `score` (3 to 5 levels) question. Every round a miner gets 8 items. The validator draws which items it verifies with its own secret only after the answers arrive, so the miner cannot tell them apart.

- s1-fast: all 8 items are verified.

- s1-pro: a secret 3 of 8 items are verified (a spot check); the rest are real work the miner does anyway.

## The logit distance

From the miner's probabilities p and the reference's q the validator computes centred log-ratios and takes the largest disagreement between option logits, in the model's own units:

d(p, q) = T · max_i | (ln p_i − mean_j ln p_j) − (ln q_i − mean_j ln q_j) |p and q are floored at 1e-6. T is the production temperature (s1-fast 2.07, s1-pro 2.0).

The distance does not depend on the softmax temperature and does not saturate when the model is confident: a near-one-hot answer still carries the exact logit gaps, which are a fingerprint of the weights and the prompt. The earlier mechanism used a protocol temperature of 4; 1.1 keeps the production temperature because answers must be production answers.

## Thresholds

D is the mean distance over the round's verified items.

| Condition | Result for the round |

| Malformed, late, unsigned or inconsistent response | scores 0 |

| D ≤ 0.20 | scores 0.8 + 0.2 × speed |

| D > 0.20 | scores 0; the round is lost |

| D > 0.50, or any verified item above 2.0 | strike: the round scores 0 and the moving average resets to 0 |

Speed is measured by the validator's own clock, within latency bounds of 0.5 to 8 s for s1-fast and 1 to 12 s for s1-pro, and is 20 % of a passing round's score. Weights are per pool with fixed shares.

## What the calibration measured

The calibration used 871 decisions (640 from the validator generator plus 231 public JevBench items) with the exact production runtimes on RTX PRO 6000 Blackwell, H100 80 GB and RTX 4090 (s1-fast only).

### s1-fast (Plumb-4B)

| Pair | Median d | Max d | Top choice agrees |

| Production path, new process, same GPU | 0 | 0 | 100 % |

| Production path, H100 vs RTX PRO 6000 | 0.071 | 0.708 | 98.7 % |

| FP8 build of the same weights | 0.250 | 3.00 | 96.8 % |

| Closest sibling model, best temperature | 0.89 | 5.79 | 83.2 % |

| Base Qwen3.5-4B | 1.43 | 10.70 | 74.4 % |

Over 8 verified items, an honest miner on any pair of the three GPU types scores 0.9998 to 1.0 of its rounds and is never struck (worst round mean 0.24). An FP8 build scores about 0.095 to 0.098 of its rounds, which keeps its moving average near 0.1, below the 0.3 needed for any weight. Other models are struck in at least 0.997 of rounds. Raising the mean threshold to 0.25 would let FP8 score 28 % of rounds, which is why 0.20 was chosen.

### s1-pro (Rune 26B-A4B v3)

- The deterministic build is bit-identical (distance 0) across restarts, concurrency 1, 16 and 64, and between H100 and RTX PRO 6000.

- Stock vLLM without the deterministic flags: median 0.146, max 3.94; it passes 0.65 of rounds, so miners must run the pinned deterministic runtime.

- FP8 of the same weights: median 0.313, max 4.1 to 5.0; it passes 0.12 of rounds and is struck in 22 %.

### Why a spot check is enough for s1-pro

If a cheater answers a fraction x of items with something cheaper and 3 of 8 are verified, a round catches it with probability 0.375 at x = 1/8, 0.64 at x = 1/4 and 0.93 at x = 1/2. A catch resets the moving average, and rebuilding takes about 22 rounds. Cheating therefore costs more rounds than it saves compute.

## Attacks and defences

| Attack | Defence |

| Wrong or cheaper model, quantised build | Logit distance on fresh items; FP8 and other models measured explicitly |

| Cached answers | Items are fresh per miner and round |

| Copying another miner | Hotkey-bound requests and responses; per-miner items |

| Latency spoofing | Validator-side clock; only 20 % weight, and only on passing rounds |

| Answering only the verified items well | Verified set is drawn after the response |

| Production-looking fields over wrong probabilities | Validator recomputes derived fields |

| Hopping between models to dodge strikes | State keyed by hotkey, model and manifest |

## Validator load

The s1-fast reference verifies 8 items per miner and round. At 30 decisions/s (RTX 4090), 255 miners need about 68 s of the 120 s round; at 55 to 60 decisions/s (RTX PRO 6000, H100) about 35 s. A 24 GB validator card is fine for up to roughly 150 s1-fast miners.

## Not measured

A100, L4, L40S, H200, RTX 5090 and other cards; FP8 or INT4 builds other than vLLM online FP8; and a model distilled on the public item generator (the closest relative averages seven times the threshold). Repository documents: `docs/CALIBRATION.md`, `docs/DESIGN-v1.1.md`, `docs/VALIDATOR.md`, `docs/THREAT-MODEL.md`.

---

URL: https://reax.dev/competition/

Release 1.1 (pre-release)

# Competition mining (planned)

A second way to mine, designed for the release after 1.1: 20 % of miner emission goes to the current number one of a public competition for faster or cheaper versions of the production models. It is switched off until it is proven robust.

Status · OFF

Designed, implemented on a separate branch behind the feature flag `REAX_FEATURE_COMPETITION` (default off), and not yet robust enough to switch on. While it is off, 100 % of miner emission stays with inference miners, as in 1.1. Nothing here runs on testnet or mainnet. Source: `DESIGN-v1.2-competition.md` and `READINESS.md`.

## The split

miner emission = 0.80 × inference pools  +  0.20 × competition winner

- The owner share is taken first, unchanged.

- With no current winner, or with the flag off, the 20 % goes back to the inference pools pro rata, never to the owner.

- The winner is a competition hotkey that commits a submission, not an inference role. One hotkey cannot be both, because the Commitments pallet allows one commitment per hotkey and subnet; an operator who wants both registers two UIDs.

## Tracks

| Track | Goal | Quality gate |

| `s1-pro-speed` | Faster s1-pro with provably identical outputs | Weights byte-identical to the pinned Rune files, or a declared quantisation recipe the evaluator re-runs to byte-identical files; and on 2,000 fresh items every 3-item round mean stays within logit distance 0.20 with no item above 2.0, against the deterministic production runtime |

| `s1-fast-speed` | Faster or cheaper s1-fast | JevBench Capability at least the incumbent's on sealed rotating items (the evaluator receives only the score), and agreement with s1-pro on fresh generated items not lower than the incumbent's. Both must pass |

In the 1.1 calibration, an online FP8 build of Rune did not pass the identical-output check; faster exact inference code can.

## Submission format

A competition hotkey commits (at most 128 bytes):

reax-comp/1:<track>:<hf_repo>@<40-hex commit>

The public Hugging Face repository at that commit must contain:

- `reax-submission.json`: track, the base manifest it claims to serve, the runtime image recipe (Dockerfile with a base image pinned by digest and pinned packages), the weights list with sha256, and for quantised s1-pro weights the exact reproducible recipe (tool, pinned version, command) that derives them from the pinned Rune weights.

- The runtime: a sidecar serving the existing 1.1 internal contract (`POST /internal/v1/decide`, `/health`, loopback, token), so a winning runtime can later be adopted by inference miners through a new manifest.

- A model card with the licence of everything inside (Apache or MIT compatible only).

The commit hash pins everything; a later push changes nothing for that submission. Submission time is the block of the commitment, and the earlier block wins a tie.

## Review and sandbox

An evaluator runs each submission on isolated rented GPU pods, never on the project's own servers and never with secrets. In the first version the evaluator is run by the owner; results are signed, published with full logs and seeds, and anyone can rerun them. That is a stated trust assumption; a fully decentralised evaluation is a later step.

- Fetch the repository at the pinned commit; reject oversized files, symlinks leaving the tree and LFS pointers to other repositories.

- Automatic code review before anything runs. Static checks for network code paths, subprocess or eval of fetched data, obfuscated blobs, references to hosted LLM endpoints, reads of environment secrets and benchmark detection; then an LLM review with a verdict of PASS, FAIL or NEEDS-HUMAN. Anything but PASS stops the pipeline and is published.

- Sandboxed build and run: the image is built from the submitted Dockerfile and runs with `--network none`, a read-only root, no secrets and CPU, RAM and GPU limits; weights are mounted read-only after their hashes match.

- Equivalence on fresh items whose generator seeds are drawn after the submission block and revealed in the scoreboard.

- Speed and cost on reference hardware (RTX PRO 6000 96 GB for both tracks at first): sustained decisions per second at p95 of at most 300 ms (s1-fast) or 1 s (s1-pro) on a fixed public workload mix, three runs, median. Score is throughput at equal or better quality.

## Winner rules

- Margin: a challenger replaces the incumbent only with at least 5 % higher throughput (for s1-fast, or at least 5 % lower cost at equal throughput), measured in the same batch as a fresh re-measurement of the incumbent.

- Holding period: a new number one is confirmed after a second evaluation at least 24 hours later reproduces the margin; until then the incumbent keeps the 20 %.

- Copy detection: identical weight hashes, or runtime code differing only cosmetically, credit the earlier submission and disqualify the copy. Work derived from another submission must beat it by the margin.

- Re-measurement: the incumbent is re-measured weekly; if it fails a gate (for example its repository disappears) the title moves to the next valid submission.

## Main threats and handling

- Benchmark detection: fresh items with post-hoc seeds, sealed JevBench items that never leave the owner pipeline, static and LLM review.

- Calling a hosted model: no network during scored runs; static review flags client code.

- Weight copying: copy detection, earliest block, margin for derived work.

- Many submissions: a registration cost per competition hotkey and a rate-limited queue per coldkey.

- Evaluator bias or compromise: signed published receipts and reproducible reruns.

## Not in scope yet

Decentralised evaluation and customer fine-tuning jobs through the competition. See the roadmap (https://reax.dev/roadmap/).

---

URL: https://reax.dev/miners/

Participate

# Miner guide

A REAX miner serves an approved decision model behind a signed HTTP endpoint. It answers finite-answer questions with complete probability distributions, fast and faithfully to the reference model. This guide covers what you serve, the contract you implement, what validators expect, and how the reference miner runs.

No miner can join yet

There is no public miner package, no registration and no netuid. The reference miner is private pre-release code that runs locally. Image serving is disabled at the network miner, and the permissionless route carries synthetic traffic only. To discuss operating a miner, use reax.co/apply (https://reax.co/apply/).

Release 1.1.0rc1

This guide follows the earlier spec 0.6 design. In release 1.1.0rc1 (pre-release, local-chain tested, not on testnet or mainnet) a miner serves exactly one System1 production model, s1-fast or s1-pro; see Inference mining (1.1) (https://reax.dev/mining/).

## What a miner serves

Miners serve approved model manifests only. The v1 catalog is closed: the owner-signed catalog `reax.catalog.v1` maps each public `model` alias to a list of approved manifests, and a manifest is approved for a question family only after it passes both an absolute quality grade and a power-admission check (see incentives (https://reax.dev/incentives/#admission)). You cannot bring your own model. An open-model competition would need a new major spec version.

A manifest is identified by `manifest_sha256`, the SHA-256 of the canonical JSON object:

```
{
  "model_alias": "…",
  "weights": [{"path": "…", "sha256": "…"}],
  "tokenizer_sha256": "…",
  "config_sha256": "…",
  "adapter_sha256": null,
  "engine_image_digest": "…",
  "inference_config": {
    "dtype": "…",
    "quantization": "…",
    "max_context": 0,
    "prob_extraction": "label_logits_v1",
    "prompt_template_sha256": "…"
  }
}
```

Probabilities must come from a deterministic extraction, never from sampled text:

label_logits_v1Candidates rendered in dispatch order with single-token labels; one forward pass; softmax (float32 or higher) over the label-token logits at the answer position.
seq_logprob_v1For multi-token candidates: `p_k ∝ exp(Σ log p(token_j | prefix))` with teacher forcing.

Temperature, top-p and seeds are irrelevant to `p`. Free-text generation followed by parsing is forbidden as a probability source. The miner and the reference processor must use the same engine image digest and prompt template.

Code today vs spec

The reference miner does not yet sign a full manifest digest. It binds a single `model_revision`: the exact lowercase SHA-256 revision reported by its local engine. The response is rejected if the engine reports a different revision. The manifest digest and `prob_extraction` field are spec 0.6 targets.

## Request and response contract

The reference miner exposes two routes:

| Route | Purpose |

| `POST /v1/decide` | Signed decision request in, signed decision response out |

| `GET /healthz` | Returns `{"schema":"reax.miner.v1","status":"configured"}`. This means the configuration loaded; it is not a model-readiness check |

### Request

A decide call must carry exactly one `Reax-Authorization` header, `Content-Type: application/json` and no `Content-Encoding`. The header is checked before the body is read, so unknown callers are rejected before intake. The body is a signed `reax.request.v2` envelope whose `audience` is your miner hotkey:

```
{
  "schema": "reax.request.v2",
  "audience": "<miner hotkey>",
  "caller": "<caller id>",
  "request": { "protocol_version": "1", "request_id": "d_…", "nonce": "…", "tier": "global_permissionless", "model": "…", "state": {}, "questions": {}, "deadline_unix_ms": 0 },
  "signature": "<Ed25519 over the RFC 8785 form of every other field, 128 hex chars>"
}
```

The miner then checks, in order: the caller grant and signature, audience and grant expiry, the request schema (see protocol reference (https://reax.dev/protocol/#request-schema)), the caller's permitted tiers, the image gate, GDPR admission for `gdpr_eu` requests, that real permissionless traffic is disabled, and finally a durable replay claim on `request_id` and `nonce`.

### Response

On success the miner returns a `reax.response.v1` envelope signed with its serving key:

```
{
  "schema": "reax.response.v1",
  "miner": "<miner hotkey>",
  "request_digest": "<SHA-256 of the canonical request envelope>",
  "nonce": "<request nonce>",
  "result": {
    "request_id": "d_…",
    "model": "…",
    "answers": { "<question id>": { "type": "choice", "choice": "…", "confidence": 0.0, "probabilities": {} } },
    "usage": { "input_tokens": 0, "output_tokens": 0, "decisions": 1 },
    "latency_ms": 0.0,
    "tokenizer_version": "…",
    "model_revision": "<64 hex chars>"
  },
  "signature": "<128 hex chars>"
}
```

The gateway rejects the response unless the signature verifies against your registered serving key, every binding (hotkey, nonce, request digest) matches, it arrived before the deadline, every answer passes validation, `decisions` equals the number of questions, and `model_revision` matches your approved identity. Answer formats are in the protocol reference (https://reax.dev/protocol/#answers).

Spec 0.6 replaces this body with `reax.response.v2`, which adds `serving_key_id`, `dispatch_id`, `manifest_sha256` and `completed_at_ms`; see miner response (https://reax.dev/protocol/#miner-response).

### Errors

Errors are generic JSON with no exception contents, because those could contain customer text or credentials:

| Status | Body | When |

| `400` | `invalid_request` | Schema, media type, size or image policy violation |

| `403` | `unauthorized_or_replayed` | Authentication, tier, admission or replay failure |

| `404` | `not_found` | Any other route or method |

| `429` | `capacity` | All `max_inflight` slots are busy |

| `502` | `inference_failed` | Engine failure or invalid engine output |

| `504` | `deadline_exceeded` | The request deadline passed |

## Latency and availability expectations

Validators score availability and latency from gateway measurements, not from anything the miner reports (`latency_ms` in the response is informational).

- Availability. Eligibility requires `A ≥ 0.50` (provisional). Timeouts, refused or reset connections, invalid or late responses and wrong identity or signature all count as failures. Validator or gateway faults, chain faults, capacity bursts and pre-dispatch expiry do not.

- Latency. Measured by the serving region's gateway on a monotonic clock, from dispatch to verified receipt. Full credit is reached once your p50 and p95 are within `(1 + η)` of the reference manifest's measured p50 and p95, with `η = 0.10` (provisional). Being faster than that earns nothing more. The reference latencies have not been measured yet, and the current validator code still uses a simpler linear latency transform (see incentives (https://reax.dev/incentives/#latency)).

- Deadlines. A request lives at most 60 seconds. The reference miner stops work at the request deadline and returns `504`.

- Capacity. The reference miner accepts up to `max_inflight` concurrent requests (1–64, default 4) and answers `429` beyond that. Spec 0.6 measures verified capacity with synchronized, closed-loop bursts; in its models, declaring more concurrency than you have never raises measured capacity (to be confirmed by simulation). The capacity prober is not implemented yet.

How these combine into a weight is covered in scoring and incentives (https://reax.dev/incentives/).

## GDPR tier vs permissionless tier

| Requirement | GDPR tier (`gdpr_eu`) | Permissionless (`global_permissionless`) |

| Operator | EU-established legal entity; off-chain KYB, contract and DPA | Any chain-registered hotkey |

| Admission | Listed in a currently valid signed admission snapshot that binds hotkey, models, exact model revision and serving public key | Signed miner record plus conformance; eligibility after the first complete fidelity window |

| Location | Every processing country and every subprocessor country must be in the EU; establishment country alone never satisfies a region | No location claim is made or accepted |

| Data | Admitted EU requests; the operator sees plaintext while inferring | Synthetic traffic only; never personal, sensitive or GDPR-tier payloads |

| Endpoint | Fixed HTTPS origin, TLS SPKI and serving key bound in the admission entry | Origin and serving key declared in the signed record; unproven origin claims fail your own conformance |

| Revocation | A signed, restrict-only revocation feed can remove eligibility for a hotkey, operator, serving key, manifest, origin or subprocessor at any time. Revocations never expire; only an explicit, authorized lift removes one |

Spec 0.6 defines the permissionless record as `reax.miner.v1`, signed by both the hotkey and the serving key, containing the endpoint origin, serving key, manifests, declared `max_inflight` and declared `hw_config`. Admission is legal and contractual work as well as technical: evidence digests bind records but do not make them true, and legal review is required before any public GDPR wording.

## Running the reference miner

The reference miner is a bounded ASGI app (`reax_subnet.miner`) that forwards validated requests to your own co-located inference engine and signs the result. You need access to the private source and the `server` extra.

### Configuration

Create a public JSON config outside the repository. It holds public metadata and file paths only, never private keys or tokens. Replace every value with your own; the caller public key below is a placeholder, and `expires_at_ms` must be a future Unix time in milliseconds.

```
{
  "schema": "reax.miner.config.v2",
  "hotkey": "operator-assigned-hotkey",
  "model_revision": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "engine_url": "http://127.0.0.1:8010",
  "serving_private_key_file": "/run/reax/secrets/serving-private-key",
  "engine_token_file": "/run/reax/secrets/engine-token",
  "replay_database": "/var/lib/reax/replay.sqlite3",
  "max_inflight": 4,
  "callers": {
    "synthetic-evaluator": {
      "public_key": "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
      "tiers": ["global_permissionless"],
      "expires_at_ms": 4102444800000,
      "data_class": "synthetic"
    }
  }
}
```

| Field | Rule |

| `hotkey` | Your miner identity; also the envelope `audience` |

| `model_revision` | Exact lowercase 64-character SHA-256 reported by the engine |

| `engine_url` | Loopback origin only: `127.0.0.1` or `::1` over HTTP; `localhost` only over HTTPS; no path; no CLI override |

| `serving_private_key_file` | Absolute path to exactly 32 raw Ed25519 private-key bytes |

| `engine_token_file` | Absolute path to the engine token as UTF-8 text |

| `replay_database` | Absolute path to a writable SQLite file shared by all workers on the host |

| `max_inflight` | Optional, 1–64, default 4 |

| `callers` | Caller grants: 32-byte hex public key, tiers, expiry and exactly one data class. Permissionless grants must be `synthetic` in this prototype |

| `admission` | Optional `{"database", "verification_keys"}`; required when any grant includes `gdpr_eu` |

Both secret files must be regular, non-symlink files with no group or world permissions, readable by the process owner. Mount them from a secret manager or protected host path; keep secret values out of config, shell history, images, logs and source control.

### Start

```
python3 -m reax_subnet.miner --config /etc/reax/miner.json
```

By default the server binds `127.0.0.1:8011` (`--host` and `--port` override), runs one Uvicorn worker, disables access logging and returns generic errors. A rejected configuration prints only `miner configuration rejected` and exits with `2`. Put a TLS-terminating, authenticated proxy in front before allowing any network access.

### Container hardening

The prototype image is designed to run read-only as a non-root user with all capabilities dropped, secrets and config mounted read-only, and one writable state mount:

```
docker run --rm \
  --read-only \
  --user 10001:10001 \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  --pids-limit=64 \
  --memory=4g \
  --cpus=2 \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --mount type=bind,src=/etc/reax/miner.json,dst=/run/reax/config/miner.json,readonly \
  --mount type=bind,src=/etc/reax/secrets/serving-private-key,dst=/run/reax/secrets/serving-private-key,readonly \
  --mount type=bind,src=/etc/reax/secrets/engine-token,dst=/run/reax/secrets/engine-token,readonly \
  --mount type=bind,src=/var/lib/reax,dst=/var/lib/reax \
  -p 127.0.0.1:8011:8011 \
  reax-miner:local
```

These limits apply to the miner container, not to your inference engine. The image build has not been run as part of a release, and it does not register with Bittensor or connect to a chain.

## Hardware

No hardware requirements are published. Under spec 0.6 each approved manifest lists `admitted_hw_configs` (GPU class, driver major version, batch sizes) for which the honest measurement noise has been measured. A miner on a configuration outside that list is `unsupported`: no weight and no penalty until the configuration is calibrated. No configuration has been admitted yet, so do not buy hardware for REAX on the basis of these docs.

## Images

The protocol allows up to four PNG, JPEG or WebP images per request, but image serving is disabled at the network miner. An isolated, sandboxed decode-and-normalize worker exists behind a closed deployment gate; it must pass review and a self-test inside the exact serving image before image traffic is enabled. Requests with images are rejected with `400` today.

---

URL: https://reax.dev/validators/

Participate

# Validator guide

REAX validators do not grade answers against their own opinion. They measure whether each miner serves the approved model faithfully, using private schedules of probes that travel the same gateway path as ordinary requests, and they turn that evidence into weights once per epoch.

Provisional

Everything on this page follows design spec revision 0.6, which is not frozen; every constant marked (provisional) can change. Only one REAX-operated validator exists, and only in the local harness. While there is a single validator, independent validation and cross-validator consensus are not claimed.

Release 1.1.0rc1

This guide follows the earlier spec 0.6 design. In release 1.1.0rc1 (pre-release, local-chain tested, not on testnet or mainnet) a validator sends 8 fresh items per miner and round and recomputes the answers on its own reference runtime; see Verification & calibration (https://reax.dev/verification/).

## Responsibilities

- Build and keep private schedules of which items go to which miner, committed before dispatch and revealed only to registered auditors after an embargo.

- Generate identity items (fresh, unlabelled) and hold a sealed labelled pool with registered provenance.

- Inject every scored probe through the gateway, never directly to a miner endpoint.

- Verify signed dispatch records and pair miner outputs with reference outputs computed on byte-identical payloads.

- Run the window tests, compute each miner's gain, apply operator-group caps, and submit weights through commit-reveal.

- Publish commitments and aggregate statistics, never seeds, leaves or item contents.

Validators receive no customer content and no organic metadata. They must be independent of other validators.

## Private schedules

At the start of each epoch the validator commits to a secret seed `s_e` and binds it to a public randomness beacon it cannot predict:

c_e = H("reax/sched/v1" ‖ s_e ‖ validator_hotkey ‖ epoch ‖ policy_digest)seed = HKDF(s_e, salt = drand_randomness(r_e), info = "reax/schedule/v1")

The commitment `c_e` goes into the validator's append-only ledger (anchored on chain where the chain profile allows). The drand round `r_e` is scheduled at least 60 s (provisional) after `c_e`, and no scored probe or burst is dispatched before `r_e` is published. One commitment can therefore never produce two valid schedules.

Allocation never depends on score or rank. Each validator has a disjoint partition of items, and items are grouped into independence clusters: at most one observation per cluster per miner per window counts.

## Probes through the gateway

Probes are injected through the gateway's validator-to-gateway API. They leave the gateway with the same ingress caller ID, TLS configuration, egress addresses and connection pooling as organic traffic. The gateway-to-miner envelope contains no data class, no probe, organic or burst flag, and no customer or tenant identifier, and receipts carry the same fields for every dispatch so they do not reveal probe status.

For each injected dispatch the validator receives a gateway-signed record: `dispatch_id`, miner hotkey, `miner_payload_sha256`, monotonic dispatch and receipt timestamps, outcome and the miner-signed response. Only timing is gateway-attested.

Where indistinguishability is claimed

Probe timing and field shapes follow privacy-reviewed organic traffic profiles on the GDPR tier. Content-level indistinguishability is not assumed, which is why the organic identity shadow is mandatory before real traffic. The permissionless route carries only validator-generated synthetic traffic, so indistinguishability is not claimed there at all.

## Identity stream and labelled pool

| Source | What it is | Used for |

| Identity stream | Fresh unlabelled items from versioned deterministic generators, each dispatched exactly once | Identity statistic `t = TV(p_miner, p_ref)` |

| Labelled pool | Sealed items with registered provenance, per-validator partition | Quality non-inferiority `d`, availability, latency |

| Burst items | Fresh sealed unlabelled items generated after `r_e`, same generator mix as the identity stream | Verified capacity and the burst identity audit |

| Reference outputs | `p_ref` computed by the reference processor on the exact dispatched bytes | Pairing partner for `t` and `d`; never a label |

| Organic shadow | Designed, disabled by default (see incentives (https://reax.dev/incentives/#shadow)) | Organic identity verdict only |

### Label provenance

Every labelled item carries a `label_source` of `deterministic` (computed by a registered checker), `resolved` (fixed before an external resolution) or `human` (at least two independent annotators with an agreement statistic). A model may draft question text but must never decide a label or break a tie. Agreement between models is a divergence signal, not ground truth. A family whose items lack registered provenance is unsupported.

### Reuse rules

- An identity item is dispatched exactly once.

- A labelled item goes to at most `R_lab = 8` (provisional) distinct hotkeys, at most one hotkey per operator group, and never twice to the same miner. With fewer than 32 scheduled miners (`N < 32`), `R_lab = 1`.

- Every item has a per-item secret that fixes its candidate permutation for life, so the same item always renders byte-identical `miner_payload` bytes. An observation whose payload digest does not match the reference record is discarded as `payload_binding_mismatch`, with no effect on the miner.

## Epoch pipeline

A ledger epoch is `epoch_tempos = 4` chain tempos (provisional), with the tempo taken only from the chain-profile readback. Fidelity is tested over windows of `W = 6` consecutive, non-overlapping epochs, each evaluated exactly once at window close.

- Commit. Publish `c_e`; wait for drand round `r_e`; derive the schedule seed.

- Schedule. Per miner and epoch: `n_lab = 48` labelled items, `n_id = 334` identity items and `b_e = 4` capacity bursts (all provisional). If the labelled pool or reference compute cannot cover this, reduce uniformly to a floor; below the floor the family is unsupported network-wide for that epoch and no miner is penalized.

- Dispatch. Inject via the gateway; collect gateway-signed dispatch records.

- Pair. Match each observation with its reference output on the exact payload bytes.

- Window tests. At window close, run the identity, quality and burst-audit tests (and the organic verdict, when enabled). Apply the two-strike rule.

- Gain. Compute each miner's gain, apply the ramp, group miners by operator and water-fill under the per-operator cap. Abstain if the rules require it.

- Submit. Run the fail-closed chain checks, commit the weight vector, and verify the applied weights after the automatic reveal.

- Publish. After epoch close: `c_e`, `r_e`, the root of the validator's own probe leaves, and aggregate counts and pass rates. Seeds, leaves and item contents are never published.

## Scoring summary

Identity and quality are hard gates, not scores. Among miners that pass them, the raw gain is:

g_i = F_i × A_i × (0.8 + 0.2 × L_i) × κ_i

F_i1 unless the miner is `fidelity_failed` in a family it serves (two consecutive failing windows).
A_iAvailability: miner-attributable successes over miner-attributable scheduled attempts; eligibility needs `A ≥ 0.50` (provisional).
L_iLatency credit in [0, 1], capped so that anything within `(1 + η)` of the reference earns full credit.
κ_iVerified serving capacity in reference units, from synchronized audited bursts.

- Ramp. Increases are limited to `ρ = 0.5` (provisional) of the new gain per epoch; decreases apply at once. A new miner reaches full gain in its second supported epoch.

- Two strikes. A first failing window puts the miner in `fidelity_watch` (gain frozen, next window uses only never-exposed items). A second consecutive failing window sets `F = 0` and `κ = 0` for the affected epochs. Exclusion from the network is disabled in this revision.

- Caps. Miners are grouped by operator (GDPR `operator_id`; permissionless coldkey plus proven linkage). Group shares are water-filled under `per_operator_cap = 0.40` (provisional). With fewer than ⌈1/cap⌉ positive groups, the validator abstains.

The full definitions and every formula are in scoring and incentives (https://reax.dev/incentives/).

## Weight submission and commit-reveal

REAX targets Bittensor's timelocked commit-reveal (CommitRevealWeightsVersion 4): the validator commits an encrypted weight vector, and the chain reveals and applies it automatically after the reveal period, without a separate reveal transaction. Commit-reveal delays weight copying for the reveal interval; it does not stop copying afterwards, shared operators or collusion, which is why private schedules and monitoring stay required.

### Fail-closed rules

- Chain profile. Each network has an owner-signed `reax.chainprofile.v1` (genesis hash, allowed runtime `spec_version` range, netuid, SDK version and wheel hash, source commit, mode and expected hyperparameters). It is created only from read-only readbacks. At connect time and before every commit the adapter compares live chain state with it; any mismatch means no transaction, an alert and a signed `chain_mismatch` receipt, while serving continues.

- Hotkey keying. At the commit block each hotkey is mapped to its current UID; deregistered or moved hotkeys are dropped and the vector renormalized, and it is committed only if still cap-feasible.

- Pre-commit checks. The canonical u16 vector is checked against the readback `min_allowed_weights`, `max_weight_limit` and `weights_version`. A vector the chain would reject is not committed; the decision is `abstain` with a `chain_constraint` receipt.

- Staleness. A vector from epoch `e` is committed only if its predicted reveal lies within `epoch_tempos + commit_reveal_period + 1` tempos (provisional) of the close of `e`.

- Transport. No retries beyond the weights rate limit; RPC loss means skip. Weight commits are the only automatic transactions. Keys are held by reference and never printed.

### Post-reveal readback

`LastUpdate` is refreshed when a commit is accepted, not when the revealed weights are applied, so a fresh `LastUpdate` does not prove application. The adapter pairs commit inclusion with the later weights-revealed event and the applied weight state, canonicalizes both sides to u16 and compares them within ±1. A missing reveal raises `reveal_missing`, a larger difference `reveal_mismatch`; two consecutive failures pause submission. The adapter also publishes the weight mass that landed on UIDs re-registered between commit and reveal.

### Abstain

`abstain` means no weight transaction for the epoch, plus a signed abstain receipt. It applies when there is no supported family or candidate, the cap is infeasible, the chain profile mismatches, the item pool or reference compute is exhausted, the multi-family gate is closed, capacity proof is missing for external miners on a non-local network, or a chain constraint would be violated. On local and test networks the policy is pure abstain.

## What the code does today

The private reference implements a provisional slice of this pipeline in `reax_subnet.validator` (`score_epoch`, `weights_from_epochs`) and `reax_subnet.chain`:

- Signed `EpochPolicy` and `MinerEpoch` documents verified against separate owner and ingestor keys; an unverified policy abstains with `policy_signature_unverified`.

- Six-epoch fidelity windows of at least 288 balanced clusters, identity tolerance 0.05 and quality tolerance 0.02 (placeholders), the two-strike state machine and the 0.5 ramp.

- Capacity fixed at 1 and group reward equal to the maximum member gain, water-filled at a 0.40 cap. Only a single question family is supported; multi-family policies abstain.

- Network profiles: `local` allows synthetic arithmetic; `testnet_mechanics` allows weights only for an owner-signed allowlist of REAX-owned hotkeys; `testnet` and `mainnet` always abstain.

- `TestnetChainAdapter` reads a block-pinned snapshot and produces dry-run weight plans. It has no `execute` method, no wallet API and no plain `SetWeights` fallback.

Several spec 0.6 elements are not implemented yet: the capacity prober, identity generators at production scale, the reference processor, the joint gateway Merkle root, the drand-bound schedule and actual commit transactions. See the roadmap (https://reax.dev/roadmap/).

---

URL: https://reax.dev/testnet/

Participate

# Testnet preparation guide

This is a preparation guide, not a joining guide. It explains what REAX testnet participation will require, which read-only chain checks already exist, and how to prepare keys and test TAO safely when the time comes.

No netuid yet

No REAX subnet is registered on Bittensor testnet or mainnet. There is no netuid, no owner UID and no registered miner or validator. Nothing described here should be read as REAX running on testnet today. Check reax.co/status (https://reax.co/status/) and the changelog (https://reax.dev/changelog/) for updates.

## What the testnet stage requires

Testnet is rollout gate G3. It opens only after the spec is frozen (G0), the local harness passes against a disposable local Subtensor with miners in both tiers (G1), and adversarial simulations pass (G2). At G3:

- REAX uses the official Bittensor test network only, with test TAO only and newly created, test-only keys.

- The signed chain profile for the network is built from read-only readbacks at that time, including the Subtensor source commit. It is never written from memory.

- Scoring runs in the `testnet_mechanics` profile until verified capacity measurement is active. In that profile, weights go only to an owner-signed allowlist of REAX-owned hotkeys; externally operated miners receive no weight on testnet until the capacity activation conditions are met. The plain `testnet` profile abstains.

- No mainnet action of any kind. Mainnet (G6) requires a separate, explicit approval of a stated cost and coldkey.

## Network facts

The reference code allows exactly one endpoint, the official test network:

```
wss://test.finney.opentensor.ai:443
```

A read-only receipt on 30 September 2026 recorded:

| Fact | Observed value |

| Genesis hash | `0x8f9cf856bf558a14440e75569c9e58594757048d7b3a84b5d25f6bd978263105` |

| Runtime | spec version 471, transaction version 1, metadata V15 |

| Pinned SDK | `bittensor==11.1.0` |

| Subnet creation cost | 1 testTAO at the observed block, plus fees and account reserve |

| New-subnet neuron burn default | 1 testTAO (source default; owner or governance may change it) |

These are dated observations for preparation, not configuration. Costs, runtime and parameters must be read again at the block where any action is taken. Parameters observed on other subnets (for example netuid 1, used only as a compatibility specimen) must not be reused as REAX parameters.

## Read-only checks that exist today

All of these read chain state without a wallet and submit nothing.

### Endpoint identity receipt

```
python3 scripts/testnet_readonly.py --output /path/to/private/testnet-readonly.json
```

Four read-only JSON-RPC calls, spaced 1.1 s apart with 5 s timeouts, record the genesis hash, a finalized block, the runtime version and the SHA-256 of the raw metadata. It requires `websocket-client`, which is installed separately, does not import the SDK and never opens a wallet. An observed genesis is a candidate pin that needs independent review, not trusted configuration.

### SDK snapshot reader and weight preview

In an isolated environment with the pinned SDK, `SDKTestnetReader` reads one finalized-block snapshot (metagraph UIDs and hotkeys, validator permits, commit-reveal and weight hyperparameters), and `TestnetChainAdapter` validates it and produces a dry-run weight plan. The preview builds the real SDK `CommitWeights` intent with u16-quantized weights and returns no signature, ciphertext, fee estimate or submitted transaction. The adapter refuses mainnet and custom endpoints, the root netuid, a wrong genesis, mismatched SDK or runtime metadata, stale or future snapshots, recycled UIDs, missing validator permits, disabled commit-reveal and vectors that violate chain limits.

Before any REAX use it needs inputs that do not exist yet: a REAX test netuid, reviewed genesis and metadata pins, and REAX-owned validator and miner hotkeys.

## Key hygiene

Never reuse keys

Create new, test-only coldkeys and hotkeys in a new empty private directory. Never reuse an existing wallet or mnemonic, never pass passwords on the command line, and never put keys, mnemonics or tokens in repositories, images, logs or environment files.

The pinned CLI's wallet creation prints mnemonics. The prepared (not yet executed) procedure uses the SDK instead, with mnemonic printing suppressed, both keys encrypted and overwriting disabled, run in a private terminal without output capture:

```
wallet.create_new_coldkey(n_words=24, use_password=True, overwrite=False,
    suppress=True, save_coldkey_to_env=False, coldkey_password=PASSWORD_FROM_GETPASS)
wallet.create_new_hotkey(n_words=24, use_password=True, overwrite=False,
    suppress=True, save_hotkey_to_env=False, hotkey_password=PASSWORD_FROM_GETPASS)
# Record only the public SS58 addresses. Keep the encrypted keyfiles private.
```

`PASSWORD_FROM_GETPASS` is interactive input, never an argument, environment variable or logged value. REAX serving keys (Ed25519) are separate from Bittensor wallet keys and are never derived from them.

## Getting test TAO

- The public testnet has no self-service faucet. The proof-of-work faucet exists only for local development chains built with the `pow-faucet` feature.

- Test TAO is requested through the Bittensor community Discord, linked from the official Bittensor documentation. Check the channel's current rules and request format before asking.

- A request needs only your new public coldkey address, the network (testnet), the purpose and an amount justified by freshly read costs. Never attach a seed, mnemonic, private key or wallet file.

## Preparation checklist

- Run the local harness (https://reax.dev/quickstart/) and read what its receipt does and does not prove.

- Set up an isolated environment with `bittensor==11.1.0` and verify the installed version and wheel hash before any chain read.

- Run the read-only endpoint receipt and compare the genesis with an independently reviewed value.

- Create new test-only keys with the procedure above; record only public addresses.

- Wait until a REAX test netuid is published. Read registration cost, burn and hyperparameters at the target block before doing anything that spends test TAO.

- Register and serve only under the `testnet_mechanics` rules published with that announcement.

Prospective operators who want to prepare with the private source can request access at reax.co/apply (https://reax.co/apply/).

---

URL: https://reax.dev/protocol/

Reference

# Protocol reference

Constants, the decision request schema, Jev-compatible question and answer types, probability transport, signed envelopes, miner responses, receipts, admission snapshots and error classes. Field names are taken from the reference code and spec revision 0.6.

Pre-release wire format

These formats will change before any network launch. Where the reference code and spec 0.6 differ, this page shows what the code does today and notes the spec target. Values marked (provisional) live in signed policy and are not protocol facts.

## Constants

| Constant | Value | Notes |

| Canonical form | RFC 8785 (JCS) | Signed field names ASCII only. Already used by the reference code; required from G1 |

| Signature | Ed25519 (RFC 8032) | Public keys validated as curve points on load. Serving keys are separate from Bittensor wallet keys |

| Hash | SHA-256, lowercase hex |  |

| Clock skew allowance | 2 000 ms (provisional) |  |

| Request lifetime | ≤ 60 000 ms | `MAX_REQUEST_LIFETIME_MS` in code |

| Request bytes | ≤ 256 KiB excluding images (provisional); `state` ≤ 64 KiB; each question text or criteria string ≤ 8 KiB | Spec target. Code today: miner wire body ≤ 1 MiB while images are disabled |

| Images | ≤ 4 per request; each ≤ 6 MiB decoded; PNG, JPEG or WebP with matching magic bytes; ≤ 4 096 px per side and ≤ 16 777 216 px | Decoded only in an isolated worker. Disabled at the network miner today. Code today: ≤ 4 000 000 px |

| Sequence numbers | Integers in [1, 253 − 1] |  |

| Ledger epoch | `epoch_tempos` = 4 tempos (provisional) | Tempo read only from the chain-profile readback |

| Fidelity window | W = 6 ledger epochs | Strictly non-overlapping; one statistical look per window |

| Probability transport | JSON numbers read as IEEE-754 binary64 | Sum within 1e-6 of 1 is renormalized; anything else is rejected |

| Questions per request | ≤ 32 | `MAX_QUESTIONS` in code |

| Options or levels per question | 2 – 64 | `MAX_OPTIONS` in code |

## Request schema

A decision request is a JSON object validated by `DecisionRequest.from_payload`. Unknown fields are rejected, not ignored. All values must be finite JSON that RFC 8785 can canonicalize.

| Field | Type | Rule |

| `protocol_version` | string | Must be `"1"` |

| `request_id` | string | `^[A-Za-z0-9][A-Za-z0-9_.:-]{0,127}$` |

| `nonce` | string | 32–128 URL-safe characters `[A-Za-z0-9_-]` |

| `tier` | string | `gdpr_eu` or `global_permissionless` |

| `model` | string | Public catalog alias, `^[a-z0-9][a-z0-9._-]{0,63}$` |

| `state` | any JSON | The context the questions are about |

| `questions` | object | 1–32 questions keyed by stable IDs (same pattern as `request_id`) |

| `images` | array, optional | ≤ 4 data URLs `data:image/(png|jpeg|webp);base64,…`, each non-empty and ≤ 6 MiB decoded |

| `deadline_unix_ms` | integer | In the future and at most 60 000 ms (plus the peer skew allowance of up to 2 000 ms) ahead |

An illustrative request with one question of each type:

```
{
  "protocol_version": "1",
  "request_id": "req-0001",
  "nonce": "b3Vy-ZXhhbXBsZS1ub25jZS0zMi1jaGFycy1taW4",
  "tier": "global_permissionless",
  "model": "example-alias",
  "state": { "ticket": "Order 1042 arrived damaged. The customer wants their money back." },
  "questions": {
    "wants_refund": { "type": "noul", "instructions": "Is the customer asking for a refund?" },
    "queue": {
      "type": "choice",
      "instructions": "Which queue should handle this ticket?",
      "criteria": { "billing": "Payments and refunds", "shipping": "Delivery problems", "other": "Anything else" }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": ["low", "medium", "high"]
    }
  },
  "deadline_unix_ms": 1790000000000
}
```

The model alias is a placeholder; no public catalog is published yet. A real `deadline_unix_ms` must be within 60 seconds of the current time.

## Question types

REAX keeps the Jev-compatible typed-decision shape. Each question object may contain only `type`, `instructions` (any JSON) and `criteria`.

| Type | Candidate set | `criteria` |

| `noul` | true / false | Optional. If present, an object with exactly the keys `true` and `false` |

| `choice` | One of N options | Required object with 2–64 entries keyed by option ID |

| `score` | One of N ordered levels | Required array of 2–64 levels, lowest first |

## Answers

A response must contain exactly one answer per question ID. Each answer must have exactly the fields below; any extra field (for example an `explanation`) fails validation.

| Type | Fields | Rules |

| `noul` | `type`, `noul` | `noul` is a probability in [0, 1] |

| `choice` | `type`, `choice`, `confidence`, `probabilities` | `probabilities` has exactly the declared option IDs; `choice` is the first maximum-probability option; `confidence` equals its probability |

| `score` | `type`, `score`, `confidence`, `probabilities`, `legend` | `probabilities` keyed `"0"`…`"N-1"`; `score` equals the expected level Σ i·pi; `confidence` equals the largest probability; `legend` maps each index to its original criteria level |

Answers for the request above:

```
{
  "wants_refund": { "type": "noul", "noul": 0.94 },
  "queue": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.81,
    "probabilities": { "billing": 0.81, "shipping": 0.15, "other": 0.04 }
  },
  "urgency": {
    "type": "score",
    "score": 1.1,
    "confidence": 0.5,
    "probabilities": { "0": 0.2, "1": 0.5, "2": 0.3 },
    "legend": { "0": "low", "1": "medium", "2": "high" }
  }
}
```

## Probability transport

- Every probability is a finite JSON number in [0, 1], read as IEEE-754 binary64. Booleans are not numbers.

- A distribution must cover exactly the declared outcomes and sum to 1 within `1e-6` (`PROBABILITY_TOLERANCE`). Spec 0.6: the validator renormalizes such a vector and rejects any other; a vector summing to 1 ± 1e-5 is rejected.

- Derived fields (`choice`, `confidence`, `score`) must agree with the distribution within the same 1e-6 tolerance.

- Probabilities must come from deterministic extraction (`label_logits_v1` or `seq_logprob_v1`), never from parsing generated text. See the miner guide (https://reax.dev/miners/#what-you-serve).

## Envelopes

### Signed request envelope (code)

Both the gateway ingress and the miner accept a `reax.request.v2` envelope. The signature is Ed25519 over the RFC 8785 form of the envelope without its `signature` field, hex-encoded (128 characters). It must have exactly these fields:

```
{
  "schema": "reax.request.v2",
  "audience": "<receiver: gateway audience or miner hotkey>",
  "caller": "<caller id>",
  "request": { "…": "decision request, as above" },
  "signature": "<128 hex chars>"
}
```

The caller must hold an unexpired grant for the request's tier. A grant fixes the caller's public key, tiers, expiry and exactly one data class; the data class lives only in the grant and never on the wire, so a customer request cannot be relabelled as synthetic.

### Transport authorization header

Every HTTP call also carries `Reax-Authorization`: the unpadded base64url encoding of a signed `reax.transport.v1` document, at most 2 048 bytes. It lets the receiver reject unknown callers before reading the body.

```
{
  "schema": "reax.transport.v1",
  "caller": "<caller id>",
  "audience": "<receiver>",
  "body_sha256": "<SHA-256 of the exact body bytes>",
  "expires_at_ms": 0,
  "signature": "<128 hex chars>"
}
```

Receivers accept an expiry no more than 62 s ahead; the reference clients emit at most 10 s and never beyond the request deadline.

### Gateway dispatch

Before dispatch the gateway replaces the caller's `request_id` with a fresh `d_`-prefixed random ID and issues a fresh nonce, so customer-facing identifiers never reach a miner.

### Spec 0.6 targets

- Request token `reax.request.v2` signs `{schema, caller_id, key_id, audience, tier, data_class, model, request_id, nonce, request_sha256, issued_at, expires_at}`, where `request_sha256` is the JCS digest of the admitted payload. Grants come only from a signed caller registry `reax.callers.v1` and fix exactly one data class, `synthetic` or `real`.

- Projection. The gateway builds `miner_payload` from an explicit, versioned allow-list per request type (question type and text, candidate options in dispatch order, criteria, `state`, images, model alias) and drops everything else. A payload containing `data_class`, `synthetic`, `probe` or an equivalent field is rejected, not stripped.

- Gateway → miner envelope contains only schema, audience (miner hotkey, network, netuid), the gateway ingress caller ID, a fresh random `dispatch_id`, `miner_payload`, nonce, deadline and the gateway signature. It must not contain a data class, a probe, organic or burst indicator, a customer or tenant identifier, or the System1 key.

Code vs spec

The code's data classes are `synthetic` and `customer` (spec: `synthetic` and `real`). The code forwards the full decision request, including its `tier` field, inside the miner envelope; spec 0.6 forwards only the allow-listed `miner_payload` and adds `dispatch_id`.

## Miner response

Code today: `reax.response.v1` with fields `schema`, `miner`, `request_digest` (SHA-256 of the canonical request envelope), `nonce`, `result` and `signature`. `result` contains `request_id`, `model`, `answers`, `usage` (`input_tokens`, `output_tokens`, `decisions`), `latency_ms`, `tokenizer_version` and `model_revision`. A full example is in the miner guide (https://reax.dev/miners/#response).

Spec 0.6: the signed body is `reax.response.v2`:

```
{
  "schema": "reax.response.v2",
  "miner_hotkey": "…",
  "serving_key_id": "…",
  "dispatch_id": "…",
  "request_digest": "<miner_payload_sha256>",
  "nonce": "…",
  "manifest_sha256": "…",
  "answers": { },
  "usage": { "input_tokens": 0, "output_tokens": 0, "decisions": 0 },
  "completed_at_ms": 0
}
```

The gateway must reject the response on any of: wrong signature or key; digest, dispatch ID or nonce mismatch; a `manifest_sha256` that is not the admitted or registered manifest; `decisions` not equal to the number of questions; an answer field outside the per-type allow-list; a probability vector that fails transport rules; arrival after the deadline on the gateway's monotonic clock; or a revocation of the miner, operator, serving key, manifest, origin or subprocessor observed while the request was in flight. `completed_at_ms` is informational.

## Receipts

Receipts are payload-free. They never contain the request, the answer, a customer identifier or a label.

| Code today (gateway ledger) | Spec 0.6 `reax.receipt.v2` |

| `request_id` (caller-scoped keyed ID), `tier`, `miner_uid`, `model_revision`, `policy_digest`, `response_digest`, `measured_latency_ms`, `observed_at_ms`, `status`, plus a ledger-keyed `signature` | Request ID, tier, data class, miner hotkey and UID, manifest, policy digest; request fingerprint, `miner_payload_sha256`, `dispatch_id`, response digest; usage, measured latency, outcome, delivery, billing-policy ID, `canon`; `leaf_commitment` on every receipt. Ed25519-signed with a `key_id` |

A receipt may say `authenticated` only after every check passes. It never says `verified`: signatures and digests do not prove model execution or answer correctness. Answers exist only in gateway memory until written to the caller; spec 0.6 target: a retry of a completed request returns `409 completed_not_retained` with the receipt ID and no answer. The code today returns `409 request_conflict`.

## Admission snapshot

GDPR-tier miners are admitted through a short-lived snapshot signed by the admission issuer. Serving processes hold only the public verification keys, and every verifier persists a monotonic sequence floor so an older snapshot can never be re-accepted.

| Level | Code today (`reax.admission.v2`) | Spec 0.6 (`reax.admission.v3`) |

| Document | `schema`, `key_id`, `sequence`, `issued_at`, `expires_at`, `entries`, `signature`; validity ≤ 24 h | Adds `network`, `genesis_hash`, `netuid`, `audiences`, `policy_epoch`; validity ≤ 24 h (6 h recommended, provisional) |

| Entry | `hotkey`, `country_code` (EU member state), `models`, `model_revisions`, `serving_public_key`, and SHA-256 evidence references `company_ref_sha256`, `dpa_sha256`, `kyb_sha256`, `location_attestation_sha256`, `identity_attestation_sha256` | `hotkey`, `coldkey`, `operator_id`, `establishment_country`, `processing_countries`, `subprocessors` (each with an authorization digest), `endpoint_origin`, `tls_spki_sha256`, `serving_public_key`, `manifests`, `models`, `evidence` |

Snapshots contain digests of independently checked evidence, never identity documents. Digests bind records; they do not make the records true. Spec 0.6 adds a durable, restrict-only revocation feed (`reax.revocation.v1`) whose entries never expire, a checkpoint that makes an emptied store fail closed, and routing that matches the requested region against every processing and subprocessor country.

## Error classes

### Reference code exceptions

| Exception | Raised when |

| `ProtocolError` | A request or answer violates the versioned schema (fields, formats, limits, probabilities, deadline) |

| `AuthenticationError` | Envelope, signature, audience, grant, tier or transport authorization fails, or a request or nonce was already claimed |

| `RouteDenied` | Policy leaves no eligible miner with capacity (for example a disabled route or a missing admission snapshot) |

| `IntegrityFailure` | A miner result does not match its approved identity, the question set, the answer rules or the deadline |

| `EngineProtocolError` | The local engine or a remote miner cannot satisfy the contract |

| `AdmissionError` | A signed admission snapshot is invalid, stale or rolled back |

| `ChainGuardError` | A chain identity, runtime, freshness or commit-reveal guard fails |

### HTTP status codes

| Status | Body `error` | Miner | Gateway |

| `400` | `invalid_request` | yes | yes |

| `403` | `unauthorized_or_replayed` | yes | yes |

| `404` | `not_found` | yes | yes |

| `409` | `request_conflict` | – | yes |

| `429` | `capacity` | yes | yes |

| `502` | `inference_failed` | yes | yes |

| `503` | `route_unavailable` | – | yes |

| `504` | `deadline_exceeded` | yes | yes |

### Attempt outcomes

Validators record every scheduled attempt with one typed outcome. The first five are scored attempts (success counts for the miner, the other four against it); the rest are excluded because the miner is not at fault or the attempt is not a scored dispatch.

| Outcome | Availability |

| `success` | Success |

| `timeout`, `unavailable`, `invalid`, `wrong_identity` | Miner-attributable failure |

| `queue_expired_before_dispatch`, `capacity_burst_unscored`, `validator_fault`, `gateway_egress_fault`, `chain_rpc_fault`, `revoked_in_flight` | Excluded |

### Named conditions in spec 0.6

revoked_in_flightA matching revocation was observed between dispatch and delivery: answer withheld, retryable `503`, charge voided, not scored.
revocation_staleThe revocation document is older than its freshness bound; GDPR dispatch fails closed.
payload_binding_mismatchDispatch and reference payload digests differ; observation discarded with no miner effect.
completed_not_retained`409` for a retry of a completed request; the answer is not stored anywhere (spec 0.6 target; code today returns `request_conflict`).
chain_mismatchLive chain state differs from the signed chain profile; no transaction.
chain_constraintThe weight vector would violate a chain constraint; the validator abstains.
reveal_missing / reveal_mismatchPost-reveal readback failed or differs by more than ±1 u16.

---

URL: https://reax.dev/incentives/

Reference

# Scoring and incentive mechanism

REAX rewards one thing: serving the approved model faithfully, reliably, at reference speed, with real capacity. This page explains in plain words how validators turn evidence into weights, then gives the formulas from spec revision 0.6.

Provisional mechanism

Spec 0.6 is not frozen. Every constant marked (provisional) lives in signed policy and can change; tolerances are placeholders until honest-noise measurements exist. No weights are set on any network today. Emissions are an incentive mechanism only: they are not customer billing, not a service guarantee and not a promise of any return.

Release 1.1.0rc1 supersedes this page as the current mechanism

This page describes the earlier design (spec revision 0.6: gain formula, fidelity windows, availability, capacity). The mechanism in release 1.1.0rc1 (pre-release, tested on a local chain, not on testnet or mainnet) is different: fresh items every round, recomputation on the same pinned model, a logit-space distance with thresholds 0.20, 0.50 and 2.0, a moving average and fixed pool shares. See Inference mining (1.1) (https://reax.dev/mining/) and Verification & calibration (https://reax.dev/verification/). A planned second track is described under Competition mining (https://reax.dev/competition/).

## In plain words

- Serve the right model. Validators compare your probabilities with the reference model's on the exact same bytes. If you consistently drift, you fail a hard gate and earn nothing for the affected epochs. Beating the reference's accuracy earns nothing extra; falling measurably below it fails the quality gate.

- Be there. Availability multiplies everything. Below 50 % (provisional) you are not eligible.

- Be as fast as the reference. Latency within 10 % (provisional) of the reference manifest gets full credit. Faster earns nothing extra, so a cheaper, faster substitute gains nothing.

- Bring real capacity. Verified capacity, measured in synchronized audited bursts, scales your weight. In the spec's models, declaring more concurrency than you have does not help.

- One operator, one share. Hotkeys are grouped by operator, and no group can take more than 40 % (provisional) of the weight.

## The gain formula

For each miner i and epoch, over the set Φi of question families its model alias covers:

g_i = F_i · A_i · (0.8 + 0.2 · L_i) · κ_iF_i = Π_{f ∈ Φ_i} 1[not fidelity_failed_{i,f}]L_i = Σ_{f ∈ Φ_i} w_f · L_{i,f}

There is no quality score, cost term or identity score inside `g`. Identity and quality act only as hard gates and through manifest admission. Two miners that both pass the gates differ only by availability, latency and capacity.

### Ramp

g^app_i(e) = min( g_i(e), g^app_i(e−1) + ρ · g_i(e) ),   ρ = 0.5 (provisional)

Increases are gradual and decreases apply at once. A miner in `fidelity_watch` cannot increase. Other miners joining or leaving change only the normalization.

## Fidelity gates

Two statistics compare a miner with the reference output `p_ref` for the same item:

identity:  t_i(x) = TV( p_i(x), p_ref(x) )  ∈ [0, 1]      no label neededquality:   d_i(x) = B( p_i(x), y ) − B( p_ref(x), y )  ∈ [−1, 1]Brier:     B = 1 − 0.5 · Σ_k (p_k − y_k)²

At window close each test uses a one-sided empirical-Bernstein bound (Maurer and Pontil 2009) on the window mean:

r_EB(n, V, b, δ) = √(2·V·ln(2/δ)/n) + 7·b·ln(2/δ) / (3·(n − 1))identity_fail  ⇔  mean t − r_EB(n_id, V, 1, δ_test) > τ_idquality_fail   ⇔  mean d + r_EB(n_lab, V, 2, δ_test) < −εburst_audit_fail is the identity test on the pooled window capacity sample; organic_identity_fail comes from the shadow when it is enabled.

| Parameter | Value |

| Identity window size `n_id,win` | 2 000 (provisional) |

| Labelled window size `n_lab,win` | 288 (provisional) |

| Burst audit sample `n_b,win` | 2 016 |

| Per-window error budget `δ_w` | 0.005 (provisional), split into a fixed `δ_test` = 0.000625 per test and a separate tripwire budget |

| Tolerances `τ_id`, `τ_item`, `ε` | 0.05, 0.04, 0.02: placeholders until measured per hardware configuration |

Code vs spec

The current validator code uses 288-cluster windows for both statistics and `δ = 0.01`; the 2 000-item identity window is the spec 0.6 target.

Two strikes. The first failing window puts the miner in `fidelity_watch`: its applied gain is frozen and the next window uses only never-exposed items. A second consecutive failing window, on disjoint evidence, makes it `fidelity_failed` for the affected epochs: `F = 0` and `κ = 0`. Exclusion from the network is disabled in this revision, because the independence assumption it would rest on is not yet proven; the miner is simply re-evaluated in the next window.

Support. A miner with too few items in its first window is `unsupported`: no weight and no penalty. A miner on a hardware configuration that has not been calibrated is also `unsupported`, never penalized.

## Model admission

Before any miner is scored on a manifest, the manifest itself must pass two checks per question family:

- Absolute grade. On at least 1 000 (provisional) label-balanced items, the lower bound of its skill over the uniform baseline must be at least 0.02 (provisional). A constant uniform predictor scores 0 and is not admitted. If the grade fails, the family is dropped for that manifest for every miner equally.

- Power admission. On at least 5 000 (provisional) identity items, the identity test must provably catch a signed panel of cheap substitutes (uniform, climatology, label-frequency and at least one cheaper sibling). If any panel member would go undetected, the manifest is not approved for that family.

Substitutes that stay within tolerance on most items are output-equivalent: they earn like the reference, and the catalog publishes every known one. Output fingerprinting never proves which weights are running; only separately evaluated, nonce-bound hardware attestation could do that.

## Availability

A_i = miner-attributable successes / miner-attributable scheduled attemptsPooled over supported families in the window. Eligibility requires A_i ≥ 0.50 (provisional).

Counted as failures: timeouts after dispatch, connection refused or reset, invalid or late responses, wrong identity or signature. Excluded: burst dispatches, pre-dispatch expiry, validator or gateway faults and injection-API failures, windows where the gateway's egress health probe failed, chain or RPC faults, `revoked_in_flight` and `payload_binding_mismatch`.

## Latency, capped at the reference

f_q(t) = clamp( 1 − max(0, t − (1 + η) · t_ref,q) / D_f , 0, 1 )     q ∈ {50, 95}L_{i,f} = 0.5 · f_50(p50_i) + 0.5 · f_95(p95_i)η = 0.10 (provisional); D_f = t_ref95 (provisional). A timeout enters as t = the request deadline.

Every miner whose p50 and p95 are within `(1 + η)` of the reference receives `L = 1`, and nothing below that earns more. A substitute that is faster than the reference therefore gains nothing over an honest miner at reference latency. Latency is measured by the serving region's gateway on a monotonic clock, from dispatch to verified receipt.

Worked example from the spec's acceptance vectors (tref50 = 400 ms, tref95 = 1 000 ms, η = 0.1): p50 = 300 ms and p95 = 900 ms gives L = 1.0; p50 = 640 ms and p95 = 1 600 ms gives f50 = 0.8, f95 = 0.5, L = 0.65. These are test values, not measured reference latencies.

Code vs spec

The current validator code uses a simpler transform, `L = 0.5·max(0, 1 − p50/deadline) + 0.5·max(0, 1 − p95/deadline)` against a signed per-family deadline, which is not capped at the reference. The capped `f_q` above is the spec 0.6 target.

## Hidden probes

Validators do not announce which requests are tests. On the GDPR tier, probes enter through the gateway with the same caller ID, TLS configuration, egress addresses and connection pooling as organic traffic; their deadlines, arrival times and field shapes follow privacy-reviewed organic profiles; and every receipt carries the same fields, so receipts do not reveal probe status. Identity items are used exactly once and labelled items are never shown twice to the same operator.

What is not assumed: that probe content is indistinguishable from real content. A generator's questions can differ from customers' questions, which is exactly why the organic identity shadow is mandatory before real traffic. On the permissionless route every dispatch is synthetic, so indistinguishability is not claimed there.

## Organic identity shadow

Designed, disabled by default, and mandatory before any real traffic. When enabled for a tier, the gateway sends a seed-selected fraction `r_sh = 0.02` (provisional) of organic dispatches synchronously to the reference processor, computes `t = TV(p_i, p_ref)` in memory, updates a per-miner, per-family, per-window accumulator, and drops payload and outputs. Nothing but the accumulator is persisted, and stored or asynchronous replay is forbidden.

At window close the validator receives only a gateway-signed verdict `{miner, family, window, verdict ∈ pass | fail | unsupported}`, with no counts. A miner fails if the mean identity test fails or if the share of items beyond per-item tolerance is credibly above 0.05 (provisional), which catches substitution on just part of the traffic. Fewer than 500 (provisional) shadowed items gives `unsupported`, which is never turned into `pass`.

Enabling it requires all of: the reference processor admitted for that tier, listed as a subprocessor in the DPA and admission workflow, covered by the System1 acceptance record, and a privacy review approving the aggregate outputs.

## Verified capacity

At `b_e = 4` (provisional) seed-derived times per epoch the gateway bursts every eligible miner at the same moment for `T_b = 60 s` (provisional), with fresh sealed items and a strict per-item deadline. Every dispatch is either a completion or a timeout. At window close one uniform audited sample of completions is compared with the reference, and

net_i(w) = C_{i,w} · (1 − 2 · k_{i,w} / n_{i,w}) − T_{i,w}κ̃_i(w) = max(0, net_i(w)) / (T_{b,w} · thr_ref)C = completions, T = timeouts, k of n audited completions outside per-item tolerance, thr_ref = measured reference throughput. Defined only with at least 336 (provisional) audited completions; otherwise capacity is insufficient.

A dropped item costs as much as an out-of-tolerance answer, so skipping hard items does not help, and, under the spec's stated assumptions, a content-independent stream that is out of tolerance on at least half its items adds nothing in expectation. Faster honest hardware is genuine capacity and is not capped.

Not active. Until the prober, the pooled sample, the headroom budget and the adversarial capacity simulations exist, `κ ≡ 1` and no externally operated miner receives weight on any non-local network. The current code fixes capacity at 1.

## Operator groups and caps

- Groups. GDPR tier: the admitted `operator_id`. Permissionless: the owning coldkey, merged only by proven linkage (same coldkey, same serving key, or a live challenge proving the same TLS key or origin). Correlations such as latency or duplicate payloads are monitoring signals only. Unknown off-chain identity is never by itself a reason for zero weight.

- Group reward. With capacity proven, a group's reward is the sum of its members' applied gains; while `κ ≡ 1`, it is the maximum member gain, so adding hotkeys adds nothing.

- Water-filling. Shares `s_k = min(cap, λ*·G_k)` with λ* chosen so the shares sum to 1 and `cap = per_operator_cap = 0.40` (provisional). Within a group, share is split in proportion to applied gain.

- Abstain. With fewer than ⌈1/cap⌉ groups of positive reward, the validator abstains rather than concentrating weight.

- Linked groups. A newly proven link can never raise a member above what it would have received unlinked in the same epoch.

Any cap can be evaded by operators who split across unlinkable coldkeys. The spec states this residual openly rather than claiming Sybil resistance.

## Fiat and emission separation

- The score ledger reads only validator evidence. It never reads prices, invoices, contract terms or settlements.

- Billing and settlement never read emissions, weights or balances.

- The customer router never reads the score, gain or weights. It picks among eligible miners using health, capacity, contract terms and a share cap.

- On chain there are only registration and weights: no customer identifiers, payloads, answers, labels or invoices.

## What is still provisional

- All tolerances (`τ_id`, `τ_item`, `ε`) until the honest-noise measurement per hardware configuration (M1) exists.

- Reference latency, throughput and burst deadlines until M2; gateway burst headroom until M3; substitute-panel statistics until M4.

- Window sizes, error budgets, reuse limits, dispute budgets and the ramp until the S1–S4 simulations pass.

- Capacity activation and the split-neutrality target, which is explicitly not established.

- Exclusion after repeated failures, which stays disabled until the conditional-independence assumption has evidence.

- Multi-family scoring: any policy with two or more families abstains.

- Leaf-position privacy of the gateway's joint Merkle root, which has not been demonstrated.

---

URL: https://reax.dev/roadmap/

Project

# Roadmap

REAX moves through explicit gates. Each stage opens only when the previous gate's evidence exists, and nothing on this page is a date commitment.

All gates closed

As of 3 October 2026 every rollout gate from G0 (spec freeze) to G6 (mainnet) is closed. The project is between the design stage and a complete local harness.

Release 1.1.0rc1 supersedes this page as the current mechanism

Release 1.1.0rc1 (3 October 2026) is built and tested on a local chain; it is not on testnet or mainnet. Details: Inference mining (1.1) (https://reax.dev/mining/).

## Stages

### Inference mining on the exact System1 models Built, local-chain tested

Release 1.1.0rc1, pre-release: miners serve s1-fast (Plumb-4B) or s1-pro (Surogate Rune 26B-A4B v3) in pinned production runtimes and validators recompute their answers. The s1-pro pool is switched off at first. See Inference mining (1.1) (https://reax.dev/mining/) and Verification & calibration (https://reax.dev/verification/).

### Design Revision 0.6, provisional

Specification of protocol, tiers, scoring and chain adapter. Freeze (G0) needs two independent critical reviews of the exact text with no open high or critical finding, the S1–S4 simulations passing, and the reference performance measurements M1 and M2.

### Local harness Loopback runs G1 closed

Today: three simulated miners, one validator, synthetic traffic, signed HTTP, no chain. G1 additionally requires a disposable local Subtensor, at least three synthetic miners across both tiers, every acceptance vector passing, canonical JSON, and measured reference latency and gateway headroom.

-
### Testnet G3 closed

Official test network, test TAO only, ephemeral keys, chain profile from readback. Weights only for REAX-owned hotkeys until capacity measurement is active. Preceded by adversarial simulation (G2). See the testnet guide (https://reax.dev/testnet/).

-
### System1 staging G4 closed

Synthetic staging traffic through the System1 preview contract, with the System1 owner's consent.

-
### Real traffic G5 closed

Requires a signed acceptance record from the System1 owner, legal review, DPA and subprocessor workflow, and the organic identity shadow enabled. This decision sits outside REAX's authority.

-
### Mainnet G6 closed

Requires active capacity measurement, passed capacity simulations, a current cost readback, a named coldkey, resolved ownership questions and explicit approval. No mainnet registration happens without that approval.

-
### Decentralized global tier Intended · G5 gates

Intended: permissionless miners may later serve accepted global traffic for System1 Models, only once the G5 acceptance gates pass: signed System1 acceptance, legal review, sampled re-execution (the organic identity shadow) on, and capacity measurement live. Until then the permissionless route carries synthetic traffic only.

-
### Finetuning service & miner competition Planned · new spec version

Planned: a finetuning service that produces custom fine-tuned decision models, with miners competing to produce better fine-tuned models. The first competition track is designed and switched off until it is proven robust: 20 % of miner emission to the number one of a public competition, with automatic code review and sandboxed runs. See Competition mining (planned) (https://reax.dev/competition/). The finetuning service itself is not yet specified.

-
### Peer-to-Peer tier routing Design only · opt-in

Design only: capacity outside data centres, opt-in only, never EU traffic. It needs a System1 gateway change (capacity class, consent flag, shadow verification, failover) and the owner's go, and is never enabled without them.

## Near-term engineering

Work named in spec 0.6 before the local harness gate can close:

- Protocol v2 bodies: grant-bound data class, signed caller registry, allow-list projection, manifest-bound miner responses.

- Admission snapshot v3, the cumulative revocation feed, trust root and checkpoint.

- Gateway: weighted-random routing without score input, claim state machine, Ed25519 receipts, burst controller and joint dispatch Merkle root.

- Validator: fixed alpha split, catalog tool with power admission, per-configuration tolerances, verified capacity, linked-group clamp.

- Capacity prober, identity generators, labelled pool, reference processor and simulator.

- Chain adapter checks on a local Subtensor at a pinned commit; isolated image decoding in the serving image.

---

URL: https://reax.dev/changelog/

Project

# Changelog and status

Design specification revisions and updates to these docs. Last updated 2026-10-03.

Current

Specification revision 0.6 (provisional, not frozen). Runtime code implements the provisional 0.3 baseline; nothing in the code implements 0.6 yet. All rollout gates G0–G6 closed. No REAX subnet on testnet or mainnet.

Release 1.1.0rc1 supersedes this page as the current mechanism

Release 1.1.0rc1 (3 October 2026) is a pre-release. It replaces the mechanism described in the spec 0.6 pages (Scoring & incentives (https://reax.dev/incentives/)) with miners serving the exact System1 models, validated by recomputation. It was tested on a local chain with the real production runtimes and calibrated on three GPU types. It has not been run on testnet or mainnet.

## Specification revisions

| Revision | Status |

| 0.8 | In review, provisional Newer working revision under independent review. These docs have not yet been updated to it |

| 0.7 | Superseded by 0.8 |

| 0.6 | Basis of these docs Self-contained merged text. Not frozen and not a freeze candidate |

| 0.5 | Superseded by 0.6 |

| 0.4 | Superseded |

| 0.3 | Superseded; provisional runtime baseline of the reference code |

| 0.2 | Superseded |

| 0.1 | Superseded (draft) |

Score-affecting changes need two independent critics and two consecutive review rounds without a high or critical finding. A revision could be frozen only after two independent critical reviews of its exact text find no open high or critical issue and the S1–S4 simulations and acceptance gates pass.

## Documentation updates

| Date | Change |

| 2026-10-03 | Added the release 1.1.0rc1 pages: Inference mining (1.1) (https://reax.dev/mining/), Verification & calibration (https://reax.dev/verification/) and Competition mining (planned) (https://reax.dev/competition/); marked the spec 0.6 scoring page as the earlier design; updated the roadmap. Pre-release; competition mining is planned and switched off. |

| 2026-09-30 | First publication of the developer docs at reax.dev: overview, local quickstart, miner, validator and testnet guides, protocol and incentive references, roadmap. Based on spec revision 0.6 and the private reference code as of this date. |

## Status elsewhere

- reax.co/status (https://reax.co/status/): dated project status (not live telemetry).

- Roadmap (https://reax.dev/roadmap/): gates and stages.