Finney is running Bittensor Runtime 455. Tao Outsider confirmed specVersion 455 through the public Finney RPC on September 8, after RaoFoundation merged the runtime package the previous evening.
The upgrade narrows what two restricted coldkey proxy types can call. NonTransfer and NonFungible proxies can no longer reach the EVM, contracts or crowdloan pallets through Bittensor’s shared call group. Broader roles retain those routes according to the Runtime 455 filter.
This is a live permission change for delegated accounts. It is not evidence that an exploit occurred, that funds were lost or that every wallet interface already explains the new boundary.
Why Bittensor proxy types matter
A proxy lets one account submit a limited class of calls for another account. Operators use that separation so an online service can perform a defined job while a coldkey remains offline.
The value of the arrangement depends on the filter being understandable. A role named NonTransfer should not unexpectedly inherit a path that can move value through another execution surface. A role named NonFungible should remain bounded even when the runtime adds pallets that were not part of the original mental model.
Bittensor’s proxy system has several roles. Any is unrestricted. NonCritical covers a wider set of operations. More specific roles restrict the calls a delegate can dispatch.
Runtime 455 addresses an inheritance problem inside those groups.
What changed in Runtime 455
The implementation groups common calls so the runtime and its metadata can describe proxy capabilities from the same definitions.
Before the change, NonTransfer and NonFungible inherited EVM, Contracts and Crowdloan calls from that common group. The new filter denies those three pallets entirely for both roles.
NonCritical keeps access to them. Any remains unrestricted.
The distinction is deliberate. Runtime 455 does not switch off Bittensor’s EVM or contract systems. It changes which delegated identities can invoke them for a coldkey.
The final patch also preserves crowdloan access for proxy types that are supposed to have it. An intermediate commit disabled that route more broadly, then the merged implementation restored it for allowed roles while keeping the restricted roles closed. Reading only the intermediate diff would produce the wrong description of the active runtime.
Existing proxies become narrower without a storage migration
PR #3146 states that the change needs no storage migration. The proxy records themselves do not have to be rewritten.
The filter is evaluated when a proxy dispatches a call. Once Runtime 455 became active, an existing NonTransfer or NonFungible relationship encountered the narrower rule on its next attempt to use one of the denied pallets.
Activation therefore changes existing software behavior. A proxy setup can remain present on-chain while one previously accepted route stops passing the runtime filter.
Wallets and automation tools should inspect the active proxy metadata instead of assuming a role has the same practical reach it had under an earlier runtime.
Tao Outsider did not execute calls through a delegated coldkey. The evidence here comes from the active Finney version and the merged source code.
The runtime metadata follows the same groups
Permission systems become fragile when the execution filter and the user-facing description are maintained separately.
Runtime 455 derives proxy metadata from the same groups used by the filter. That gives clients a stronger basis for describing which call families a role accepts.
It does not guarantee that every interface consumes the metadata correctly. A wallet can lag the chain, cache an older description or present a proxy label without listing the affected pallets. The runtime boundary is active even when a product has not caught up.
This is why specVersion 455 and UI adoption are separate claims. The first is verified. The second was not measured in this report.
Who needs to check their setup
The immediate audience is anyone using a coldkey proxy for automated Bittensor operations, custody processes or contract-connected account systems.
Operators should review the actual role assigned to each delegate and the calls their software expects to dispatch. A task that legitimately needs EVM or contract access now requires a proxy type whose active filter permits it. Expanding a delegate to Any simply to restore a broken workflow would also expand every other permission, so it is a security decision rather than a compatibility shortcut.
Developers building wallet and custody products should refresh runtime metadata and test failure handling. A denied call should be surfaced as a permission mismatch, not retried as though the network were unavailable.
What the change does not prove
Runtime 455 is security hardening with a narrow technical scope.
The public evidence does not establish a Runtime 454 exploit, a victim count, a customer incident or an independent audit. The merge discussion describes the permission mismatch and the intended filter behavior. It does not support a loss narrative.
The on-chain version also cannot prove that every downstream tool has updated its labels or tests. Nor does it make NonTransfer and NonFungible universally safe for every future call. Proxy policy still has to evolve when the runtime gains new call families.
The useful conclusion is specific. Bittensor has closed three inherited call families for two restricted proxy roles, and Finney is enforcing that code now.
Sources
Runtime 455 implementation pull request
Restricted proxy implementation commit
Finney RPC endpoint used for activation verification
Was this article useful?
One tap feedback helps us improve each post.
