Launching on Mainnet

Registration

Registering a subnet on mainnet requires locking and burning TAO. The registration cost is dynamic and set by the protocol based on current subnet demand — it rises when many subnets are registering and falls during quiet periods. This cost is permanent and non-refundable; it is the protocol’s mechanism for filtering out low-commitment subnet proposals.

The registration grants you a netuid (a unique identifier for your subnet) and the owner role, which includes the ability to set hyperparameters for your subnet and receive the owner’s cut of emissions. It does not guarantee a specific amount of network emissions — how much your subnet earns depends on how much TAO is staked into it relative to other subnets.

Launch Process

Follow these steps to go from registered subnet to first emissions:

Documentation & Community

The quality of your documentation is the primary determinant of how many miners and validators will attempt to join your subnet. Miners evaluate potential subnets based on how clearly they can understand the requirements, how confident they are in their hardware meeting the specs, and how transparent the scoring criteria are. Vague or incomplete documentation is a signal of a poorly organized subnet and drives away exactly the high-quality operators you want.

At minimum, your documentation should cover: exact hardware requirements with benchmark numbers, step-by-step setup instructions from a fresh machine, a complete description of how miners are scored (with examples where possible), a FAQ covering the most common setup questions, and a clear channel for getting help (Discord, GitHub issues, or Telegram).

Building community before launch is a significant advantage. Subnets that announce their intention months before registration, share progress updates, and engage with potential participants during testnet typically launch with a ready pool of miners and validators. A cold launch — registering on mainnet with no prior community engagement — often results in a slow bootstrap that leaves your subnet earning minimal emissions for months.

First Emissions

Your subnet will begin earning emissions once it has active miners and validators submitting weights. The first epoch is the highest-risk period: scoring bugs, misconfigured validators, and miners who did not read the documentation all tend to surface immediately. Watch your validator logs closely and monitor the on-chain weight submissions and metagraph state in real time.

Do not expect the first emission distribution to be perfect. Early subnets typically have noisy scoring as miners calibrate their setups and validators converge on a consistent evaluation. The important signal to look for is directional correctness: miners you believe to be performing well should be earning more than miners you believe to be performing poorly. If the ranking is inverted or random, there is likely a bug in your scoring function that needs immediate attention.

Keep a fast feedback loop with your early miners during the first week. They will encounter setup issues, discover scoring edge cases, and ask questions that reveal gaps in your documentation. Responding quickly and transparently builds the trust that turns early adopters into long-term participants and advocates.

After Launch

Growth comes from three levers: documentation quality, visible earning opportunity, and reputation. Miners are economic actors choosing between subnets, so publish benchmarks — what top performers earn on what hardware — and cut the time from interested to first emission. Every hour a new miner spends debugging setup is an hour they might spend joining someone else instead. Attract independent validators the same way: a validator template good enough to run without your help makes consensus more robust and your subnet more trustworthy to mine.

Emission share follows stake, and stake follows belief, so competing for it means giving stakers something to believe with. A public leaderboard, quality metrics over time, and regular updates let capital price you accurately; opacity is a real disadvantage against subnets that report honestly.

You can change your subnet’s hyperparameters without a vote, which is operational freedom and a trust liability in the same sentence. Announce changes in advance, explain them, and give people time to adapt. Then treat the mechanism as a living system: scoring functions that are not maintained get gamed, templates that are not updated fall behind, and protocol migrations that are not adopted quietly accumulate into a disqualifying amount of debt. Owners who track network-level governance early get to influence the changes that reprice their subnet rather than react to them.