Finney is already executing Bittensor Runtime 452 even though the public GitHub release still describes the package as proposed and awaiting signatures.
Two public Finney RPC endpoints returned specVersion 452 when Tao Outsider checked them at 10h06 BRT on August 30. That proves the runtime was active by the observation time. It does not identify the exact activation block.
The release is small by file count. Its failure boundaries are consequential. One group of changes stops a terminal problem in one Root basket holding from blocking healthy holdings in the same claim. Another prevents pending basket deposits from freezing unrelated Root stake changes. A separate change tightens how signed EVM precompiles can execute inside contract call frames.
Those are three distinct engineering stories. None of them proves better basket returns, recovered user losses, broader EVM adoption or a market catalyst.
Finney is ahead of the release label
The unusual part of Runtime 452 is the mismatch between two official surfaces.
GitHub labels v452 as a prerelease and says the proposed runtime is awaiting signatures. Finney, however, reports the runtime version the chain is actually executing. Both entrypoint-finney.opentensor.ai and lite.chain.opentensor.ai returned hexadecimal 0x1c4, which is decimal 452, through state_getRuntimeVersion.
For activation status, chain state outranks release-page wording. Runtime 452 was observed active on Finney by 10h06 BRT on August 30. The GitHub label had not caught up at the time of publication.
This is also why a release tag cannot be treated as an activation timestamp. Code may be tagged, proposed, signed and activated at different moments. Reporting each state separately is more useful than compressing them into one announcement.
One bad Root holding no longer has to block the whole claim
Root Reborn lets a Root staking position hold exposure through a basket of subnet alpha. Turning that basket back into TAO requires swaps. A basket claim can therefore encounter a holding whose available reserves are too low to complete the intended conversion.
Before the Runtime 452 change, a terminal swap failure could block progress across the broader claim path. The new code handles that failure per holding. A holding that reaches the terminal ReservesTooLow condition can be written down proportionally, while healthy holdings continue through settlement.
That design does not erase every loss or make an illiquid subnet liquid. It changes the scope of failure. The basket no longer needs to treat one terminal holding as a reason to stop processing unrelated holdings that can still settle.
The implementation records the failed portion and adjusts the corresponding alpha rather than pretending the swap succeeded. Tests cover mixed baskets, repeated claims and owner reward behavior. These are code-level guarantees about the intended path. Tao Outsider has not reproduced a historical user claim or measured the financial result of the change in production.
Pending deposits stop freezing unrelated stake changes
Runtime 452 also changes how pending basket deposits interact with Root stake operations.
A pending deposit represents work that has not finished moving into its target basket state. The previous path could cause that pending state to block changes beyond the deposit itself. The new logic keeps the pending deposit isolated so a user can still make other Root stake changes.
The code narrows the blocking scope in the staking flow; its effect on user-facing availability has not been independently measured. It offers no evidence that every pending deposit resolves faster. An unfinished deposit should no longer become a global lock on otherwise valid changes.
Combined with the per-holding claim behavior, the direction is clear. Root basket operations are becoming more granular about where failure lives. A bad holding stays a bad holding. A pending deposit stays pending. Healthy or unrelated state can continue when the surrounding checks pass.
The EVM change is a different boundary
The precompile work in Runtime 452 belongs to Bittensor’s EVM compatibility layer, not to Root baskets.
Precompiles expose native functionality at reserved EVM addresses. Some Bittensor precompiles can dispatch signed runtime calls. The merged change requires the code address being executed to match the current EVM call frame for those signed-dispatch precompiles.
That matters when one contract reaches another through call modes such as delegation. Without a frame check aligned to Frontier’s execution model, a precompile could be reached under a context that does not match the address whose native behavior is being invoked.
The patch does not disable stateless cryptographic precompiles. It targets the signed-dispatch surface where execution context and authority matter. The accompanying test suite checks contract deployment and call behavior under the revised boundary.
This should be described as call-frame alignment, not as proof that Bittensor’s EVM layer is secure against every contract pattern. The code narrows one class of context mismatch. Independent security review and production observation remain separate evidence.
What Runtime 452 changes for operators
Root basket users get more localized failure handling. A terminal reserve problem in one holding should no longer stop healthy holdings from settling, and a pending deposit should no longer block unrelated stake changes.
Contract developers get a stricter execution boundary around signed-dispatch precompiles. Integrations that depend on indirect call modes need to match the current frame rules.
Node operators have the clearest immediate obligation. Finney is already on 452, and the release page’s proposed label was stale against chain state at the time of our check.
Runtime 452 does not rewrite the economic system covered in Tao Outsider’s Runtime 421 through 450 investigation. It is a focused reliability and execution-context release after that larger sequence.
Runtime 452 does not solve every Root basket problem. It contains these failures more precisely, while Finney’s live state again shows why on-chain verification matters more than a release label.
Sources
Rao Foundation release: Subtensor v452
Rao Foundation comparison: Runtime v450 to v452
Root basket pull request: Handle terminal basket swap failures per holding
Root stake commit: Avoid blocking Root stake changes on pending basket deposits
EVM pull request: Align precompile execution with the current call frame
Was this article useful?
One tap feedback helps us improve each post.
