Glossary

What one alpha staked to this validator on this subnet earned over the last 7 days, annualised: the APR at a flat rate, the APY compounded every epoch, since alpha dividends are staked back into the pool.

A rate in alpha, so moves in the alpha's price are not in it. Already net of the validator take and of what its childkey parents received, while a childkey take earned on other coldkeys' parents lifts it. Blank until the hotkey has a full window of history, and when it earned nothing on the subnet in the last 7 days. Some explorers show the APR under the name APY. The 30D and 90D figures are the same over 30 and 90 days.

What a validator's basket holds, one row per subnet under the donut on its page: the alpha, its value in τ and $, its share of the basket, and how far that share sits from the subnet's weight in all baskets combined.

The holdings come live from the chain, so they can run ahead of the API's hourly copy, and the all-baskets weights from the API. vs all is a difference in points, not a ratio: 12% against an average of 8% reads +4. The TAO cash row counts τ instead of alpha and closes the table whatever the sort. The donut slices the same values, and the mark on each legend bar is the same all-baskets weight. Of all baskets on /validators is that weight; Average share beside it weighs every basket the same instead.

The ceiling on how much of one basket's value a single holding may reach through a trade. It is checked on buys only, so a holding that grows past it through prices or dividends is left alone: it can be sold down, not topped up.

The cap is a governance parameter that the hourly basket sync reads back from the chain, so the field always carries the current value. It binds trades, not accumulation: uncurated baskets hold single positions well above the cap, and only a sale brings them down. Kusanagi's own target allocation is fitted under it, which is why its largest weights sit at the ceiling and the excess is spread over the tail.

Two lifetime counters the chain keeps for each basket, in TAO: Deposited, the value added by everything that came in, root dividends as well as purchases, and Redeemed, what its holders' claims took out. The Flows view of a validator page's history card draws both as cumulative curves.

Deposited climbs with every root payout, even in a basket nobody bought into: purchases alone, with what each buyer paid, are at /v1/beta-baskets/{hotkey}/deposits/. Neither counter measures performance: (value + Redeemed) / Deposited reads a basket seeded at launch, with no matching deposit, as a winner, which is why performance reads the share price. Between two points, Δvalue − ΔDeposited + ΔRedeemed is roughly what prices and rebalancing did to the holdings. On a validator page the curves end on the chain's live totals; on /validators the two columns wait in Customize.

How the share price of a validator's basket moved over fixed windows of 1, 7 and 30 days (Perf 1D, Perf 7D, Perf 30D) and since the oldest daily snapshot on record ("Since start" on /swap/funds, "Perf all time" on /validators). It is what one share bought then is worth now, in TAO.

Share price, not basket value against deposits: a dividend mints new shares at the current share price, so the basket's value grows while the price barely moves, only the slice the basket's own TAO earns lifting it. Every basket reads the same span or a dash, which keeps the windows comparable; Since start begins at each basket's first daily snapshot, not at its opening, so it can cover much less than the basket's life, and the days shown with it say how much. A validator page shows the 7D and 30D windows, each with its gap to all baskets, and the 24H change under its share price is computed in the app: the chain's live share price against the hourly point 24 hours earlier (within 2 hours), so it can differ from Perf 1D.

What the Buy shares card of a validator page estimates before you sign: the share of the basket the amount buys, what entering costs in pool fees and price impact, and what your new shares are worth once that is paid.

Estimates at today's pool prices, as the card says: the chain shows no preview. It splits the amount over the holdings in proportion to their value and mints shares on the value that added, at most what the least-covered holding allows, so the shares received can fall short of the estimate; the Portfolio shows the exact count. A pool the app cannot price leaves the entry cost as a dash rather than skipping that holding. The chain refuses a purchase into the basket of a validator without a root seat, which is why /swap/funds lists only those. A bought share earns only its price moves, no root dividend; the network fee is charged apart.

