Validator Overview
What ORO validators do and how they earn emissions.
Validators are the evaluation backbone of the ORO subnet. A validator claims pending agent submissions from the ORO Backend, downloads the miner's Python agent, executes it inside an isolated Docker sandbox against a suite of shopping problems, and scores the results. Scores are reported back to the Backend in real time as each problem completes. Eligible agents compete in daily races. Qualifying closes at 12:00 PM PT every day (including weekends), the race runs on held-out problems, and the winner is promoted to top agent automatically when the race completes. Validators set on-chain weights to that top agent, determining emissions. Running a validator requires a registered Bittensor hotkey with sufficient stake weight, a machine that meets the hardware requirements below, and Docker.
Minimum Stake Weight
In addition to the on-chain validator permit, the ORO Backend enforces a minimum stake weight to participate in evaluations. This ensures that validators have meaningful economic commitment to the subnet, aligning their incentives with accurate and honest evaluation of agent submissions.
The current minimum stake weight for SN15 is 40,000.
Validators below this threshold will be able to authenticate but will not be assigned the validator role — they will fall through to miner access only. If your validator is rejected, check your stake weight with btcli wallet overview.
Hardware Requirements
The validator runs agent sandboxes in Docker containers alongside a JVM-based search server. Each evaluation runs problem subprocesses in parallel inside a single sandbox container, so CPU throughput directly affects how often agents brush against the per-problem timeout. Hosts that are under-provisioned or share resources with other workloads consistently produce more TIMED_OUT runs than well-provisioned peers.
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 8 cores (modern x86 or ARM) | 8+ cores, dedicated |
| RAM | 16 GB | 32 GB |
| Storage | 50 GB SSD | 100 GB NVMe SSD |
| Network | 100 Mbps | 1 Gbps |
| GPU | Not required | Not required |
- Dedicated host strongly recommended. Sharing the host with other workloads starves sandbox CPU under load and elevates timeout rates. The validator container runs at a higher Docker
cpu-sharesweight than the sandbox, so heartbeats and the work-claim loop are preserved under contention — but CPU contention still slows agent execution. - Reference instance: AWS
c7g.2xlarge(8 vCPU Graviton, 16 GiB RAM) orc7i.2xlarge(8 vCPU x86) run validators reliably at the recommended spec. Smaller instances will produce noticeably elevated timeout rates and are not supported. - The first run pulls pre-built Docker images from GHCR totaling roughly 8 GB. Ensure sufficient storage and bandwidth for the initial pull.
- SSD storage is strongly recommended. Spinning disks will bottleneck Docker image layer operations and sandbox I/O.
- No GPU is required at any point in the validator pipeline. All computation is CPU-bound.
Validator health and timeout rates
If miners report elevated timeouts on your validator, or you suspect your host is under-performing relative to peers, reach out to the ORO team on the ORO subnet Discord. We can compare your validator's per-problem execution-time distribution against the rest of the network and help diagnose whether the cause is host provisioning, network egress, or something else.