Loading...
Loading
Overview
Registration Activity
Neuron registration trends
This Interval
0
— burn · — PoW
Target / Interval
Loading
Neuron registration trends
Training language models at frontier difficulty is computationally expensive because systems that generate completions and then filter based on reward variance waste GPU compute on low-signal groups. Centralized approaches either discard unprofitable generations or require a single oracle to judge which prompts matter. Reliquary restructures this as a market: independent miners use their own GPU compute to predict which prompts sit at the current policy's learning frontier and generate completions only on those prompts. Validator nodes continuously verify those completions using cryptographic GRAIL sketches (commitments over model activations), apply a statistical filter to admit only high-variance groups, and select winners via FIFO—eliminating post-hoc rejection and aligning miner incentives with training utility.
On Bittensor subnet 81, miners compete to contribute verified rollout groups. Each miner polls the validator for the current checkpoint and one-shot prompt cooldown, selects a non-cooldown prompt from the active environment (math, code, or logic reasoning), generates exactly 16 forced-seed rollouts using validator-reproducible randomness, and submits a signed batch with cryptographic proof commitments. The validator's worker runs bounded admission checks, queues eligible groups for continuous proof dispatch, and selects proven groups in FIFO order until the window fills. Selected groups accumulate in a training journal; when enough groups collect, the trainer runs one GRPO step and publishes a new checkpoint. Per-miner emission is proportional to their EMA score of selected groups per window, updated once per epoch on-chain.
Use cases were auto-generated from the GitHub repository and may not reflect the latest changes.
Reliquary is a decentralized GRPO training protocol on Bittensor subnet 81 where independent miners compete to contribute verified rollout groups at the policy's learning frontier. Miners generate language model completions, construct cryptographic GRAIL proofs, and submit them to a validator that continuously proves groups, applies a zone filter (σ ≥ 0.24 reward variance), ranks by verified difficulty and throughput, selects via FIFO until the window fills, and trains the current checkpoint on selected groups while publishing to Hugging Face. The system combines ex-ante miner prediction of frontier prompts with validator-authoritative reward computation and cryptographic verification to optimize the compute-per-gradient efficiency of DAPO training at scale.
Reliquary operates a continuous streaming loop: (1) Miners poll /state to read the active checkpoint revision, window number, and one-shot cooldown set. (2) Miners select a non-cooldown prompt from the active environment (OpenMath, OpenCode, or Logic) and generate exactly 16 forced-seed rollouts with validator-reproducible randomness. (3) For OpenMath, miners compute and submit local reward claims; for OpenCode and Logic, they generate completions and the validator computes authoritative rewards. (4) Miners construct GRAIL sketches (linear commitments over hidden-state samples) and commit the signed batch metadata via /submit/precommit, then upload the exact body bytes to /submit before the 33-second reveal grace expires. (5) The validator's worker runs bounded admission (schema, identity, prompt, reward, zone filter checks), gates by provisional ACCEPTED, and queues eligible groups for continuous proof dispatch. (6) Proof workers grind through FIFO groups, verifying GRAIL sketches and exact termination against the validator's own forward pass. (7) Groups that pass proof enter the pick queue; once the window collects enough proven groups (16 picks × 16 groups per environment by default), the window seals. Unprovable or late groups that miss the pick target burn unpaid. (8) Sealed selection yields final rewards and canonical ranks. (9) Selected groups (optionally quarantined for model health) accumulate in a training journal until the configured CHECKPOINT_PUBLISH_INTERVAL_WINDOWS boundary is reached, at which point the trainer runs one GRPO step and publishes a new checkpoint to HF Hub and R2. (10) The validator updates per-hotkey EMA scores and once per epoch calls set_weights on-chain with the smoothed emission. The entire loop is drand-derived randomness, FIFO-based, and cryptographically verified, eliminating post-hoc filtering and aligning miner incentives with frontier selection.
This information was auto-extracted from the GitHub repository and may be incomplete or out of date. Always refer to the subnet's GitHub repository for the latest instructions.
The zone filter (σ ≥ 0.24 reward variance, σ ≥ 0.22 during bootstrap) ensures only frontier prompts are trained. Groups with zero variance (all same reward) are rejected before GRAIL proof. FIFO proof dispatch and continuous selection (not deferred auction) mean earlier valid arrivals have a residual advantage until the window fills on a configured pick target (16 picks × 16 groups/pick × environment_count by default = 256+ groups per environment).
Each selected group earns window_pool / (environment_count × picks_target × B_BATCH) regardless of completion length, payload size, or reward magnitude. Unused slots burn; there is no redistribution or runner-up split. One-shot cooldown (BATCH_PROMPT_COOLDOWN_WINDOWS = 1_000_000) locks a winning prompt_idx for the entire run, and canonical-content SHA256 identity blocks dataset-alias bypasses.
Hotkeys have no winner cap and can win multiple distinct prompts per window. EMA smooths single-window variance: a miner that stops contributing loses half its score in ~25 windows. Training quarantine (archive but no GRPO) protects model health during exploit discovery, credited but unpaid.
The sections above were auto-generated from the GitHub repository and may not reflect the latest changes. View repository
The RL layer of Bittensor
0
FAQs were auto-generated from the GitHub repository and may not reflect the latest changes.
Two GPUs recommended (generation + proof on separate devices); one larger device also works. Must match validator's pinned inference stack: Torch 2.7.0+cu128, Transformers 5.9.0, flash-linear-attention 0.5.0, no causal-conv1d. CUDA 12.x with flash-attn-compatible drivers required. No R2/S3 credentials needed.
Proof capacity depends on p95 group-proof latencies. Minimum homogeneous H100 count formula: ceil(18 * (M_p95 + C_p95) / (240 * 0.8)). Plan 8-10 H100s for Qwen3-4B long-context workload. Validator owns proof scheduling, GRAIL verification, training, checkpoint publication, and R2 archiving. Detached trainer can run on separate box with GPU + HF/R2 access.
Clone the Reliquary repository
git clone https://github.com/reliquadotai/reliquary.git && cd reliquary
Create and activate Python 3.11+ virtual environment
python3.11 -m venv .venv && source .venv/bin/activate
Install Reliquary in development mode
pip install --upgrade pip && pip install -e .
Install pinned PyTorch, Transformers, and flash-attention versions matching validator stack
pip install torch==2.7.0 --index-url https://download.pytorch.org/whl/cu128 transformers==5.9.0 flash-attn==0.5.0
Create Bittensor wallet and register hotkey
btcli wallet new-coldkey --wallet.name my_miner && btcli wallet new-hotkey --wallet.name my_miner --wallet.hotkey default
Register hotkey on subnet 81 (finney testnet)
btcli subnet register --wallet.name my_miner --wallet.hotkey default --netuid 81
Set environment variables for current protocol profile and fill-closed window mode
export RELIQUARY_PROTOCOL_PROFILE=qwen3-4b-base-dapo-reliquary-v1 && export RELIQUARY_EXPERIMENTAL_FILL_CLOSED_ENABLED=1
Launch miner (validator-url required during subnet launch phase; auto-discovered after owner validator gains validator_permit)
reliquary mine --network finney --netuid 81 --wallet-name my_miner --hotkey default --checkpoint Qwen/Qwen3-4B-Base --environments openmathinstruct,opencodeinstruct --validator-url http://<validator-ip>:8888 --log-level INFO
Clone the Reliquary repository
git clone https://github.com/reliquadotai/reliquary.git && cd reliquary
Create and activate Python 3.12+ virtual environment
python3.12 -m venv .venv && source .venv/bin/activate
Install Reliquary with validator dependencies
pip install --upgrade pip && pip install -e .[validator]
Install pinned PyTorch, Transformers, and flash-attention stack
pip install torch==2.7.0 --index-url https://download.pytorch.org/whl/cu128 transformers==5.9.0 flash-attn==0.5.0
Set protocol profile and base checkpoint environment variables
export RELIQUARY_PROTOCOL_PROFILE=qwen3-4b-base-dapo-reliquary-v1 && export RELIQUARY_CHECKPOINT=Qwen/Qwen3-4B-Base
Configure proof GPU devices and capacity manifest (must be qualified for exact fleet)
export RELIQUARY_PROOF_DEVICES='cuda:0,cuda:1,...' && export RELIQUARY_PROOF_CAPACITY_MANIFEST=/path/to/proof-capacity.json
Configure HuggingFace Hub and Cloudflare R2 credentials for checkpoint publishing and archive storage
export RELIQUARY_HF_REPO_ID=<your-repo> && export HF_TOKEN=<token> && export R2_ACCOUNT_ID=<id> && export R2_ACCESS_KEY_ID=<key> && export R2_SECRET_ACCESS_KEY=<secret>
Launch validator (in-process training by default)
reliquary validate --network finney --netuid 81 --wallet-name my_validator --hotkey default
Enable detached trainer mode (optional; writes payloads to R2 and skips in-process training)(optional)
export RELIQUARY_WRITE_TRAINING_PAYLOADS=1 && export RELIQUARY_DETACHED_TRAINER=1
Launch detached H100 trainer worker on separate box (if using detached mode)(optional)
reliquary train-worker --validator-url http://localhost:8000
Holder & total-staked metrics as of 3h ago (hourly snapshot)