How a root validator changes what its basket holds: it sells one holding for TAO and buys another with it, in one trade. Dividends stay on the subnet that earned them and a purchase of shares buys the existing holdings in proportion, so only a trade changes the mix.

Validators no longer publish a weight vector to direct their dividends: the chain cleared every one and removed the call, and /v1/root-weights/ now answers 410 Gone. /v1/beta-baskets/composition/ and /v1/beta-baskets/subnets/ serve the holdings that replaced it, which is what the baskets page draws. Trades go through swap_basket behind a network-wide switch, and governance can freeze a single basket. Rebalances 7D on /validators counts each basket's trades over the last 7 days; the /swap/funds head counts the baskets with at least one ("N rebalanced in the last 7 days") and lists the three that moved the most TAO through the middle (Most rebalanced (7D)).

How much TAO a validator's basket may still trade right now. The chain caps each basket's rebalances at a daily share of its value, kept in a bucket that refills block by block, which also bounds the harm a leaked trading key can do: at most this budget a day.

Read hourly from the chain for each basket, then charged with that basket's trades since and refilled up to the newest indexed block, which as_of_block gives. Null when the hourly sync did not read it. Once the bucket is spent, a trade waits for the refill, whatever its size, and a single large rebalance can use up the whole budget in one block.

A per-validator fund that keeps a root validator's dividends as alpha, on the subnets that paid them, instead of selling them, so part of a root staker's yield sits in alpha the staker does not pick. Root stakers hold redeemable shares of it, as does anyone who buys some with TAO, and its value is what all its holdings would sell for, in TAO, added together.

Redeeming hands a holder its pro-rata slice of every holding, sold to TAO and staked back on root with the same validator (claim_root, or claim_root_with_hotkey for one validator); the dust slices a claim skips stay in the basket. The API names the value nav_tao, for net asset value; read it rather than spot_nav_tao, which marks every holding at its spot price and ignores depth, so no redemption could actually get it. Growth belongs to neither figure: a dividend mints new shares for the root stakers at the value of that moment, so a basket can grow several times over with its share price flat, and only the slice earned by the basket's own TAO, which mints nothing, lifts the price. A bought share earns no dividend, only its price moves. That is why the history card on a validator page opens on the share price, set against all baskets, with NAV and Flows as its other views, and why the yield beside it comes from neither. See "Root staking APY".

The share a validator keeps of what the stake its childkey parents, hotkeys of other coldkeys, delegate to it earns on this subnet. Separate from the take it charges its own nominators.

Capped at 18%. A raise waits 216,000 blocks (about 30 days) after the previous change on that subnet; a cut applies at once. A take set below a minimum adopted later is charged at the minimum, and a parent of the same coldkey pays nothing. Served up to about 15 minutes behind the chain.

What the validator paid out over one UTC day, across every hotkey it runs, in TAO: the first figure is what its delegators shared, the second what it kept as commission. The page labels them Del. Earn. 24h and Val. Earn. 24h, but they cover the last complete UTC day, which their tooltips name, not the last 24 hours.

A single day, not a rate, so it moves with the stake behind the validator and with what its subnets emitted that day: a large validator out-earns a small one at the same APY. That day is yesterday, or the day before while the ledger trails midnight; without a complete day in the last two, both figures are empty rather than older. The dollar figure beside each converts it at today's TAO price, not that day's. The childkey-take slice is counted inside these figures, not on top of them. A validator running a 0% take reads 0 on its own line while still paying its delegators in full. Only the validator's own page carries them, so a list of validators compares yields instead.

How many delegators are staking to the validator.

Wallets, not positions: the delegator table on the validator's page lists one line per wallet, hotkey and subnet, so it is always longer than this count. The validator's own wallet is counted too, since its self-stake is a position like any other. There is no dust floor. An explorer counting wallet-and-hotkey pairs, or applying a minimum stake, will differ.

