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

Pool	Share	Who earns	Live source of truth
Rented	13% — fixed	Nodes whose GPU is currently rented	Grafana — GPU model rate (per-model gpu_portion)
Unrented	0 – 87% — dynamic	Unrented nodes of eligible GPU models	Lium rewards calculator (per-model USD/epoch)
Burn	87% minus the unrented share and Spot idle pay	Designated 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.

Idle pay for Spot nodes that run a Lium Default Job comes out of the same ceiling: from what is left after the unrented pool, which would otherwise be burned. When the unrented pool takes the whole ceiling, Spot nodes get no idle pay that cycle.

"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 for the current 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), either validator-assigned score (score or the Job score shown in Job Logs) 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). An eighth rule is not released yet: the host must not keep putting the limit back while Lium's Pearl job runs (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.

A host that puts its own limit back while Lium's Pearl job runs loses the same payout through the same gate (not released yet). After two such jobs in 24 hours the idle payout stops and the job log carries reverts_gpu_power_cap; the payout resumes once fewer than two counted jobs remain in the 24-hour window. It withholds nothing until validators turn it on. Do not put the limit back has the details.

Price and the unrented incentive

Each GPU model has a soft limit: a price per GPU-hour, listed in the Soft Limit column of the rewards calculator. Price a node at or below its model's soft limit to keep the unrented incentive while it is idle. Priced above it, the node stays active and rentable and earns from rentals, and while idle it earns nothing from this pool. A model that shows no limit yet in that column has no soft limit, so its price never costs it the unrented incentive; whether it earns that incentive at all is set by the unrented pool requirements above.

The live list of soft limits loads in the browser, with JavaScript on. Each GPU model's soft limit is also in the Soft Limit column of the rewards calculator.

The soft limit follows the market: it is a fixed multiple of the 90th-percentile price for that GPU model, so it changes as prices change. Check it before you change a price, not just when you first set one.

This is not the hard cap: a price above machine_max_price_rate × the reference price zeroes score (not the Job score) at the validator and drops the node off the marketplace altogether — see Price limits.

The idle rate itself is the validator's rate table: Lium’s rate per GPU model, with B300 at 6.40 USD per GPU-hour and the RTX PRO 6000 Server Edition at the Workstation Edition's rate. Lium sets the rates by hand and re-checks them against the market; the rewards calculator shows the rate the validator pays today for each model.

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 the current tiers in the rewards calculator.

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.

The portal shows the same numbers when a tier is full. On the node page, the Idle Pay Tier row says what the tier's count was made of in the node's latest scoring run: how many idle nodes, and how many free GPUs of part-rented split nodes, with your share of each. On a node's earnings day, each run where the tier was full carries an Idle pay % badge, and the day summary says on how many runs a full tier reduced your idle pay. The count is the scoring run's, not the marketplace's: a split node is one marketplace listing, but its free GPUs are counted in the tier of its smallest rentable split (for example the 1× tier), and a node the marketplace does not list can still be counted while it is idle.

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 — twice the 8-GPU tier's 0.5 — 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. See Sysbox setup.

Discord is required for extra incentives

The rented and unrented pools pay providers whose Discord account is connected in the Provider Portal and is a member of the Lium Discord server. Other providers' nodes earn 0, rented or idle, until the account is connected and in the server. To earn again, rejoin the server, or disconnect Discord and connect it again in the Provider Portal. Pay resumes in stages: Lium re-reads membership within 60 minutes, the validator picks that up in its next 15-minute check, and the change reaches emission at the next tempo, about 72 minutes later. Emission is settled about 24 hours after it is scored, so allow about a day before it shows on your hotkey. The first payment after a rejoin is partial; the full share returns one tempo later.

Rental fees that renters pay for active GPU usage reach your coldkey as usual. 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; there is no single payout transaction to look for. Each tempo's emission is settled about 24 hours after it is scored, so what lands now reflects your node's state about a day earlier; idle pay of a node that was not active when its window settled is put on hold until one check a day later: paid if the node is active at that moment, lost if not (see Getting Paid).

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, 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).

• Grafana — GPU model rate (live rented-pool portion per model)
• Lium rewards calculator (live unrented-pool USD/epoch per model)
• TAO Market Cap — Subnet 51
• Subnet Alpha — Lium
• TAO Stats — Subnets

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.