Subnet 127: Astrid
Astrid is Bittensor Subnet 127. The SN-127 overview source describes a validator system that blends vault weight targets with arena competition results before submitting weights on chain.
What Astrid Provides
The Astrid overview describes Subnet 127 as a validator system that blends weight targets from two sources: a vault allocation and an arena allocation. The validator fetches vault targets, checks arena competition data, resolves eligible participants to Bittensor UIDs, and submits blended weights on chain.
At the subnet level, Astrid connects validator weight-setting to capital-allocation and trading competition signals. Arena participants run trading agents in miner competitions, while validators use public competition data to rank eligible miners before publishing weights through Yuma Consensus.
Miner and Validator Roles
Miners participate through Astrid Arena competitions. The ranking documentation describes miner eligibility as requiring at least one trade and recent execution runs that correspond to recent trades. Eligible miners are ranked by competition performance, with only the highest-ranked eligible miners receiving arena weight.
Validators operate the SN-127 validator daemon. The repository describes validators as fetching vault targets, reading arena competition state, applying eligibility and ranking rules, resolving miner identities to UIDs, and submitting the resulting weights to Bittensor.
Allocation Context
Astrid’s distinctive subnet context is that validator weights can come from two different allocation sources. The overview document describes vault targets as one source and arena miner competition results as another, with the validator blending the two before weight submission.
That makes Subnet 127 different from a single leaderboard subnet. Vault allocation can represent a configured target, while arena allocation depends on live competition data. When no active arena competition exists, or when no miners are eligible, the overview says the arena allocation is ignored and vault-only weights apply.
The overview also describes the arena share as coming from the burn allocation. In practical terms, an active and eligible arena competition can redirect part of what would otherwise remain assigned to UID 0 toward ranked arena miners.
Arena Eligibility Context
The SN-127 ranking algorithm describes the arena side as an eligibility-and-ranking process. A miner must be registered in the active competition, must have at least one trade, and must have recent execution runs correlated with recent trades before receiving arena weight.
After eligibility, the ranking document sorts eligible miners by current PnL percentage and limits arena emissions to the highest-ranked eligible miners. This keeps the arena signal tied to both trading performance and evidence that the agent was actively running around recent trades.
The useful distinction is that Astrid does not treat all arena participants as equal once a competition exists. Competition participation, trade activity, execution evidence, and PnL ranking all shape which miners can receive the arena portion of the blended weights.
On-Chain Identity
Live SN127 subnet data is available on TaoStats. The source-backed allocation and arena-ranking details in this article come from SN-127 overview and ranking materials rather than from live identity fields.
Relationship to Yuma Consensus
Subnet 127 uses Yuma Consensus to convert validator-submitted weight vectors into miner and validator emission shares within the subnet. In Astrid’s context, those validator weights come from a blended allocation path: vault targets, arena eligibility, recent execution evidence, and PnL-ranked competition results shape the weights that validators submit on chain.
The Emission documentation describes how subnet emission is distributed from consensus weights each tempo. For Astrid, that means the public ranking and allocation process informs the weight vector, while Yuma Consensus and the emission mechanism determine how those weights become participant rewards.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Astrid (SN127), that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Astrid (SN127) is registered as the live production subnet at netuid 127. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Netuid 127 Identifies the Subnet On-Chain
Bittensor assigns every subnet a unique numeric identifier called a netuid, and Subnet 127 is the subnet registered at netuid 127 (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 Astrid from every other subnet.
For a reader, this means “Subnet 127” and “netuid 127” refer to the same on-chain slot. A claim about Astrid 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 127 Astrid should not be read as generic Bittensor subnet documentation, financial or trading advice, or a guarantee of any trading agent’s performance. It names one validator-coordinated subnet where weights combine vault targets with arena competition results from trading agents on netuid 127 (Understanding Subnets, Glossary: Netuid).