Subnet 124: Swarm
Swarm is Bittensor Subnet 124, an open benchmark for autonomous drone navigation. Miners train a neural network that flies a simulated drone to a landing platform through 3D environments it has never seen, using only a depth camera and the drone’s flight state. The network rewards the flight policies that succeed most reliably and quickly. The incentive-mechanism code is maintained in the swarm-subnet/swarm repository.
What the Subnet Produces
The subnet’s output is drone flight-control policies, measured on a common benchmark. According to the repository, a model is given a 128×128 depth image and a state vector — position, velocity, and orientation — at 50 Hz, and it outputs velocity commands (direction, speed, and yaw). It has 60 seconds to reach a landing platform and touch down safely, with no waypoints, GPS, or obstacle coordinates: the model has to read the depth image and react.
Models are tested across procedurally generated worlds — cities, mountains, warehouses, forests, and open terrain — so success reflects general navigation skill rather than memorizing a fixed course. The stated aim is to give autonomous-drone research a standard, public way to compare flight policies.
Generalization Context
The Swarm repository frames SN124 as a benchmark for policies that fly through 3D worlds they have not seen before. For a reader, that is the core distinction: the subnet is not measuring whether a miner can replay one route, but whether a model can keep navigating when the layout, obstacle pattern, and landing approach change.
That makes generated-world coverage part of the evaluation itself, not background scenery.
The miner guide supports that reading by describing the model’s observations and actions. A submitted policy receives depth and state data, then emits direction, speed, and yaw controls during the simulated flight. Because the task omits waypoints, GPS, and obstacle coordinates, the useful output is a policy that can turn limited onboard information into safe control choices across many generated scenes.
References: Swarm repository, Swarm miner guide
Validator Evaluation Context
The validator guide describes validators evaluating miner models on procedurally generated maps such as cities, open terrain, mountains, villages, warehouses, and forests. That source context explains why consistency matters: a strong policy has to survive different spatial problems, not only a single favorable map.
The repository’s scoring description combines landing success, time, and obstacle clearance, with ranking by average performance across 1,000 seeds. Those pieces fit together as one evaluation target. A model needs to land, do so quickly, and avoid unsafe paths often enough that the result is repeatable across the benchmark’s generated worlds.
References: Swarm repository, Swarm validator guide
Miner and Validator Roles
Miners develop and submit the flight policy. A miner improves its standing by training a model that lands more often, faster, and with more clearance from obstacles across many unseen worlds.
Validators run the submitted models in simulation and score them. The repository describes a score that weights success (did the drone land), speed (how fast relative to the limit), and safety (minimum clearance), and ranks miners by their average score across 1,000 procedurally generated seeds so that consistency, not a lucky run, wins. New models must clear a screening gate before the full benchmark, and each validator generates its own seed set per epoch, with seeds rotating on a fixed weekly schedule and published for transparency. Those validator scores become the weights that feed into Yuma Consensus, which converts them into the incentive split across miners and validators.
On-Chain Identity
Live SN124 data, including metagraph state and alpha token pool information, is available on TaoStats. The live Finney identity for netuid 124 registers the subnet name as Swarm, and points to the swarm-subnet/swarm repository, which is the source of truth for the benchmark and scoring described above.
Relationship to Yuma Consensus
Subnet 124 uses Yuma Consensus to convert the flight-policy performance weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Swarm’s context, validators evaluate submitted drone flight-control policies across procedurally generated environments, rank miners by average landing success, speed, and obstacle clearance across 1,000 seeds, and translate those benchmark scores into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Swarm (SN124), that sequence changes how readers should interpret drone navigation benchmark examples and flight-policy scoring outcomes.
In localnet, Swarm-compatible miners and validators can be developed and tested in an isolated environment. Localnet flight-policy evaluation results and emission outcomes do not represent production subnet performance.
On testnet, Swarm-compatible model submission and simulation evaluation workflows can be exercised in a shared, non-production network. Testnet navigation scores and validator weights are separate from mainnet subnet state.
On mainnet, Swarm (SN124) is the live production subnet where miners submit drone flight-control policies and validators benchmark them across procedurally generated environments to determine real Bittensor emissions. The Swarm repository is the registered project repository for SN124 on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A flight-policy benchmark result or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Netuid 124 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 124 is the subnet registered at netuid 124 (Glossary: Netuid). The Understanding Subnets reference explains that each subnet runs its own incentive mechanism while sharing the same underlying Subtensor chain, so the netuid is the stable handle that distinguishes Swarm from every other subnet.
For a reader, this means “Subnet 124” and “netuid 124” refer to the same on-chain slot. A claim about Swarm should be tied to that netuid rather than to the registered name alone, because the name field can be changed on-chain while the netuid stays fixed.
Reader Boundary
Subnet 124 Swarm should not be read as generic Bittensor subnet documentation, a finished consumer media product, or a substitute for the subnet’s own primary sources. It names the on-chain subnet registered at netuid 124 under the identity “Swarm” (Understanding Subnets, Glossary: Netuid).