Bittensor’s Finney network is running runtime 469, bringing changes to how Root claims handle tiny subnet holdings and how selected failed staking calls account for their computational work. Tao Outsider observed version 469 at finalized block 9,129,382 on September 23.
For Root participants, the most consequential detail is a tradeoff: a claim can settle its full entitlement while leaving very small slices in the validator’s fund. For wallet developers, the update also changes the weight charged when certain heavy calls fail.
What happens to a tiny Root claim
A Root claim redeems the claimant’s owed shares in a validator’s fund, sells the corresponding subnet alpha and restakes the resulting TAO on Root with that validator. A fund spread across many subnets can contain positions whose individual contribution to a claim is extremely small.
The version 469 code sets two default thresholds for skipping a sale. A holding can qualify when its anchored value is below the smaller of 1 TAO and 0.1% of the fund’s anchored net asset value. A claimant’s individual slice can also qualify when its anchored value is less than 0.0001 TAO. In either case, that slice must be worth at most 0.01 TAO at the anchored valuation.
The 0.01 TAO cap applies to each skipped slice. Several slices can be skipped in one claim. The valuation uses the smaller of the realizable sale quote and a fast moving-price reference, with a fallback while that reference is unseeded. A live price can exceed the reference, so the cap should be read in those valuation terms. Governance can change the defaults.
That cap matters for a participant with a larger entitlement. A small fund position can still produce a slice too large to skip, so the normal sale path applies.
When a slice is skipped, the claim settles the whole entitlement. The unsold value stays in the fund for its remaining holders, and the runtime records a BasketClaimDustSkipped event. Claim interfaces should make that outcome visible alongside the amount restaked.
Root cash is excluded from this dust rule. A participant redeeming the entire fund also skips nothing, because there would be no remaining holders to receive the retained value.
There is a separate rule for claims whose estimated total payout is below the claim threshold: those can be skipped while the entitlement continues to accrue. That is a different outcome from settling an admitted claim and leaving bounded dust slices behind.
Failed calls receive more specific weight accounting
Runtime 469 also extends actual-weight reporting to selected failed staking calls. Previously, an error could retain a large declared work allowance even when the operation performed much less work before stopping.
The release’s test suite includes failed stake transfers and stake exits. One transfer test checks that an insufficient-stake error returns a weight based on the base operation and the actual traversal, below the declared maximum traversal allowance.
For Root claims, the documented accounting distinguishes successful redemption, rows scanned and failures after admission. A scanned dust row still has a cost. Unused work allowance can be refunded.
These changes give wallet developers more precise outcomes to surface: the error, the work charged and, for a completed claim, any value retained as dust. The change covers specific paths; each operation’s failure handling determines its result.
Some expensive refusals retain the declared allowance. One repository test covers registration refused after searching for a slot to prune: that search has already done enough work to keep the declaration. A failed call alone therefore says little about the size of any refund.
What to watch
The useful next evidence is how wallets present these outcomes. A claim history that shows both restaked TAO and skipped slices would make the tradeoff easier to follow. Failed-call receipts should also reflect the runtime’s returned weight rather than treating the initial allowance as the final cost.
The version observation is a finalized-chain checkpoint. Thresholds and behavior above come from the tagged implementation, transaction documentation and repository tests; individual storage settings and staking transactions were not independently tested for this report. Actual fees depend on the call and network parameters.
Sources
- Root claim transaction documentation, version 469
- Root claim implementation
- Default dust parameters
- Failed-call refund tests, version 469
- Changes between runtimes 467 and 469
- Public Finney RPC
Was this article useful?
One tap feedback helps us improve each post.
