Root Validator Baskets

Root Validator Baskets are the mechanism Root Reborn introduced for handling root dividends. Root dividends no longer cash out to TAO: they are held in your root validator's basket of subnet alpha, which you redeem to TAO on demand.

For the full treatment see the Root Reborn explainer and its TL;DR. This page is the short canonical reference.

How the basket works

Each root validator has a single basket, staked under a global escrow coldkey with the validator as hotkey. Your root stake with that validator gives you a share of the basket, valued at the basket's net asset value (NAV).

• Dividends land where they were earned. A root dividend earned on subnet N is held as subnet-N alpha in the basket — the protocol executes no trades on it, so no swap fees and no slippage. Direct deposits (stake_into_basket) are split across the basket's current holdings by value and buy each one; the depositor pays that entry's swap fees and slippage.
• Only trades move composition. The validator reshapes the basket by trading (below). Otherwise the protocol only converts holdings to the basket's TAO slot: dust rows during a claim, and every holding on a deregistered subnet.
• Your deposit mints shares at the pre-deposit NAV, so existing holders are never diluted by an inflow.

The basket compounds through alpha emissions on its positions and price movement on the alpha held. It creates and destroys no TAO — it is TotalStake-neutral.

Basket trading: swap_basket

A root validator rebalances its basket with a single call, signed by its coldkey (or a BasketTrading proxy):

Sell amount of the basket's origin_netuid holding for TAO and buy destination_netuid with it. Either side may be root (netuid 0) — the basket's TAO slot. The TAO slot counts as a holding for the concentration cap, so trading can't lift it above 1/16 of the basket. Shares and staker entitlements are unchanged; only the basket's composition moves. Every trade emits a BasketSwapped event, so a validator's trades — and the fees and slippage they incurred — are public on chain.

Guardrails

Every swap_basket must pass all of these, or it rolls back:

The three caps are governance-set hyperparameters (u16-normalised; defaults 6553/65535 ≈ 10%, 6553/65535 ≈ 10%, 4096/65535 = 1/16). The basket_trading_status runtime view exposes the network gate, per-hotkey freeze, and remaining turnover budget.

Redeeming: claim_root

Your balance does not rise on its own. To realise rewards you make a manual claim:

• claim_root_with_hotkey(hotkey) — redeem one validator's basket (preferred).
• claim_root(subnets) — coldkey-wide sweep of every root-relevant validator. The subnets argument is ignored (kept for old-client SCALE compatibility).

Your share is valued at the basket's current NAV and redeemed pro-rata across all holdings, swapped to TAO, and staked back onto root on that validator. Redemption is always to TAO. If you want subnet alpha on your coldkey, claim to root, unstake, then stake into the subnet yourself.

Claims whose estimated payout is below the network claim threshold (default τ0.0005) are skipped and keep accruing. Dust holdings below that threshold are consolidated into the basket's root (TAO) slot as a side effect, so later claims get cheaper as rows disappear.

Since spec 468 a claim also leaves small rows unsold: a subnet holding worth less than min(τ1, 0.1% of the basket's NAV), or one where your own slice is worth less than τ0.0001, is skipped as long as your slice is at most τ0.01. Your whole share is still redeemed, so the skipped slices stay in the basket for the other holders (BasketClaimDustSkipped reports them). The TAO slot is never skipped.

Costs and considerations

• Claiming costs a fee, but billing is capped. Admission still uses a large declared work envelope (so heavy claims fit in a block), yet paymentInfo and the fee you pay are discounted to a fixed fee allowance of 4 claim units (ROOT_CLAIM_FEE_ALLOWANCE in the runtime) — about τ0.0082 after the spec 467 fee-rate halving. Light claims can refund below that; heavy claims are capped at it. Prefer a concentrated basket and claim infrequently.

• Reservation vs spent. The chain quotes the fee allowance at inclusion (paymentInfo); light work can refund unused weight after:

  Call	Admission envelope (block capacity)	Fee billed (paymentInfo)
  Single-validator (claim_root_with_hotkey)	129 units + scan(129) + flush bound	~0.0082 TAO (4-unit allowance)
  Coldkey-wide (claim_root)	256 units + scan(256) + flush bound	~0.0082 TAO (same allowance)

  You must have enough free TAO to cover the reserved amount to submit. Typical spent fees stay near the allowance for any non-trivial basket; tiny single-holding claims can land lower (~τ0.0015).

• Switching validators. New dividends follow your root stake, but what you're already owed doesn't: moving or unstaking credits pending dividends first, and your owed share stays in the old basket (still moving with its value) until you claim it with claim_root_with_hotkey or claim_root.

• Your return depends on subnet performance. Between claims you hold subnet-alpha exposure — it can outperform or underperform TAO. Stakers who want pure TAO exposure should claim more frequently — trading can't take a basket's TAO slot above 1/16 of its NAV.

• Pick validators on their basket. BasketSwapped events, NAV history, and composition are all public — judge a validator on what it holds and how it trades, not just its take rate.

Data on Taostats

The BetaBasketRuntimeApi exposes per-staker owed TAO, per-validator NAV and basket composition, network-wide root NAV, and basket_trading_status. These power basket performance, composition, and pending-claim metrics on Taostats.

Related

• Root Reborn — full explainer
• Root Reborn — TL;DR
• Stakeholder Emissions: Root
• Dividends for Validators
• Staking in dTao