This guide explains how to run a Grail miner. Miners generate GRPO rollouts with GRAIL proofs for SAT problems, upload them to object storage, and participate in decentralized scoring via validators.
Grail miners:
- Connect to a Bittensor subnet and follow scoring windows.
- Derive per-window randomness from drand and the window’s block hash.
- Generate multiple GRPO rollouts per SAT problem using a HF model.
- Produce GRAIL proofs (Prover) binding tokens to the model and seed.
- Upload signed rollouts to object storage for validators to verify and score.
- Linux with NVIDIA A100 GPU and CUDA drivers installed
- Python (via
uv venv) and Git - Bittensor wallet (cold/hot) registered on the target subnet
- Cloudflare R2 (or S3-compatible) bucket and credentials
- Create a Bucket: Name it the same as your account ID and set the region to ENAM.
- Optional: WandB account for monitoring
Hardware requirements:
- NVIDIA A100 GPU is required for the current version
- The codebase has been optimized and tested on NVIDIA A100
- GPU-agnostic verification is coming soon, which will enable support for other hardware configurations
- Network bandwidth needs are modest; uploads are JSON rollouts
# Clone and enter
git clone https://github.com/one-covenant/grail
cd grail
# Create venv and install
uv venv && source .venv/bin/activate
# Recommended (reproducible, uses lockfile and installs extras)
uv sync
# Configure environment
cp .env.example .env
# Edit .env with your wallet names, network, and R2 credentials
# Run miner
grail mine
# Run miner in debug mode
grail -vv mineSet these in .env (see .env.example for full list and guidance):
- Network & subnet
BT_NETWORK(finney|test|custom)BT_CHAIN_ENDPOINT(whenBT_NETWORK=custom)NETUID(target subnet id)
- Wallets
BT_WALLET_COLD(coldkey name)BT_WALLET_HOT(hotkey name)
- Model & generation (read-only for miners in this release)
- Do not override
GRAIL_MODEL_NAMEorGRAIL_MAX_NEW_TOKENS. - Use
Qwen/Qwen3-4B-Instruct-2507as the network default model in the first version. - Set
GRAIL_MAX_NEW_TOKENS=1024(mandatory in first version). - Validators assume the network default model and generation cap; changes may cause rollouts to be rejected.
- You may adjust
GRAIL_ROLLOUTS_PER_PROBLEMfor throughput, but ensure you finish generation before the window upload buffer (last 2 blocks).
- Do not override
- Object storage (R2/S3)
R2_BUCKET_ID,R2_ACCOUNT_ID- Dual credentials (recommended):
- Read-only:
R2_READ_ACCESS_KEY_ID,R2_READ_SECRET_ACCESS_KEY - Write:
R2_WRITE_ACCESS_KEY_ID,R2_WRITE_SECRET_ACCESS_KEY
- Read-only:
- Monitoring
GRAIL_MONITORING_BACKEND(wandb|null)WANDB_API_KEY,WANDB_PROJECT,WANDB_ENTITY,WANDB_MODE
Create and fund a wallet, then register the hotkey on your subnet:
btcli wallet new_coldkey --wallet.name default
btcli wallet new_hotkey --wallet.name default --wallet.hotkey miner
btcli subnet register --wallet.name default --wallet.hotkey miner --netuid <NETUID> --subtensor.network <NETWORK>Set BT_WALLET_COLD and BT_WALLET_HOT to these names in .env.
Bucket requirement: Name it the same as your account ID; set the region to ENAM.
Grail uses a dual-credential design:
- Write credentials stay local and are used by miners to upload.
- Read credentials are committed on-chain so validators can fetch your data.
Fill R2_* variables in .env.example.
Set GRAIL_MONITORING_BACKEND=wandb and provide WANDB_API_KEY (or use null). Metrics include rollout counts, rewards, upload durations, and success rates.
Public dashboard: set WANDB_ENTITY=tplr and WANDB_PROJECT=grail to log to the public W&B project and monitor real-time scores and issues. View at https://wandb.ai/tplr/grail.
From an activated venv with .env configured:
grail mine # default; mix drand + block-hash for randomness
# grail mine --no-drand # fallback to block-hash onlyFlags are minimal; most behavior is configured via .env. Increase verbosity with -v or -vv.
High-level loop (see grail/cli/mine.py):
- Load R2 credentials and initialize
GrailChainManager; commit read credentials on-chain. - Connect to subtensor; compute
window_start = (current_block // WINDOW_LENGTH) * WINDOW_LENGTH. - For the window:
- Derive randomness:
sha256(block_hash + drand.randomness)(or block hash only). - Generate SAT problems (difficulty ramps) and create GRPO batches via
SATRolloutGenerator. - Use
Proverto commit/open GRAIL proofs and package signed rollouts.
- Derive randomness:
- Upload the window’s rollouts to R2/S3 with write credentials.
- Repeat on the next window.
Artifacts uploaded per rollout include:
- GRAIL commit (
tokens,s_vals, signature, beacon) - SAT problem metadata (seed, clauses, difficulty)
- GRPO data (reward, advantage, token logprobs, lengths, success)
- Miner signature over a challenge derived from seed/block/nonce
- CUDA OOM or driver errors: Ensure you're using an NVIDIA A100 GPU; verify drivers match CUDA runtime; periodically clear cache.
- GPU not detected: Currently requires NVIDIA A100. Check
nvidia-smioutput to verify GPU availability. - No uploads: check
R2_*variables and bucket permissions; verify network/firewall. - Not receiving weights: ensure uploads succeed; validator will score the previous complete window.
- Drand failures: miner automatically falls back to block-hash; you can use
--no-drand. - Wallet not found: ensure
BT_WALLET_COLD/BT_WALLET_HOTnames exist in your~/.bittensor/wallets.
- Use NVIDIA A100 GPU for optimal performance; this is currently required for proper GRAIL proof generation and verification.
- Keep model-related envs at network defaults; do not override
GRAIL_MODEL_NAMEorGRAIL_MAX_NEW_TOKENS. UseQwen/Qwen3-4B-Instruct-2507and setGRAIL_MAX_NEW_TOKENS=1024in the first version. - Reserve the final 2 blocks of each window for uploads; the miner does this automatically but avoid heavy generation near the end.
- Use
--use-drand(default) for robust challenge derivation; fall back with--no-drandonly if needed. - Ensure R2 dual-credential setup: write locally, read credentials are committed on-chain by the miner.
- Monitor GPU memory on your A100; the miner periodically empties cache, but size your rollouts to avoid OOM.
- Increase verbosity with
-vvwhen diagnosing sampling, group sizes, or upload issues. - Note: GPU-agnostic verification is under development and will expand hardware support in future releases.
For issues or questions: