Root Claims, Safer Staking, and Linked Orders

What shipped

Spec version 448 is a release about predictability. Its own summary is that it makes expensive operations easier to predict and multi-step operations safer to express: the SDK blocks a root claim that cannot fit the runtime's work envelope while the transaction is still being planned, and the runtime rejects an oversized raw submission at dispatch. btcli protects cross-subnet moves and supports multi-hotkey exits, linked orders can size a later trade from an earlier trade's output, and two live staking indexes replace scans that become more expensive as the network grows. [source]

The source for this page is one document: the project's own release note, titled "Root claims, safer staking, and linked orders" and dated August 2026. It is an interested party's account of its own work — so what follows reports what that note says rather than repeating it as established fact. [source] [source]

What it changes for the ecosystem

For anyone holding a root basket — the escrowed alpha a root network validator accumulates on a staker's behalf, covered on the v441 page and sitting on top of the root network staking lesson 10 describes — the practical change is where a claim fails. Both root-claim paths reserve the same conservative 256-unit work envelope, independent of the number of live networks; a claim whose required work cannot fit is rejected with RootClaimTooHeavy; and the fee for declared work that went unused is refunded after a successful claim. The minimum payout threshold is evaluated per validator rather than across a coldkey's positions as a whole. [source]

Unverified Evaluating the payout threshold per validator rather than over a coldkey's combined positions is presented as a correctness fix, and on the note's own terms it is one — the SDK now agrees with the runtime. It also implies that a coldkey whose root basket positions are spread thinly across many validators can hold legs that individually sit below the threshold while the aggregate sits above it. The note does not say how common that shape is, and nothing here has been checked against chain state.

Exiting a root position is the change stakers will notice first. Root --claim --all now claims first and resolves the full post-claim stake inside the atomic batch, so freshly claimed yield does not remain staked. That atomic form is available only while RootStakeUnlockInterval is zero; where a hold is configured, the note's instruction is to claim separately, wait out the interval, and then unstake. The new btcli stake unstake-all --all-hotkeys path discovers every staking hotkey for the coldkey and attempts to exit positions across them — but the runtime can skip disabled or otherwise invalid positions, so the release tells anyone automating a bulk wallet exit to verify the remaining stake afterwards, and to read the staking guide and the unstake-all reference first. [source]

Anyone moving stake between subnets gets a guard that is on by default. move_stake_limit changes hotkey and subnet in a single call while enforcing a minimum destination-alpha per origin-alpha ratio, and the SDK and btcli apply a 5% protection to cross-subnet moves unless the caller sets an explicit tolerance or deliberately disables the guard. Those protected moves are submitted fill-or-kill. Callers going in directly through the runtime, through EVM, or through WASM can opt into partial execution instead. [source]

For applications, indexers and dashboards, the change is a cheaper read path. TotalAlphaStaked maintains each subnet's aggregate stake in constant-time storage, and StakingHotkeys exposes the hotkeys relevant to a coldkey's staking and root basket state, the latter also through a paged EVM view — so an application can use these indexes instead of walking every stake position. [source] The population of those indexes is a background job, not an instant one: historical totals are backfilled and stale hotkey relationships cleaned in bounded passes using otherwise-unused on_idle capacity, normal staking stays enabled throughout, and operators need no separate migration — but until the total-stake backfill reaches a key, that key can be omitted from the aggregate, and live mutations are reconciled by the time the migration completes rather than necessarily being visible immediately. [source]

Linked orders are aimed at anyone composing a multi-leg trade. A V2 limit order can record its post-fee output, and a later order can spend a signed percentage of that recorded amount; provider and consumer must share the same signer, the output asset must match the consumer's input, and neither side may use partial fills. The output record is accounting rather than custody — the funds stay in the signer's balance, the first consumer removes the single-use record, and anything left over is ordinary balance again. [source] Records stay drawable for seven days; execute_orders can place a provider before its consumer in one call, while execute_batched_orders resolves amounts before its netted swap, so under that path the two legs have to be submitted separately. Existing V1 signed orders remain valid. [source]

Holders of proxies and multisig accounts get a narrower but sharper correction. Fee previews now distinguish the signer that pays from the proxy or multisig account whose state the call actually changes, and shielded submissions run the same hard intent checks as ordinary submissions, so wrapping a call no longer bypasses the reserve or work-limit preflight. [source] Planning keeps dispatch origin and fee payer separate through proxies and multisigs, so warnings, effects and hard blocks inspect the account the call changes. [source]

What to watch

Unverified The release note does not state a deployment status. It does not say whether spec 448 is running on the main network, when it might be, or what step remains before it is — so nothing on this page establishes that this is the runtime the chain executes today. It also prints no current value for RootStakeUnlockInterval, which is what decides whether the atomic claim-and-exit path is available at all. Both are chain state, and both have to be read there rather than inferred from this page.

Unverified The 5% tolerance on cross-subnet moves is a client-side default, not a chain rule, so a caller reaching the runtime directly — through EVM or WASM — gets whatever protection it builds for itself. Whether the gap matters depends on how much stake actually moves through those paths, which the note does not say.