Incentive mechanism design: the core problem
This lesson is about the one decision every contest owner actually makes, underneath all the settings and dashboards: what, exactly, gets rewarded.
A subnet owner's real job is deciding two things: what a miner must produce, and how a validator scores it. Everything about registering the contest, tuning its settings, and publishing who runs it is handled through the chain itself — but the scoring logic, the actual definition of "good work" for this one contest, is code the owner writes and runs off-chain, outside the chain's view entirely. [source]
That split matters because of what the chain can and can't check. It can watch whether judges agree with each other, weigh that agreement by how much money backs each opinion, and pay out accordingly — it has no way to tell whether the scoring code producing those opinions is measuring anything real in the first place. A contest can reach smooth, tidy agreement around a badly designed test and get paid out exactly as cleanly as one testing something that actually matters. [source] [source]
What an owner can change after launch, day to day, is a set of dials — not the scoring code itself. Before an upgrade to that code, an owner can pause new registrations so nobody gets evicted mid-transition; day to day, the wiser move is running a validator from the same key that receives the owner's cut, so both incomes land in one place and can be staked together. [source] [source]
The chain does build in a couple of guardrails against the most obvious abuse. Emission a miner's key would earn is simply burned or recycled, never paid, if that key belongs to the subnet owner — there's no reward for mining your own contest. Judging your own contest is a different story: every validator's opinion of its own key is thrown out before consensus runs, except that owner's — its self-judgment is the one opinion the rule doesn't touch. [source] [source]
Enforcement doesn't have to happen on-chain, either. On contests that require miners to lock collateral, the rule lives entirely in the validator's own code: it reads how much is locked and simply stops scoring anyone who falls short or misbehaves. There's no on-chain penalty for this — just a starved-out zero score, with the stranded collateral left sitting where it is. [source]
How it actually works
Owner-settable parameters go through one dispatch call, and each individual one can only be changed roughly once every two tempos, tracked independently — several different settings can move within one tempo, just never the same one twice. Admin calls are also rejected during the last stretch of blocks before each tempo ends, so nothing can shift mid-calculation. [source]
Not everything is the owner's to touch. Kappa — the median-clip threshold from the consensus mechanics — the cap on how many validators can hold a permit, how often weights can be resubmitted, and a subnet's tempo outside its normal bounds are all root-only settings, reachable only through a privileged escape hatch. An owner can shape what gets measured; the arithmetic that turns measurements into a ranking is not theirs to move. [source]
One incentive is built into every subnet regardless of what the owner scores: dividends flow through bonds, an exponential moving average of a validator's weight times stake toward each miner, paid out as bonds times that miner's incentive. It is a design that rewards recognizing a good miner before the rest of the network catches up — and a later lesson covers the exploit this specifically exists to blunt. [source]