How differently a validator votes from the rest of the subnet on the selected mechanism: 0% votes exactly like the stake-weighted pack, and the higher the figure, the further from it.

Computed in the app from the last weight vectors the chain stores (the last revealed ones on a commit-reveal subnet), so it is not Yuma's consensus: no median, no clipping. The validator's own vote is inside the pack, so a heavy validator reads low by construction: one with 60% of the stake reads at most 40%. A dash means the hotkey has no stored vector on this mechanism, or that the Weights section further down the page, which the column is computed from, has not loaded yet. Root's validators table has no Divergence column, root's page having no Weights section.

What proportion of all validator stake on the network this one validator controls.

Same exit-value pricing as Total Stake. The denominator is the visible set, not the whole chain, which is exactly why the column adds up to 100%. A validator's own page divides by that same total. Validators under 1000 τ are absent from the list but do have a page of their own, and it serves them a dominance computed the same way.

The commission the validator keeps out of its delegators' rewards.

A percentage, not a fraction: 18 reads as 18%. The chain applies it to the hotkey's dividend before the remainder reaches its delegators, so every yield on this page is already net of it. It is read per hotkey and a validator can run several with different commissions; the figure shown is the one of the hotkey holding the most stake, which the validator's page labels Take (main hotkey). A 0% take is real and not unusual, but 0% is also what a newly seen hotkey shows until the next commission read, every two hours, and what the Take column of a validator's subnets table shows on a subnet where the sync does not count the hotkey as a validator: the commission is only read there for hotkeys with more than 1,000 α of stake weight and either a validator trust above 0.001 or weights set in the last 20,000 blocks, or for a validator permit holder earning no miner incentive.

How many accounts hold a claim on a validator's basket: its root stakers, whose dividends the basket keeps, and the buyers of its shares.

Not the subnet Holders count, which counts the wallets holding a subnet's alpha. A buyer still counts after redeeming everything: a claim redeems bought shares and dividends as one balance, so nothing marks the buyer's exit, and the figure can run above the accounts holding shares today. Root stakers count from any non-zero stake, with no dust floor, as of the last stake sync. It is the Holders column on /swap/funds.

The TAO one hotkey earned on one subnet over the last 7 days, as a row of a validator's subnets table shows it, split three ways: what went to its nominators, what it kept as commission, and the part that came from childkey take.

Amounts, not rates: they scale with the stake behind the hotkey, which is why the APY sitting beside them can be high on a small line and modest on a large one. The two columns are not symmetric: the nominator side counts alpha dividends only, since what root stakers earned is reported on the root line, while the validator side counts the take on both. Root lines are not shown in this table at all. On a childkey row the three are the child hotkey's own, its operator keeping the take. Blank, not zero, when the ledger holds no payment to the hotkey on that subnet over those 7 days, and blanked with the yields once yields_as_of is older than the day before yesterday. The childkey figure is a slice of the other two, so adding all three double-counts it.

How much of a basket's mix all baskets combined also hold: 100% is a basket holding exactly the average mix, a low figure one that bets apart from it.

The combined mix is the Of all baskets column of the per-subnet table on /validators, the basket itself included, so the largest baskets pull the average toward themselves and read higher. The TAO cash counts as a holding like any subnet. Null for a basket without value or without a holding worth anything. In Customize on /swap/funds, and above the composition on a validator page.

The validators that delegate stake to a hotkey on one subnet through childkeys, listed when its row of a validator's subnets table is unfolded: the share of its stake each one gives, that stake's weight, and the weight that reaches the child.

Stake Weight is in this subnet's alpha units, root counting at γ as in Root weight (validator), so it compares within one subnet only, and a parent's root stake counts in full on every subnet it delegates on. It is rebuilt from the stake Taoswap indexes on the parent hotkey, its own and its nominators', pallet custody left out, rather than read from the chain, so Delegated approximates the weight the chain moves to the child. A pending parent shows the share its queued list gives (→ x%) and the wait until its block; a parent whose queued list leaves the child out shows its share → 0%. Parents are listed heaviest Stake Weight first, and the tooltip on Stake Weight splits it into root τ and alpha.

