Bittensor Runtime 454 repairs Root claims and contract proxy stake transfers

Finney is running Bittensor Runtime 454. Tao Outsider confirmed specVersion 454 through the public Finney RPC on September 5, after GitHub had published the release artifact as proposed and awaiting its second multisig approval.

That sequence matters. The release page records the package and deployment process, while the chain reports what is active. Runtime 454 is no longer merely proposed.

The upgrade is a repair release rather than a new economic regime. It changes how coldkey-wide Root claims account for work, lets certain tiny but valuable basket positions settle instead of stalling, and restores one explicitly delegated contract-proxy path for transfer_stake.

Those are narrow changes with practical consequences. They are not a Root Reborn relaunch, free claiming, or proof that every historical claim problem has disappeared.

Root claims were counting the wrong kind of breadth

Root Reborn lets a validator hold a basket of subnet alpha through Root. When a staker claims, the runtime has to inspect the relevant validator relationships and basket rows, redeem the corresponding alpha, and calculate the TAO owed.

That work cannot be unbounded. Runtime calls declare a maximum amount of work so a block producer can decide whether the transaction fits before execution.

Before Runtime 454, the coldkey-wide admission check could multiply a coldkey’s staking hotkeys by the number of existing networks. A hotkey used only on an unrelated subnet could therefore enlarge the Root claim estimate even when it had no Root stake or outstanding Root basket claim.

The new code filters the selection first. A hotkey is relevant when it has Root stake or a negative basket watermark showing shares that still need redemption. The runtime then counts selected hotkeys plus the basket storage rows it will scan. Classification of the broader staking-hotkey vector is separately capped.

The safety envelope remains. Runtime 454 stops unrelated subnet relationships from consuming the Root claim budget as if each one required a full network-wide walk.

The documentation still describes a conservative 256-unit envelope and a refund for unused work. Runtime 454 changes what enters that envelope and how the scan component is priced. It does not promise that every large coldkey can claim everything in one call.

One atomic alpha unit fixes a rounding dead end

Root baskets can contain fractional entitlements. At the smallest unit, integer arithmetic can leave a claimant owed nonzero TAO from a valuable basket row while the proportional alpha amount floors to zero.

Earlier code treated that condition as a reason not to settle the claim. The concern was legitimate. Burning shares without transferring any alpha could hand value to the remaining holders.

Runtime 454 uses a more precise path. When the proportional alpha amount is zero but the priced entitlement is positive, the subnet is not Root, and the row is not terminal garbage, the runtime can sell one atomic alpha unit. It pays no more than the claimant’s calculated entitlement and keeps any surplus as fund Root cash.

For the final claimant, the code allows all realized rao to be paid so value is not stranded behind zero remaining shares.

This is a rounding repair, not a bonus. The claimant does not receive an arbitrary windfall from the one-unit sale. The payout remains bounded by the pro-rata value the basket accounting assigned.

Contract proxies regain one stake-transfer call

Runtime 453 tightened inherited origin filtering for calls dispatched through a proxy. Runtime 454 adds a deliberately narrow exception for contracts.

A contract that a user has explicitly registered as a proxy can dispatch transfer_stake on that user’s behalf. Other contract calls do not become generally available through the same filter.

The code comment is unusually clear about the boundary. The contract must already hold the user’s proxy delegation, and the inherited filter remains active. A contract without that explicit delegation cannot use this exception, and the change does not expand proxy powers generally.

Tao Outsider did not execute this path with a contract account. The claim here comes from the active runtime package and its code diff.

Who is most affected

Coldkeys with many staking relationships are the clearest audience for the Root claim changes. Validators with broad alpha baskets and software that estimates fees before signing are also directly affected.

The Python SDK code in the same release now queries stake information to identify Root-relevant hotkeys, reports the admission limit and selection scans, and estimates both redeem and scan work. A wallet or operator tool can therefore explain why a claim is too heavy with more useful terms than hotkeys multiplied by every network.

Contract-based account systems are the other direct audience. A product that depended on delegated stake transfer can recover that specific route after the Runtime 453 filter change, provided the proxy relationship is valid.

None of this establishes how many users were blocked, how much TAO was affected, or whether a known loss occurred. The public changes are defensive accounting and access corrections. The available evidence does not support a breach or victim narrative.

Activation is verified; outcomes are not

The strongest evidence in this story is the chain state. Finney returned specVersion 454 at the reporting checkpoint. The GitHub tag identifies the exact package, commit and WASM hash that went through the upgrade process.

The code supports three specific conclusions:

coldkey-wide Root claims filter for Root-relevant hotkeys and bounded basket work;
minimum-unit basket redemptions can settle without overpaying the claimant;
transfer_stake is permitted through an explicitly registered contract proxy.

The code does not prove that every wallet has adopted the matching SDK logic, that every validator operator has tested the claims, or that no edge case remains. Activation and independent execution are different facts.

Runtime 454 is small by protocol-upgrade standards. Its value lies in making Root accounting less sensitive to unrelated state and making two previously awkward paths explicit. Users should read it as a set of active repairs with defined limits. Bittensor’s economic design is unchanged.