Table of Contents
Bittensor has deployed support for quantum-resistant wallets on its Finney mainnet through Runtime 488, introducing three post-quantum signing schemes and optional automatic key rotation. The upgrade gives users a path to replace the classical signatures used by existing wallets without changing how their accounts hold TAO or participate in staking.
The Opentensor Foundation unveiled the wallets after the runtime reached mainnet. However, deployment has not yet opened the feature for use. Taostats reports that Runtime 488 went live at block 9,442,681 on November 5, but post-quantum signing and rotating-account registration remain disabled pending root activation. Post-quantum addresses can receive funds before activation, but cannot spend them.
Existing fixed-key Sr25519 and Ed25519 wallets retain their addresses and continue working normally. Users do not need to migrate to keep using Bittensor; adopting a post-quantum scheme requires a new account and compatible signing software.
Three Signing Schemes With Different Tradeoffs
A wallet signature proves that an account authorized a transaction. Bittensor’s existing Sr25519 and Ed25519 schemes rely on elliptic-curve cryptography, which a sufficiently powerful quantum computer could break by deriving a private key from its public key. The new schemes use post-quantum cryptography instead of those elliptic-curve assumptions.
Bittensor supports ML-DSA-65, Falcon-512, and Falcon-1024. ML-DSA-65 is standardized in NIST’s FIPS 204, while the Falcon parameter sets target different NIST security categories. Bittensor uses Falcon’s original padded signature format and does not claim compatibility with final FN-DSA encodings.
The official wallet crypto types guide details the differences:
| Signing Scheme | NIST Security Category | Public Key | Signature |
|---|---|---|---|
| ML-DSA-65 | 3 | 1,952 bytes | 3,309 bytes |
| Falcon-512 | 1 | 897 bytes | 666 bytes, padded |
| Falcon-1024 | 5 | 1,793 bytes | 1,280 bytes, padded |
Falcon-512 has the smallest public key and signature, while Falcon-1024 targets the highest security category of the three. ML-DSA-65 has the fastest signing time in Bittensor’s published comparison. These choices affect the amount of authorization data a transaction carries; transaction fees also depend on runtime execution weights, not signature size alone.
Key Rotation Without Changing the Account
The update separates two decisions: which cryptographic scheme signs a transaction, and whether the account keeps a fixed signing key or rotates it. All five supported schemes, including Sr25519 and Ed25519, can use either standard or hashed account mode.
In hashed mode, each transaction reveals the current public key and commits to the next one. When a valid transaction is included and reaches dispatch, the account advances to a new signing generation, even if the requested operation fails. Invalid or dropped transactions do not advance it.
The account’s address, balances, stake, and recovery phrase remain unchanged. During recovery, compatible software reads the current generation from the chain and derives the corresponding key, so users do not need to keep a separate history of signing keys.
Rotation alone does not make a wallet quantum-resistant. A rotating Sr25519 or Ed25519 account still uses classical signatures; ML-DSA and Falcon provide post-quantum signatures in both fixed-key and rotating modes.
The wallet implementation, including the ML-DSA integration, retains Bittensor’s existing signed-transaction envelope. Post-quantum proofs travel in the signer-address field, while the ordinary signature field holds a format marker that grants no authority. Metadata-aware clients can decode these transactions, but creating them still requires an updated signer.
Coldkeys, Hotkeys, and Multisig Protection
Support extends to coldkeys and hotkeys, allowing the new account types to authorize native operations such as transfers, staking, subnet registration, and validator weight-setting once enabled. Coldkeys control funds and account ownership, while hotkeys handle operational activity such as validator participation.
Multisig and proxy security requires more than changing the members’ signing schemes. A legacy multisig address is derived from its participants and approval threshold, but that derived address could also represent a classical public key. New safe composite accounts derive addresses that cannot be interpreted as Sr25519 or Ed25519 keys, preventing that route around the intended approval rules.
Safe mode creates a different address from a legacy multisig with the same members and threshold. Existing configurations keep their addresses. Safe composite accounts require no account-registration deposit, although normal multisig and proxy deposits still apply.
The approval policy must also require post-quantum authority. If enough classical members can authorize a transaction by themselves, or a classical proxy has sufficient permission, that route remains classical. Registered rotating ML-DSA and Falcon accounts enforce stronger ownership and delegation rules; standard fixed-key post-quantum accounts follow ordinary policies and can voluntarily delegate to classical keys.
Registration, Recovery, and Activation
Standard ML-DSA and Falcon accounts use an ordinary SS58 address and require no account registration or registration deposit. Rotating accounts must register and permanently reserve a deposit, set at 0.2 TAO by default. Root can change the amount for future registrations; ordinary transaction fees remain separate.
A sponsor can pay a rotating account’s registration deposit without gaining control of it. Supported transfers can register a recipient as part of funding it, but the payer must explicitly approve the reserve. Hashed wallets expose a descriptor-bearing tao_ receiving address alongside the SS58 form; both identify the same account, and the descriptor gives compatible software the information needed to arrange registration.
The documented CLI commands select the signing scheme with --crypto-type ms, --crypto-type falcon512, or --crypto-type falcon1024. Adding --type hashed selects rotating mode. ML-DSA and Falcon wallets use 24-word recovery phrases, and recovery must preserve both the original scheme and account mode. Restoring the same phrase with a different mode produces a different account rather than converting the original.
Browser extensions, hardware wallets, and other clients need explicit support for the selected scheme. The current wallet guide also says ML-DSA and Falcon do not support arbitrary message signing or HTTP authentication, a relevant constraint for hotkey-based applications. Ethereum transactions continue to use separate ECDSA wallets; native post-quantum signing does not make those EVM signatures quantum-resistant.
The Runtime 488 release changes are deployed, but root must enable AdminUtils.sudo_set_hashed_accounts_enabled before the new accounts can sign. The control covers all hashed accounts and all standard or rotating ML-DSA and Falcon accounts. Users preparing a migration should verify activation and client support before moving funds into a post-quantum address.
