# Null consensus (spec 474)

Subnet owners can switch their subnet from Yuma to Null: the top-stake validator sets miner pay and every staker earns dividends by stake.

_Source: https://taostats.io/docs/concepts/protocol-changes/null-consensus_

_Last reviewed: 2026-10-06_

> [!WARNING]
> **Not live on mainnet yet**
>
> Null consensus ships in runtime **spec 474** ([subtensor PR #3206](https://github.com/RaoFoundation/subtensor/pull/3206), merged 2026-10-06). Finney runs spec 473. When 474 ships, every subnet stays on Yuma until its owner switches.

## The short version

Null is a second epoch mode, alongside Yuma. A subnet owner or root can switch a subnet to it. On a Null subnet:

- **The validator with the most stake sets all miner pay.** Only that UID's weights count.
- **Dividends follow stake.** Every staked UID earns its stake share, active or not.
- **No bonds, consensus or clipping.** Weights are used exactly as sent.
- **The emission split is unchanged.** The owner cut comes first, then miners and validators split the rest.

Yuma stays the default on every existing and new subnet. The root subnet cannot use Null.

## Yuma vs Null

| | Yuma | Null |
|---|---|---|
| Who sets miner pay | All permitted validators, stake-weighted | Only the UID with the most stake |
| Validator permits | Up to `max_allowed_validators` | Exactly one, the top-stake UID |
| Validator dividends | By bonds | By stake. Inactive stakers still earn |
| Bonds, consensus, clipping | Yes | None |
| Weights | Normalised and clipped | Raw `u16` values, used as stored |
| Max UIDs per subnet | 256 ÷ mechanisms | 2,500 ÷ mechanisms |

## How miner pay is set

| Rule | Detail |
|---|---|
| Who | The registered UID with the most stake. One winner per epoch |
| Tie | The lowest UID wins |
| Inactive | Still counts. Inactivity does not remove stake |
| Owner | No special treatment. The owner only wins with the most stake |
| Empty or all-zero weights | Miner pay is split equally across every registered UID |
| No staked UID on the subnet | The validator half goes to miners |

This is a single point of control by design: whoever holds the most stake on a Null subnet decides every miner's share.

## For subnet owners

```bash
btcli hparams set --netuid 123 --name epoch_consensus --value Null
btcli hparams set --netuid 123 --name max_allowed_uids --value 2500
btcli hparams trim-null --netuid 123 --switch-to-yuma
```

| Item | Rule |
|---|---|
| Who can switch | Subnet owner or root (`sudo_set_epoch_consensus`), within the normal owner rate limit and admin window |
| Root subnet | Cannot use Null |
| Capacity on Null | Up to 2,500 ÷ mechanisms. Switching does not raise `max_allowed_uids`; the owner sets it |
| Back to Yuma | Registered UIDs must fit 256 ÷ mechanisms, so trim first |
| Trimming | At most 64 UIDs per batch (`sudo_trim_null_uids_batch`) |
| Pending commits | Must clear before any mode change |
| Validator limit | Set to 1 on entering Null. The previous value is saved and restored on return to Yuma |

## Registration: burn, proof of work or both

Burn and proof-of-work registration are separate switches, both settable by the subnet owner or root:

| Switch | Default |
|---|---|
| `registration_allowed` (burn) | On |
| `network_pow_registration_allowed` (PoW) | Off |

The chain rejects turning off the last enabled route, so to move from PoW back to burn, turn burn on first. This works on both Null and Yuma subnets. Root stays burn-only.

```bash
btcli hparams set --netuid 123 --name network_pow_registration_allowed --value true
btcli hparams set --netuid 123 --name registration_allowed --value false
btcli subnets register --netuid 123 --pow --yes
```

PoW difficulty moves with demand, the same way the burn price does:

| Item | Rule |
|---|---|
| After a PoW registration | Difficulty × `burn_increase_mult` (default 1.26) |
| Every block | Decays toward its floor using `burn_half_life` (default 360 blocks) |
| Burn price | Moves only on burn registrations. PoW does not touch it |
| PoW switched off | Difficulty keeps decaying, so turning PoW back on does not reset it |

## Commit reveal on Null

Commit reveal works on Null subnets with a larger payload: up to 32 KiB per commit, against 5,000 bytes on Yuma. Each Null subnet's commit queue is capped at 64 KiB and 64 commits per epoch, shared across mechanisms.

## Also in spec 474

A child hotkey can have at most **100 parents** per subnet.

## Known limits

The PR's own cost notes (`.maintain/null-4k-cost.md`) measured one Null epoch at 4,096 UIDs at a charged weight of 4.9 to 7.0 seconds, above the 4-second block limit. Capacity was set to 2,500 UIDs instead.

> [!NOTE]
> **Sources:** subtensor `main` at merge commit `02214123e` (spec 474): `subnets/mechanism.rs` (`do_set_epoch_consensus`, `NULL_UID_BUDGET`), `epoch/run_epoch.rs` (Null epoch, `null_validator_winner`), `subnets/uids.rs` (`NULL_PRUNING_BATCH`), `subnets/registration.rs` (PoW difficulty), `staking/set_children.rs` (`MAX_PARENTS_PER_CHILD`), `lib.rs` (commit limits), `admin-utils/src/lib.rs`. Finney spec read on two RPC endpoints, 2026-10-06.