Skip to main content

Subnet emission

Subnet 51 receives a share of Bittensor's per-tempo (~72 minutes) TAO emission. Validators split that share across three pools — rented, unrented, and burn — and pay the result to providers as alpha.

Bittensor protocol layer (general context)

Every 72 minutes (~360 blocks), Bittensor emits new TAO to the network:

  • 41% to providers (the protocol's "miner" role)
  • 41% to validators and stakers
  • 18% to subnet owners

Subnet 51 competes for the provider share alongside other subnets, then distributes its slice via Yuma Consensus. See Bittensor Emissions and Yuma Consensus.

Subnet 51 layer​

Each epoch the validator splits the SN51 provider emission into three pools.

The three pools​

PoolShareWho earnsLive source of truth
Rented13% — fixedNodes whose GPU is currently rentedGrafana — GPU model rate (per-model gpu_portion)
Unrented0 – 87% — dynamicUnrented nodes of eligible GPU modelsLium rewards calculator (per-model USD/epoch)
Burn87% minus the unrented shareDesignated burner UIDs only—

The unrented and burn pools share a ceiling of 87%. When unrented activity grows, burn shrinks toward zero; when unrented activity is sparse, burn absorbs the slack.

"Fixed" here means the rented pool does not move with network activity the way the unrented/burn split does — not that the number can never change. The ceiling is a platform setting the validator reads at the start of every cycle, so Lium can retune it without a subnet release (it moved from 91% to 87% in mid-2026). The current value is always published at lium.io/api/v1/shared-config as total_burn_emission; the rented pool is whatever is left over.

Rented pool​

Distributed across rented nodes in proportion to a live per-model gpu_portion, which the validator updates from rental revenue every time the Lium platform reports a new figure. The current values are on the Grafana dashboard — treat that as the live truth.

Unrented pool​

Distributed across unrented nodes of eligible GPU models. The eligible models, the per-(model, gpu_count) USD/hr prices, and the per-bucket supply caps all change over time as Lium tunes the validator's incentive parameters — so use the rewards calculator rather than memorizing a list. See Rewards calculator for a walkthrough.

Eligibility is seven things: your GPU is not currently rented, it is not running your own Default Job (running your own Default Job forfeits the unrented incentive for that node), its base model has a positive bucket cap (a per-model limit on how many unrented GPUs can earn from this pool), your validator-assigned score is > 0, the node carries enough disk for its VRAM (below), its price is at or below the soft limit (below), and its node container can set a GPU power limit (below).

Flagship nodes have one extra condition: an 8× H200, B200, or B300 node must also offer GPU splitting (with a minimum below the node's total), GPU Profiling (ncu), or run inside a confidential VM whose TDX quote the validator verifies. With none of the three, the node stays active and rentable but forfeits this pool while idle.

Every node also has to carry enough disk for its own GPUs: total disk must be at least 1.5× the total VRAM of the node's GPUs. VRAM is summed across every GPU on the node. Disk is the node's total disk, not its free space — free space moves with whatever is running, total does not. A node sitting at exactly 1.5× passes; only strictly less is gated.

Below the line the node stays active and rentable, and its rental fees are untouched — only the idle payout is lost. The node's job log carries the reason insufficient_disk_for_vram with both numbers. Rented nodes are never checked, and a node whose scrape is missing either number is never flagged, so nothing is lost over missing telemetry.

The disk the validator measures is the one behind the Lium node container, not your host's root partition — on a machine where Docker's data directory sits on a separate drive, df -h / reports the wrong disk. Measure it the way the validator does, from inside a container:

nvidia-smi --query-gpu=memory.total --format=csv   # sum across all GPUs
docker run --rm alpine df -h /                     # total disk, as the validator sees it

The disk figure has to be at least 1.5× the VRAM sum. An 8× H100 80GB HBM3 node with 637.2 GB of VRAM needs 955.8 GB of disk; at 483.3 GB it is at 0.76× and earns nothing from this pool while idle. An 8× RTX PRO 6000 Blackwell at 764.7 GB VRAM / 865.2 GB disk is at 1.13× — past 1×, still short of the line. 8× H200 nodes at 1123.2 GB VRAM / 1731.4 GB disk are at 1.54× and pass.

The node has to be able to cap its GPUs​

One of Lium's own idle jobs caps GPU power before it starts, so the node container must be allowed to run nvidia-smi -pl: it needs CAP_SYS_ADMIN, and /dev/nvidiactl has to belong to root inside the container. A node that provably cannot do this stays active and rentable, keeps its rental fees, and loses only the idle payout, with the reason cannot_apply_gpu_power_cap in its job log. A node whose scrape carries no readable answer is never flagged.

The standard node stack already runs with the rights it needs, so an affected node is usually one that stopped updating, one started from a hand-written compose file, or a host where Docker's default-runtime is sysbox-runc. GPU power cap has the check command and the fix for each case.

Price and the unrented incentive​

If you price a node above the soft limit — the GPU model's market p90 × soft_limit_price_rate, published per model as the Soft Limit column on the rewards calculator — it stays active and rentable while idle, but earns nothing from this pool. A model Lium has no market p90 for is exempt and keeps the full unrented incentive at any price.

This is not the hard cap: a price above machine_max_price_rate × the reference price scores the node 0 at the validator and drops it off the marketplace altogether — see Price limits.

GPU-count tiers and capacity caps​

The unrented pool is not one pot per GPU model. Each model is divided into GPU-count tiers, and every tier has its own hourly rate and its own capacity cap (the "bucket cap"). Today the priced tiers are 1 GPU and 8 GPUs; Lium retunes this over time, so confirm against the rewards calculator rather than memorizing it.

Your node is placed in the tier matching its GPU count. Two consequences follow:

  • A GPU count with no priced tier earns nothing from this pool. A 4-GPU node sits in neither the 1-GPU nor the 8-GPU tier, so it has no rate and no capacity, and its unrented incentive is 0. It still earns rental fees normally when someone rents it — only the idle-time incentive is lost. GPU splitting is the fix; see below.
  • A tier over its cap dilutes everyone in it. If a tier's cap is 64 GPUs and 128 unrented GPUs are sitting in it, every node there is paid at 64 / 128 = 0.5 of its rate. Nobody is thrown out — the tier is shared proportionally.

Your node's tier, its cap, and the multiplier it was paid at all appear on every scoring run in the Grafana job logs.

When your GPU-count tier is full​

Turning on GPU splitting also sets a minimum GPU count per rental. That minimum names a second tier the validator can rate your idle node against. It gets used in two situations:

  • Your GPU count has no priced tier at all — a 4-GPU node, for example. It is rated against your minimum-split tier from the start, which is the difference between earning and earning 0.
  • Your GPU count has a tier, but that tier is over its cap — the node may be moved into your minimum-split tier for that cycle, under the rules below.

The move in the second case happens only when all of these are true:

  1. Your node is idle — a rented node earns from the rented pool instead.
  2. Your own GPU-count tier is over its cap this cycle.
  3. Your minimum-split tier is a priced tier with a cap.
  4. Your node's whole GPU count fits in that tier's remaining capacity. A node is never split across two tiers.

A node that moves is paid at the split tier's rate with no dilution, because rule 4 only admits it when it fits under the cap. Nodes already in the split tier are never diluted by an arriving node.

Example. The 8-GPU H200 tier holds 128 unrented GPUs against a cap of 64, so it pays every node there at 0.5. Your 8×H200 node has splitting enabled with a minimum of 1 GPU, and the 1-GPU H200 tier holds 2 GPUs against a cap of 10 — 8 free slots, exactly enough for your node. It is rated against the 1-GPU tier at 1.0 instead of 0.5: twice the effective rate for that cycle.

When it happens, the node's job log says so:

Unrented incentive: the 8x NVIDIA H200 tier was over its capacity when this executor was placed, so it is rated against its 1x split tier, which had free capacity and pays a better rate.

This is re-evaluated every scoring cycle. The free capacity is shared with every other provider, so a node can be moved one cycle and not the next. If more nodes qualify than there is room for, they are admitted in a fixed internal order until the tier is full — there is no queue position you can buy or influence.

On a node with GPU splitting enabled, the rented check applies per GPU: while part of the node is rented, the remaining free GPUs still earn from the unrented pool (rated at the node's minimum-GPU-count tier), and the rented GPUs earn from the rented pool at the same time.

Burn pool (ordinary providers do not earn from this pool)

The residual: burn share = total burn ceiling − unrented share. Distributed equally across designated burner UIDs.

Sysbox is required​

Sysbox is a hard precondition. Without sysbox-runc running on your node, your sysbox_multiplier is 0 and you earn nothing — from any pool. The legacy partial penalty (a 0.8× multiplier for non-sysbox rented nodes) only applied to rentals created before the cutoff at 2026-04-03 12:00 UTC, which has now passed. See Sysbox setup.

Discord is required for extra incentives​

Providers must keep Discord connected in the Provider Portal to remain eligible for extra subnet incentives. Nodes from providers without connected Discord are treated like spot nodes for incentives: they do not earn from the rented or unrented incentive pools until Discord is connected again.

This does not change rental fees paid by renters for active GPU usage. See Connect Discord.

What about my score? (math details)

The math depends on which pool your node is earning from. The formulas below assume sysbox-runc is running on your node (without it, every score is 0) and the provider account meets the current incentive eligibility requirements.

Rented pool (your GPU is currently rented):

mining_score = score × gpu_portion × gpu_count / total_gpu_count_of_model
incentive    = mining_share × mining_score / total_mining_score

gpu_portion is the live per-model value on the Grafana dashboard. total_gpu_count_of_model is the total count of your GPU model across all rented nodes in the epoch — so your slice shrinks as more competitors of the same model come online.

Unrented pool (your GPU is unrented and its base model is eligible):

effective_rate = hourly_rate × unrented_cap_multiplier
incentive      = rental_share × gpu_count × effective_rate / total_rental_cost

unrented_cap_multiplier = min(unrented_count_in_bucket, max_cap) / unrented_count_in_bucket — cap dilution per (base_model, gpu_count_bucket). If your bucket already has more unrented GPUs than its cap, every node in it scales down proportionally.

hourly_rate is the rate of the bucket your node is rated against. For a splitting-capable node that is the better of its own GPU-count rate and its minimum-split rate, and the bucket itself may be the minimum-split bucket — see When your GPU-count tier is full.

How emissions arrive​

Subnet 51 emission accrues as alpha stake on your hotkey, added every tempo (~72 minutes) when the subnet's validators set weights via Yuma Consensus. It is not processed by Lium's billing system and is not transferred to your coldkey — it lands directly on the hotkey you registered on Subnet 51, as stake in the SN51 pool.

Why you may not see it on your hotkey. Emission is stake growth, not a transfer, so it does not appear in a wallet's "Transfers" or extrinsics tab — check the Stake view for your hotkey on the Subnet 51 page (e.g. taostats / TAO Market Cap). Two things can also make a hotkey look empty even though emission is arriving: it accrues continuously in small per-tempo increments rather than as one visible payout, and your coldkey may periodically re-stake or move the accrued alpha to a delegate. Rental fees are the separate stream that lands on your coldkey — see Getting Paid.

Where to monitor​

When a cycle paid a node nothing, expand that epoch in the node's Incentive history tab to read the reason per observation (see Earnings).

On-chain weights update at the end of each tempo (~72 minutes). The Grafana dashboard updates continuously as the validator processes new rental-revenue messages.