The V448 Upgrade
Root claims, safer staking, and linked orders · August 2026
Introduction
Spec 448 makes expensive operations easier to predict and multi-step operations safer to express. The SDK now blocks root claims that cannot fit the runtime envelope during planning, while the runtime rejects oversized raw submissions at dispatch. btcli protects cross-subnet moves and supports multi-hotkey exits, and linked orders can size a later trade from an earlier trade's output. Two live staking indexes replace scans that become more expensive as the network grows.
Root claims fail safely and quote real costs
Both root-claim paths reserve the same conservative 256-unit work envelope, independent of the number of live networks. The runtime rejects a claim with RootClaimTooHeavywhen its required work cannot fit that envelope, then refunds the fee for unused declared weight after a successful claim. The SDK mirrors that check during planning and evaluates the minimum payout threshold per validator, matching runtime enforcement rather than combining a coldkey's positions into one aggregate result.
Fee previews distinguish the signer that pays from the proxy or multisig account whose state the call changes. Shielded submissions run the same hard intent checks as ordinary submissions, so wrapping a call no longer bypasses the reserve or work-limit preflight. See the Root Reborn guide for claim fees, thresholds, and basket semantics.
Stake moves and multi-hotkey exits are safer
Runtime v448 adds move_stake_limit: one call can change both hotkey and subnet while enforcing a minimum destination-alpha per origin-alpha ratio. SDK and btcli cross-subnet moves apply a 5% protection by default; callers can set an explicit tolerance or deliberately disable the guard. SDK and btcli submit protected moves as fill-or-kill; direct runtime, EVM, and WASM callers can opt into partial execution.
Root --claim --all exits now claim first and resolve the full post-claim stake inside the atomic batch, so freshly claimed yield does not remain staked. This atomic form is available only while RootStakeUnlockInterval is zero. When a hold is configured, claim separately, wait out the interval, 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. The runtime can skip disabled or otherwise invalid positions, so automation should verify the remaining stake. Review the staking guide and unstake-all reference before automating a bulk wallet exit.
Live staking indexes replace expensive scans
TotalAlphaStakedmaintains each subnet's aggregate stake in constant-time storage, while StakingHotkeysexposes the hotkeys relevant to a coldkey's staking and root-basket state. The latter is also available through a paged EVM view. Applications can use these indexes instead of walking every stake position.
Historical totals are backfilled and stale hotkey relationships are cleaned in bounded passes using otherwise-unused on_idle weight. Cleanup preserves a relationship when root-basket claim state still needs it for discovery. Normal staking remains enabled throughout and operators do not need to run a separate migration. Until the total-stake backfill reaches a key, that key can be omitted from the aggregate; live mutations are reconciled by migration completion, not necessarily visible immediately. Unrelated stale hotkey relationships can likewise remain until cleanup finishes.
Linked orders compose multi-leg strategies
A V2 limit order can record its post-fee output, and a later order can spend a signed percentage of that amount. Provider and consumer must have the same signer, the output asset must match the consumer's input, and neither side may use partial fills. The output record is accounting, not custody: funds remain in the signer's balance, and the first consumer removes the single-use record. Unused output remains ordinary balance.
Records stay drawable for seven days. execute_orders can place a provider before its consumer in one call; execute_batched_orders resolves amounts before its netted swap, so the two legs must be submitted separately there. Existing V1 signed orders remain valid. The limit-orders referencedocuments the signed payload, validation rules, and pruning behavior.
Wrapped and shielded submissions preserve intent
Planning now keeps dispatch origin and fee payer separate through proxies and multisigs, so warnings, effects, and hard blocks inspect the account the call actually changes. Shielded raw calls and multisig approvals honor wait_for_finalization for the decrypted inner extrinsic. The SDK waits for canonical finality, resumes scanning if a reorganization removed the observed inner call, and raises ChainError after bounded finality RPC failures or stalled-finality polling instead of hanging forever. See advanced submission for the full composition model.