Skip to main content

Rewards FAQ

1. How much will I earn with N×H100/H200/A100 on Subnet 51?​

Start with the rewards calculator. Enter your GPU model, count, and rental rate, and you'll get hourly, daily, and monthly projections based on live SN51 data.

Example: 8×H100 at $0.20/hr at typical SN51 utilization might earn $3,000–$4,000 per month from rental fees plus subnet emission, depending on current network conditions. But the actual number depends on:

  • Current SN51 demand for H100 capacity (drives both your rental utilization and the live gpu_portion for the rented pool — see the Grafana GPU model rate dashboard)
  • Your competitive pricing
  • Whether sysbox is running on your node (mandatory; without it your score is 0 post-cutoff — see the emission docs)
  • The bucket cap dilution for your (GPU model, count) pairing (see the unrented-pool eligibility rules)
  • Validator scoring at the time

The calculator accounts for all of these. Use it as your primary planning tool, and revisit it weekly as network conditions change.

2. Why are there two reward streams instead of one?​

Subnet 51 combines two independent reward sources:

  1. Rental fees (platform side) — when a renter books your GPU, Lium collects USD and distributes your provider share daily as alpha.
  2. Subnet emission (Bittensor protocol side) — the SN51 subnet mints new alpha tokens every ~72 minutes (one tempo) and distributes them to eligible providers via Yuma Consensus.

The two streams coexist because rental demand is not always saturated. SN51 emission itself is split into three pools (rented, unrented, burn — see Subnet emission): when your GPU is unrented and its model is eligible, you earn from the unrented pool; when your GPU is rented, you earn rental income plus a slice of the rented pool.

See the Rewards index for a diagram showing both streams.

3. Why did I receive less than the calculator predicted?​

Common reasons:

  • Actual utilization fell short — your real rental utilization tracked below the figure you used in the calculator (for example, you assumed steady-high utilization but averaged moderate). Lower utilization means lower rental income.
  • Sysbox dropped out — sysbox is mandatory. Any window where sysbox-runc was not running on your node zeros that period's score.
  • Live gpu_portion shifted — the rented-pool portion for your GPU model is an EMA of platform-wide rental revenue and moves between epochs. Watch the Grafana GPU model rate dashboard.
  • Cap dilution kicked in — if more unrented GPUs landed in your (model, count) bucket than the per-model cap allows, every node in that bucket is scaled down by cap / unrented_count. See GPU-count tiers and capacity caps.
  • Your GPU count has no priced tier — the unrented pool pays per (model, GPU count) tier, and only some counts are priced (today 1 and 8). A 4-GPU node earns 0 from that pool unless you enable GPU splitting with a minimum count that does have a tier.
  • Misbehavior windows — nodes with SSH failures, crashes, or policy violations forfeit that day's payout. Even one misbehavior incident can reduce your monthly total.
  • Emission allocation shifted — the dynamic split between the unrented pool and the burn pool moved; if rental activity dropped, more emission went to the burn pool (paid to designated burner UIDs only) and less to you.

The calculator shows a best-estimate snapshot. Your actual earnings are determined by live network conditions and your node's real-time score. Check the Payouts page for details on misbehavior policy.

4. When do I get paid? Can I be paid faster?​

Payouts are processed daily. Your earnings from a given day are computed at the end of the day, and a payout is initiated. You receive your alpha with a delay of 2 days.

There is no expedited payout path. If you need faster liquidity, unstake your alpha once it arrives (7-day unbonding period on Bittensor) and swap for a stablecoin on your exchange of choice.

5. Why do I have alpha and not TAO? How do I cash out?​

Subnet 51 uses dynamic TAO (alpha), a subnet-specific token backed by stake in the SN51 pool. When you earn rewards, you receive alpha in your coldkey.

To convert to standard TAO or another token:

  1. Unstake your alpha from the SN51 pool. This returns it to your wallet as standard TAO. See the Bittensor dynamic-TAO guide.
  2. Swap or sell your TAO on a centralized (Coinbase, MEXC) or decentralized (Uniswap) exchange.

Unstaking has a 7-day unbonding period on the Bittensor network. Plan accordingly if you need the tokens urgently.

6. What is the burn pool and how big is it?​

The burn pool is dynamic, not a fixed slice. SN51 emission splits into three pools each epoch:

  • Rented pool — 13%. It does not move with network activity, though Lium can retune the figure itself.
  • Unrented + burn — share the remaining 87% ceiling. The split between them is recomputed every epoch by the validator from real rental activity.

When unrented activity is low, most of the 87% ceiling falls into the burn pool — paid to designated burner UIDs rather than concentrated on a small set of active providers. As unrented activity ramps up, the burn pool shrinks toward zero. In mature operation with saturated unrented activity, burn can reach zero and the entire 87% flows to active unrented eligible nodes.

For the full three-pool table, see Subnet emission.

7. How do I increase my score and earn more?​

Today, the score depends on a small set of factors that actually move the needle:

  • Sysbox running (mandatory) — without sysbox-runc on your node, your score is 0. See Sysbox setup.
  • Run an eligible GPU model — only base models with a positive bucket cap earn from the unrented pool. The eligible/ineligible split is tuned over time; use the rewards calculator for the live snapshot rather than relying on a static list.
  • Pick a (model, count) pairing that isn't capped out — if your bucket already has more unrented GPUs than its cap, every node in that bucket is diluted by cap / unrented_count. Watch supply.
  • Turn on GPU splitting on multi-GPU nodes — your minimum split count gives the validator a second GPU-count tier to rate the idle node against. It rescues a node whose GPU count has no priced tier at all, and it lets a node escape its own tier when that tier is over its cap. See GPU splitting.
  • Competitive pricing — set your rental price competitively. Higher utilization shifts you from the unrented pool into rental income + the rented pool. The rented pool's per-model gpu_portion is updated live from rental revenue (visible on the Grafana dashboard), so models that get rented heavily earn more from the rented pool too.
  • Mind your Default Job — running your own Default Job on an idle node forfeits the unrented incentive for that node. Leave the node in Lium Default Job to keep the incentive (Lium runs its own Default Job there instead).
  • No misbehavior — failed verifications and SSH/connectivity incidents zero out your score for the affected day.

To increase your earnings:

  1. Make sure sysbox-runc is installed and running on every node.
  2. Run an eligible GPU model and check whether your (model, count) bucket is already saturated.
  3. Adjust your price to match demand; too high and you won't rent, too low and you leave money on the table.
  4. Use the rewards calculator and the Grafana GPU model rate dashboard to plan against live numbers — the static tables in this doc and in the validator config change over time.

For detailed operational guidance, see the Provider portal documentation (if available) or the Getting started guide.

8. My idle node's rate changed and I didn't change anything. Why?​

The unrented pool is divided into (GPU model, GPU count) tiers with capacity caps, and those caps are shared with every other provider on the subnet. Two things move on their own:

  • Other providers arrived or left. When a tier goes over its cap, every node in it is diluted by cap / unrented_count. When those GPUs get rented or go offline, the dilution lifts.
  • Your node changed tier. If you run GPU splitting, an idle node in an over-cap tier is rated against your minimum-split tier whenever the node fits in that tier's free capacity. That free capacity is shared, so a node can be moved one cycle and not the next.

Neither is a penalty, and nothing on your host changed. Both are visible on every scoring run in the node's Grafana job logs — check the tier, its cap, and the multiplier. The full rules are in When your GPU-count tier is full.

The way to stop depending on shared idle capacity is to get the node rented: price it competitively so it earns rental fees plus the rented pool, neither of which is capped this way.