REAX.docs Pre-release · not on testnet
MenuOverview

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 · 30 September 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.

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.

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.

REAX architecture System1 sends signed requests to the REAX gateway and router, which dispatches them to GDPR-tier or permissionless miners. Validators inject probes through the gateway, receive signed dispatch records, pair results with reference outputs, and submit weights to the Bittensor chain. EXTERNAL OWNER System1 API Customer ingress, tenant policy, legal notices, billing REAX CORE Gateway / router Authenticate callers · enforce tier, eligibility and capacity · project the payload · measure latency · write payload-free receipts GDPR-tier miners Admitted EU operators under contract and DPA Permissionless miners Any registered hotkey that passes conformance REAX CORE Validator Private schedules · identity and labelled probes · epoch scoring DESIGNED Reference processor Computes p_ref on byte-identical payloads NO SUBNET YET Bittensor chain Registration, permits, stake-weighted consensus signedrequest dispatch probes signed dispatch records paired p_ref commit-reveal weights REAX architecture (stacked layout) EXTERNAL OWNER System1 API Customer ingress, policy, billing signed request REAX CORE Gateway / router Authenticate · enforce tier and capacity · project payload · measure latency · receipts GDPR-tier Admitted EU operators Permissionless Registered hotkeys probes ↑ records ↓ REAX CORE Validator Private schedules · epoch scoring p_ref weights DESIGNED Reference processor NO SUBNET YET Bittensor chain
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 for the exact envelopes.

Roles

RoleResponsibilityTrust boundary
Miner (GDPR tier)Serves admitted EU requests under contract and DPASees plaintext while inferring; admitted through an off-chain process and a signed admission snapshot
Miner (permissionless)Serves authorized synthetic traffic onlyAssumed to be able to log, copy or retain payloads, so it never receives personal or GDPR-tier data
ValidatorPrivate schedules, labelled items, identity items, verification, epoch scoring, weight submissionReceives no customer content and no organic metadata; injects probes only through the gateway; must be independent of other validators
Gateway / routerAuthenticates callers; enforces tier, eligibility and capacity; projects payloads; dispatches; measures latency; records receiptsCustomer API keys and chain keys never reach miners; never reads the emission score
Reference processorComputes reference outputs p_ref on byte-identical payloadsNever 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, billingOwns the decision to send real traffic; REAX cannot override that gate
Subnet owner / trust rootChain hyperparameters, signed trust root, policy, catalog and chain profileOwner 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 tierPermissionless tier
Wire valuegdpr_euglobal_permissionless
Who can serveEU-established legal operators processing data in admitted EU countriesAny chain-registered hotkey that passes conformance
How you get inOff-chain KYB, contract and DPA, then a signed admission snapshot; chain registration is necessary but never sufficientChain registration plus a signed miner record and conformance
Traffic todayNone outside the local harnessSynthetic only, and only in the local harness
Real traffic requiresA 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

AreaStateDetail
Design specificationProvisionalDocs 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–G6All closedFrom spec freeze through mainnet; see the roadmap
Local harnessRuns locallyLoopback only: 3 simulated miners, 1 validator, synthetic traffic, mocked chain snapshot
TestnetNot registeredNo REAX subnet, no netuid; read-only chain checks exist
MainnetNot registeredRequires explicit approval of a stated cost and coldkey
Customer trafficNoneNo System1 acceptance record exists
ImagesDisabledDisabled at the network miner pending isolated decode validation
Capacity measurementNot builtCapacity is fixed at 1 in code; no weight to external miners on any non-local network until it exists
Organic identity shadowDesigned, offDisabled by default; mandatory before real traffic
Source codePrivatePre-release; access by request for prospective operators

Where to go next