Should you build one?
Launching a subnet gets you a market without having to build one. The protocol already handles registration, token distribution and consensus; you supply the task and the scoring logic, and miners worldwide self-select into competing on it. As owner you receive a fixed cut of your subnet’s emissions each epoch, and you benefit again from growing the subnet’s share of the network total — more stake draws more emission, which attracts better miners, which justifies more stake.
It is the wrong path for most people. Build one if you have a task whose output quality can be measured programmatically, the engineering depth to write validator scoring and a miner interface, and the resources to bootstrap participation before emissions make it self-sustaining. If what you want is to earn from the network rather than to run one, mining, validating or staking will serve you better — subnet ownership is high-leverage and unforgiving, and an incentive design mistake undermines everything downstream of it.
Defining “good”
Before writing a single line of scoring logic, you need a precise, operational definition of what good output means for your subnet’s task. This definition must be automatable — a human expert can assess quality, but your validator needs to do it programmatically, at scale, for every miner every epoch.
Start by collecting examples. What does an excellent response to your task look like? What does a mediocre one look like? What does a deliberately gamed response look like? Answering these questions concretely — with actual examples, not abstract descriptions — is the foundation of every scoring function worth building.
Good quality definitions share two properties: they are verifiable without knowing the “answer” in advance (so you can score responses in real time), and they correlate with actual usefulness for the task (so miners who score well are also delivering genuine value). Tasks where these two properties conflict are among the hardest to build subnets for.
Scoring functions
A scoring function takes a miner’s response and produces a number between 0 and 1. These scores become the weights your validator submits to the chain, which in turn determine each miner’s emission share. The design space for scoring functions is vast and deeply task-specific, but a few patterns recur across successful subnets.
Reference-based scoring evaluates responses against a known correct answer. This works when you can generate or curate ground truth: for factual QA, code correctness, data transformation, or any task with an objectively verifiable output. The challenge is constructing a diverse, non-gameable reference set — if miners can memorize or predict your references, the score stops measuring genuine capability.
Relative scoring ranks miners against each other rather than against an absolute standard. A validator submits the same query to multiple miners, compares the responses, and assigns higher scores to relatively better answers. This sidesteps the need for ground truth but introduces a different problem: if all miners are equally bad, the best of a bad bunch still earns a high score.
Multi-signal scoring combines several measures — quality, latency, consistency, format compliance — into a single score using a weighted aggregation. This is the most common design in practice. The tradeoffs between signals should reflect what actually matters for your use case: an inference subnet might weight latency heavily, while a research subnet might care almost exclusively about output quality.
Reward distribution
How you translate scores into weights shapes the competitive dynamics of your subnet. A linear mapping (score → weight proportionally) creates a relatively flat competitive landscape where incremental quality improvements earn proportionally more. A rank-weighted or winner-takes-more mapping concentrates emissions at the top, driving higher performance ceilings but potentially reducing the number of viable miners.
Consider the shape of the distribution carefully. If emissions are too concentrated, new miners cannot break in against established incumbents and the subnet stagnates. If they are too flat, there is insufficient pressure to improve and quality plateaus at a mediocre equilibrium. Most successful subnets use a curve that rewards top performers disproportionately while still leaving meaningful emissions for the next tier — keeping the competitive field alive.
The validator’s cut of emissions is set by the protocol, not by you — but you influence the attractiveness of validating on your subnet by providing good tooling, clear documentation, and a scoring mechanism that does not require prohibitive compute to run honestly.
Common pitfalls
The three most common failure modes in incentive mechanism design are gaming, sybil attacks, and reward hacking.
Gaming occurs when miners find a way to score well without doing the actual task. If your scoring function is simple and deterministic, miners will reverse- engineer it and optimize for the score rather than genuine quality. The defense is randomization (vary your queries and references so miners cannot predict exactly what they will be scored on) and holdout evaluation (keep a test set that miners have never seen).
Sybil attacks involve a single actor registering many identities to dilute competition or manipulate consensus. The protocol’s registration cost provides partial defense, but you can strengthen it by requiring validators to observe behavioral consistency over time — making it expensive to establish a new miner identity that scores as well as an established one.
Reward hacking is a subtler failure: miners satisfy the letter of your scoring function while violating its spirit. A language model subnet that scores on fluency might be gamed by fluent but factually incorrect responses. An image subnet that scores on perceptual similarity might be gamed by images that are perceptually similar to references but visually useless. The defense is ongoing red-teaming — actively trying to fool your own scoring function and patching the holes you find.