The iteration loop
Assuming you have a subnet registered on testnet and a validator submitting weights, the development cycle is four steps — and the third is the one people skip.
How this works on-chain: local development setupRunning a local subtensor node, the testnet endpoints, wallet and hotkey creation, and the btcli commands to register a subnet and its neurons.subtensor.com/learn/guides/local-development- Deploy test miners with known characteristicsRegister several miner hotkeys and run them at deliberately different performance levels: one returning high-quality output, one mediocre, one returning garbage or actively trying to game your scoring function. Then check the only thing that matters at this stage — that your validator ranks them in the order you already know is correct.
- Iterate on your scoring functionRead the weight vectors your validator produces each epoch. Where they disagree with your own judgement of the miners, find out why and fix the logic. Observe, find the mismatch, change the function, observe again: this loop is the actual work of building a subnet, and it is worth going round it many more times than feels necessary.
- Stress test with adversarial minersWrite miners that attack your function rather than perform the task: returning cached responses, copying other miners, spoofing metrics, probing your query generation for predictable patterns. If any of them score as well as an honest miner, you have found a hole that will be found again on mainnet, by someone who will not tell you.
- Run for at least 48 hours continuouslySustained operation surfaces what short tests never do: memory leaks in the validator process, scoring edge cases triggered by rare miner behaviour, epoch timing under realistic load. Do not go to mainnet until the subnet has run two days without manual intervention.
Debugging tips
The most common failure is weight submissions not landing on-chain. Check, in order, that the validator hotkey holds enough TAO for fees, that it is registered as a validator rather than a miner on your subnet, and that it meets the minimum stake for weight-setting. Confirm with btcli subnets metagraph after each epoch.
For scoring problems, instrument heavily. Log every score with the raw inputs that produced it — the query, the response, the intermediate metric values. That log is what tells you whether the function is behaving as intended, and it is the only way to catch a regression you introduced three commits ago.
Watch for drift. If your scoring carries state — moving averages, historical comparisons — verify it behaves correctly after a process restart. A validator that scores differently once restarted produces weight changes that are extremely hard to diagnose in production.
When you’re ready
Four conditions, all of them: the subnet has run 48 hours without intervention; the scoring function orders miners correctly under adversarial conditions; the miner and validator templates are documented well enough that a stranger could run them; and you have a plan for bootstrapping participation.
Do not rush this. Testnet mistakes are free. Mainnet mistakes cost real TAO and land at the moment your subnet’s reputation is being formed.