What one TAO staked on root through this validator was paid over a trailing window, as a simple annual rate. It is the root staker's yield, not a blend of the validator's alpha pools, and on root APY and APR are the same number.

Shown in four places: /validators offers 7, 30 and 90 days in its Customize menu, root's validators table (/subnets/0) opens on APR 7D per hotkey, the validator's page shows the longest window the hotkey's history fills (labelled Root APY 1Y, 180d, 90d or 30d, its tooltip naming the window's UTC days), and /swap/funds shows the 30-day APR of /validators as Root APR, a dash where that list has none. A validator's figure is its main hotkey's, the one holding the most stake, and it is what the chain actually paid, already net of the validator take and of childkey redistribution. Root payouts are queued and minted as basket shares, so the root TAO the rate is measured on never grows and nothing compounds: the APY is the APR. Exactly 10000 means the real figure was clamped (the app prints >10000%). Every window is null, not 0, for a hotkey paid no root dividend over the last 7 complete UTC days; a wider window stays null until the hotkey's root history covers it, or while the dividend ledger is being rebuilt. Stale values are never carried forward, and the app blanks them all once yields_as_of is older than the day before yesterday. On /validators an asterisk marks a validator with under 10 τ of root stake, where a day's noise annualises into hundreds of percent. It is neither the basket's Root staking APY, which values these payouts as fund shares, nor an alpha staker's yield: see APY / APR 7D (subnet), which the list's Alpha APY / APR columns average over the subnets the hotkey validates on, weighting each by the TAO value of its stake there.

Taking one of root's 64 seats. A seat directs a stream of root dividends, so the chain makes registration costly and rate-limited.

Governance can change these values, and the request serves the current ones. Registering also makes each subnet owner's hotkey a childkey of the registered hotkey, in the same transaction, unless auto-delegation is turned off for it first. Only a seat earns root dividends, so for a stake on root the validator pickers hide a hotkey without one, unless validators with no yield are shown. When root is full, eviction skips seats still immune and breaks ties on registration block, then uid. Taoswap has no screen for root registration: it is a validator operation done with btcli.

The two halves of a validator's total stake: TAO staked on root, and alpha staked across subnets (valued in TAO).

The alpha half carries the same slippage-aware valuation as Total Stake, so it moves with pool depth as well as with price. The Allocation donut on the validator's page splits this same pair; its stake chart does not: the Root stake line matches at 1:1, but the Alpha stake line prices alpha at spot (alpha_stake_tao of /validators/{hotkey}/history/), from a snapshot taken every two hours, so it usually reads above this half. alpha_stake_tao_with_slippage is its exit-valued twin.

What one TAO staked on root with this validator earned over the last 30 days (7 or 1 when the basket has no reading that far back), compounded to a year, each dividend valued at the moment it was paid. It is the reward itself and not the market value of what the basket holds: the two are different numbers, and they do not even rank validators in the same order.

Each dividend is valued once, when it lands, so what its alpha does afterwards stays out of the rate: that belongs to the share price, which a dividend barely moves since it mints shares at the basket's value of that moment. Never negative: a basket that took no dividend over the window reads 0%, and a window whose reading fell, which only a basket that emptied and restarted or a hotkey swap can produce, gives way to a shorter one, null when none is left. The API serves the 1-day window too; the app withholds anything measured over less than 7 days, a dash in the tables and no rate in the note, rather than annualize one day 365 times. It is Basket APY on /swap/funds, Validator APY in the portfolio's Root Staking dialog (hidden by default; its info mark names the last 30 days, and a row measured over a week shows 7D), and the rate in a validator page's Basket note, "Root staking with … keeps your τ and pays …% a year". The Root APR column beside it on /swap/funds is the validator's root APR over 30 days, another measure of the same rewards.

