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.

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:

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.

Identity stream and labelled pool

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.

1. Commit. Publish c_e; wait for drand round r_e; derive the schedule seed.
2. 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.
3. Dispatch. Inject via the gateway; collect gateway-signed dispatch records.
4. Pair. Match each observation with its reference output on the exact payload bytes.
5. Window tests. At window close, run the identity, quality and burst-audit tests (and the organic verdict, when enabled). Apply the two-strike rule.
6. 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.
7. Submit. Run the fail-closed chain checks, commit the weight vector, and verify the applied weights after the automatic reveal.
8. 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:

F_i

1 unless the miner is fidelity_failed in a family it serves (two consecutive failing windows).

A_i

Availability: miner-attributable successes over miner-attributable scheduled attempts; eligibility needs A ≥ 0.50 (provisional).

L_i

Latency credit in [0, 1], capped so that anything within (1 + η) of the reference earns full credit.

κ_i

Verified 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.

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.