Bittensor’s Null Consensus lets a subnet support up to 2,500 registered UID slots with one emission mechanism, compared with a 256-slot Yuma budget in the inspected runtime. It also changes who decides how miners are rewarded: one elected validator supplies the scores used to divide their reward budget.
That combination is the update’s central trade-off. Removing collective scoring calculations allows a larger registry, while placing more responsibility on the elected evaluator. Other staked participants can still receive validator dividends without independently scoring miners under Null.
For subnet owners, the question is whether this simpler model suits the work they want to reward. For miners, it is how reliably that evaluator measures their contribution. A larger registry creates room for participation; the evaluation rules determine what participation earns.
What is Null Consensus?
Null is an optional algorithm for distributing rewards inside a subnet. It leaves the blockchain’s transaction validation, block production and finality unchanged. Subnet owners can select it; Yuma remains the default.
Under Null, the chain uses one elected validator’s list of relative miner scores, called a weight row, rather than combining several validators’ assessments. It skips Yuma’s collective scoring and bond calculations. Bonds track validator–miner relationships used to calculate validator dividends.
Our Bittensor introduction covers the network’s roles, and the glossary explains its terminology. The epoch-consensus reference documents the mode switch.
From 256 to 2,500 UIDs
The implementation’s capacity budget is 2,500 divided by the number of emission mechanisms, rounded down. These mechanisms are separate reward calculations within the same subnet population. One permits 2,500 slots; two permit 1,250. The inspected Yuma budget follows the same division, starting from 256.
A UID identifies a registered participant slot. One operator can control several registrations, so UID counts do not establish the number of independent miners, businesses or GPUs.
Owners must increase configured capacity within the allowed budget; enabling Null alone does not enlarge or fill the registry. Returning an oversized subnet to Yuma requires reducing its population, potentially deregistering participants. Separate settings limit the permitted mechanism count.
Yuma versus Null
Yuma combines permitted validators’ evaluations. Its consensus clipping limits scores to a level supported by sufficient stake, constraining a validator that scores a miner above that level. Null uses the elected scorer’s row without this collective correction.
| Feature | Yuma | Null |
|---|---|---|
| Miner evaluations | Multiple permitted validators can score. | One elected UID supplies scores. |
| Collective correction | Stake-supported consensus clipping. | No Yuma consensus clipping. |
| Validator dividends | Evaluation-linked bonds and miner incentives, with version-specific stake treatment. | Shares based on positive effective stake. |
| UID capacity budget | 256 divided by mechanism count in the inspected runtime. | 2,500 divided by mechanism count. |
| Optional PoW admission | Available independently. | Available independently. |
The inspected implementation handles dividends differently across Yuma versions. Earlier Yuma incorporates stake when forming bonds; Yuma 3 applies active stake explicitly to the bond-and-incentive result. Both retain evaluation-linked calculations, unlike Null’s direct stake proportions.
Yuma can distribute evaluation authority, although stake concentration still matters. Under Null, the distinction between scoring miners and receiving dividends is explicit.
A Simpler Way to Think About It
Imagine an engineering competition opening room for many more entries. Its new format stops combining a panel’s assessments and uses one lead judge’s scorecard to divide the prize budget. Different entries can still receive different amounts.
That simplifies the reward calculation, but every contestant now depends on the same scorer’s methods and reliability.
Under Null, the eligible validator with the highest effective stake supplies the miner reward weights. Subnet ownership alone does not grant that role. Other staked participants can still receive dividends without supplying miner scores. A larger entry list does not make the scorecard more reliable.
This analogy illustrates the trade-off between participation capacity and scoring authority, not the literal operation of a subnet.
How rewards work
The scorer is the eligible registered UID with the highest effective stake: the stake the protocol counts behind it after delegation relationships, combining subnet alpha and weighted root TAO exposure. This differs from a wallet’s spendable balance. Selection uses the unrounded value; equal-stake ties go to the lower UID.
The winner needs the largest individual share, not a majority. Subnet ownership does not automatically confer the scoring permit.
The reward implementation applies the relevant self-weight, registration-age and commit/reveal filters before dividing the miner budget by surviving weight ratios.
For example, a funded budget of 1,000 atomic reward units and weights of 6, 3 and 1 for three eligible destinations produce payments of 600, 300 and 100. This is illustrative arithmetic, not an observed payout or a TAO-denominated budget.
Payments use whole atomic units. Cumulative rounding preserves the funded total, but a very small positive weight can receive zero; fractional amounts do not carry forward.
Equal sharing applies only when no valid positive weights survive; that fallback covers all registered UIDs. Separately, validator dividends follow positive effective-stake proportions, including inactive UIDs and those without the scoring permit, before downstream settlement. These dividends are not additional miner scores.
Proof-of-Work registration
Owners can enable Proof-of-Work registration with either Yuma or Null. Entrants solve a computational challenge tied to the subnet, a recent block and their keys as an alternative to burn registration.
A direct, zero-tip PoW registration requires no TAO transaction fee, registration burn or upfront collateral purchase. A transaction submitted through an outer wrapper, such as a proxy or multisig, may still incur that wrapper’s fee. Hardware, electricity and unsuccessful work remain costs. Admission limits and full-subnet replacement rules still apply.
PoW establishes eligibility to register. It does not evaluate the miner’s service or determine its ongoing reward. Difficulty remains subject to protocol constraints, including a governance-controlled minimum.
Where the model could fit
Consider a hypothetical subnet rewarding results against transparent, reproducible tests. An elected evaluator could apply published accuracy and completion-time metrics across a large contributor pool. Participants could independently reproduce the scoring, making one scoring authority easier to scrutinize.
That is an illustrative fit, not evidence of a deployed success. Test design, resistance to manipulation and evaluator reliability would still matter. Where quality depends on subjective judgment, private inputs or disputed assessments, independent evaluators may provide valuable checks. Null simplifies the on-chain calculation; the subnet must still solve the problem of trustworthy evaluation.
Benefits and trade-offs
Removing collective matrix and bond processing reduces a major source of reward-calculation work. Larger registries may help workloads needing many contributors, and explicit weight ratios can express unequal contributions.
The dependency is the elected evaluator. Biased, compromised or ineffective scoring could distort rewards within the remaining rules. Miners need visibility into its tests and exclusions. Other staked UIDs can continue earning dividends without an independent scoring duty under Null, separating capital participation from evaluation work.
Scaling also involves registration, stake reads, delegation and payout writes. Simplifying one calculation does not establish reliable operation at the maximum population. Historical resource measurements raised unresolved engineering questions at merge; they do not demonstrate a current failure at 2,500 UIDs.
Technical note: the archived cost fixtures concerned 4,096 UIDs, not measured 2,500-UID production performance. The scheduling problem reported in issue #3230 concerned testnet, not an established Finney outage.
What is actually live on Finney?
A finalized-state snapshot on 15 October 2026, at 18:24:47 UTC, found Null enabled on three Finney subnets. The observations came from block 9,290,501, running runtime spec 479:
| Subnet | Registered UIDs | Configured capacity |
|---|---|---|
| 37 | 256 | 256 |
| 82 | 63 | 64 |
| 120 | 331 | 1,000 |
Subnet 120’s 331 registrations demonstrate use beyond 256 slots. None of the observed Null subnets was operating at 2,500. These figures describe that block, not permanent network conditions or independent-operator counts.
The implemented design was merged through PR #3206 and included in v475. The earlier equal-payment proposal, #3202, was closed. Later claim-based settlement work in #3255 remained a draft proposal when checked on 15 October; it is not part of the deployed behavior established by this research.
What this means for Bittensor
Increasing capacity does not itself increase a subnet’s funded rewards. More contributors may compete for an unchanged budget. Their earnings depend on their weight shares, token values and operating costs.
Commercial adoption and TAO demand require separate evidence. Useful output, reliable delivery and customers willing to pay remain the relevant tests, as our business evaluation guide explains.
Null creates room for more participants. Whether that leads to better results depends on how fairly and reliably their work is evaluated.
Sources and verification notes
This independent analysis uses public documentation, pinned Subtensor code and repository discussions linked throughout. Further primary references: Null guide, Yuma technical reference, stake computation and funding and settlement.
Bittensor.zone collected the Finney observations from finalized chain state via entrypoint-finney.opentensor.ai, using the same block hash for runtime and storage reads: 0xcc82040b71a1fa9ef2b945de395d3132947ba83e0830630c3df87c5ed92771e9. The snapshot time records completion of those reads. The first activation block, an independently reproduced source-to-runtime WASM match and full-capacity production performance remain unverified.
