Bittensor’s latest runtime changes how users pay for the account scan behind selected stake operations. The code calculates that part of the fee using an allowance of four hotkeys, while retaining the full execution and admission bound of 256.
Tao Outsider observed specVersion 466 at a finalized Finney block on September 18 at 10:17 OPO. The upgrade matters to users moving, removing or transferring stake, and to wallet developers estimating those costs.
A transaction can reserve enough capacity for a large scan while charging a smaller allowance for that particular component.
What the four-hotkey allowance covers
The implementation applies a fee-weight discount to specified calls for removing, moving, transferring and swapping stake. It also covers the bulk unstake_all and unstake_all_alpha paths.
For bulk operations, the discount follows the declared network envelope. Supported batch and proxy wrappers carry the discounts for their qualifying inner calls. The implementation deliberately excludes the with_weight override from that traversal.
Adding stake sits outside this discount’s call list. Base costs, transaction length and other fee components still matter. Actual savings depend on the operation and the applicable fee calculation.
For someone managing several positions, the useful change is in the cost assigned to scanning account relationships. Four is the fee allowance for that scan; the code retains its ability to inspect the larger permitted set.
Wallet estimates should preserve the distinction
The runtime’s fee-query APIs report the full execution weight alongside the discounted fee. The first describes reserved computational capacity. The second estimates what the transaction costs.
The payment wrapper uses the discounted declaration during fee preparation and caps the post-dispatch fee against it, preserving ordinary refunds when applicable. Execution accounting continues to see the full work.
This separation lets the protocol subsidize a specific cost without giving transactions extra block capacity. Wallets consuming the runtime query APIs have a basis for showing the revised estimate. Adoption by individual interfaces remains a separate question.
The final package keeps its previous block budget
The development sequence briefly included a larger native block budget. The final change restored the four-second reference-weight budget while retaining the scan-fee cap.
That budget is a runtime accounting parameter. It describes neither the interval between blocks nor a measured execution time. Claims about a twelve-second capacity expansion would describe an intermediate proposal that the final package removed.
Verification and limits
The finalized-block observation establishes that Finney reported runtime 466 by the retrieval time. It does not establish the exact activation time or independently match the deployed bytecode against a locally rebuilt release.
GitHub still labelled v466 as proposed and prerelease during the check, despite the chain observation. The article follows the finalized RPC response for the observed version and the pinned implementation for the fee mechanism. Tao Outsider has not measured matched before-and-after transaction fees or tested wallet estimates.
Sources
Staking scan-fee implementation
Final reference-weight budget correction
Was this article useful?
One tap feedback helps us improve each post.