The validator's root stake counted the way the chain counts it for emission, where TAO on root does not weigh 1:1 against alpha.

A scaled TAO amount, not a ratio and not a second stake bucket, so never add it to the stake columns yourself. Same γ as the subnet Root Proportion. The list does combine it with the alpha stake in its own Total Weight column, which is the figure to use when comparing against explorers that discount root the way the chain does. Do not confuse γ with the owner share shown under Conviction, 0.18 by default but set per subnet: a different parameter entirely.

On a validator's subnets table, the part of its stake on that subnet the validator delegates to a childkey, a hotkey of another coldkey that validates with that stake. A change the validator has queued reads as today's share → the share it takes, with the wait until the chain applies it.

Only childkey rows carry one; the validator's own hotkeys read a dash. When several of its hotkeys parent the same child, the row shows the largest active share and Parent validators lists each. The wait assumes the 12-second target block time; once the block has passed, the row reads Pending until the next syncs, every 15 minutes, fold the change in. Queued changes are only tracked for the 128 largest validators by stake. The wait is the chain's childkey cooldown, which governance sets, and has nothing to do with the 216,000 blocks a childkey take raise waits (see Childkey take). The chips above the table count rows, not subnets: chk the childkey rows, pending those with a queued change, infra the validator's own hotkeys that are not inactive, and inactive the rows whose last weights are over 50,000 blocks old (about a week), which the table dims; a click shows only those rows.

The split of a validator's own stake between root and alpha, drawn as a bar. It says nothing about the validator's size relative to others, which is Dominance.

How concentrated a basket is: the share of its value sitting in its three largest holdings.

A reading of what the basket holds, not a rule: the chain's ceiling on a single holding is the Basket concentration cap, checked on buys only, so a basket that never trades can carry far more in one holding. Null for a basket without value or without a holding worth anything. Shown on /validators, above the composition on a validator page, and in Customize on /swap/funds.

Everything a validator has behind it, root stake plus alpha across every subnet, expressed in TAO.

Alpha is valued at roughly what its holder would fetch on exit, not at flat spot and not at the moving price, so it reads lower than a naive Σ(alpha × price) for large holdings; it is still slightly optimistic, since the swap fee is not deducted. The Accounts table values alpha the same way, so the two are directly comparable, though each reads the pools at its own sync. A position on a subnet with no pool is left out of the total rather than valued at zero. It is a snapshot from the last sync. The stake chart on the validator's page is valued differently: its Total stake and Alpha stake lines price alpha at spot, from a snapshot taken every two hours, so their last point usually reads above this figure, by the slippage it leaves out; /validators/{hotkey}/history/ also serves the exit-valued pair as stake_tao_with_slippage and alpha_stake_tao_with_slippage.

The head figures of the basket pages: what the baskets listed are worth together, and how many there are.

The /swap/funds sum includes the baskets under 10 τ its table hides by default. Each basket is valued as if it alone sold its holdings, so the total is more than all of them could fetch at once from the same pools. Baskets frozen appears on /validators only while governance holds at least one basket out of trading.

How a basket's share price did against all baskets over the last 7 or 30 days: above zero it beat the average basket, below zero it trailed it. The average is the All baskets line, a value-weighted index of every basket's share price.

A ratio, not a difference: a basket up 10% while the line rose 5% reads +4.76%, not +5%. Deposits and redemptions mint or burn shares at the basket's value, so the line follows what the baskets hold, not the money flowing in and out. A dash when the basket has no reading for the window or the line misses either end. It reads vs all (7D) and vs all (30D) in the /swap/funds and /validators tables and vs all baskets under each Performance window of a validator page, whose history card draws the line as All baskets, both curves starting at 0% on the first point they share. The /swap/funds head gives the line's own move as All baskets (7D), its 30-day move under it, and lists the three baskets worth 10 τ or more furthest Ahead of all (30D) and Behind all (30D).