# Quantum-resistant wallets (release 487)

New wallet types signed with ML-DSA-65, Falcon-512 or Falcon-1024, plus rotating 'hashed' accounts and quantum-safe multisig and proxy addresses. Existing wallets keep working unchanged.

_Source: https://beta.taostats.io/docs/concepts/protocol-changes/quantum-wallets_

_Last reviewed: 2026-10-30_

> [!WARNING]
> **Not live on mainnet yet**
>
> This page describes [subtensor PR #3220](https://github.com/RaoFoundation/subtensor/pull/3220), merged into the `release-487` branch (commit `820544921`). That code is not on subtensor `main` yet, and work on the branch is ongoing. Once deployed, the whole feature stays off until root switches it on with `AdminUtils.sudo_set_hashed_accounts_enabled`.

## What it does

Every Bittensor wallet today signs with an elliptic-curve key (Sr25519 or Ed25519). A large enough quantum computer could work out such a private key from its public key, which every signature exposes. This upgrade adds signature schemes that don't rely on elliptic curves.

Existing Sr25519 and Ed25519 wallets keep their addresses and work as before. There is no migration.

## Wallet types

A wallet is two choices: a **signing scheme** and an **account mode**.

| Scheme | Quantum-resistant | Public key | Signature |
|---|---|---|---|
| Sr25519 (default) | No | 32 B | 64 B |
| Ed25519 | No | 32 B | 64 B |
| ML-DSA-65 (NIST FIPS 204) | Yes | 1,952 B | 3,309 B |
| Falcon-512 | Yes | 897 B | 666 B |
| Falcon-1024 | Yes | 1,793 B | 1,280 B |

| Mode | Signing key | Registration | Addresses |
|---|---|---|---|
| Standard | One fixed key | None | SS58 |
| Hashed | Rotates on every included transaction | Required, with a permanent 0.2 τ deposit | SS58, plus a `tao_` receiving address |

Only the scheme decides quantum resistance. A hashed Sr25519 or Ed25519 wallet hides its key until each transaction, but it is still elliptic-curve and not quantum-resistant.

The mode is part of the account's identity. Restoring the same mnemonic with a different scheme or mode gives a different account. ML-DSA and Falcon wallets use 24-word mnemonics; Sr25519 and Ed25519 default to 12.

### Standard ML-DSA and Falcon wallets

This is the simplest quantum-resistant option. The wallet has one ordinary SS58 address, needs no registration or deposit, and uses a normal nonce. The address is a hash of the key, derived so that it can never also be read as an Sr25519 or Ed25519 public key. A classical signature can therefore never act for it.

### Hashed wallets

A hashed wallet registers once (`HashedAccounts.register`). Registration permanently reserves **0.2 τ**. It is a deposit, not a fee, and it is never refunded. Anyone can pay it for someone else without gaining control of the account, and a transfer to a `tao_` address can register the recipient in the same step if the sender agrees to pay the deposit.

Each transaction reveals the current key and commits to the next one. The key moves on whenever a transaction is included, even if the call itself fails. Recovery needs only the mnemonic: the wallet reads the current generation from the chain and derives that key.

The `tao_` receiving address never changes as keys rotate. It carries what a payer's wallet needs to check or perform registration. It converts to the account's SS58 address without any chain lookup.

## Transactions

Post-quantum and hashed transactions keep the normal signed-transaction format, but put the whole proof in the signer (address) field as a `MultiAddress::Raw` value:

| Signer | Raw signer size |
|---|---|
| Hashed Sr25519 / Ed25519 | 106 B |
| ML-DSA-65 | 5,367 B |
| Falcon-512 | 1,669 B |
| Falcon-1024 | 3,179 B |

The first 32 bytes of the raw signer are the account's permanent ID. For ML-DSA and Falcon, the ordinary 64-byte signature field holds a fixed marker and authorizes nothing; the real signature is inside the signer field.

Bigger transactions pay a higher length fee. Falcon-512 is the smallest post-quantum option.

## Who can control a protected account

A protected account can't hand authority to a weaker key:

- **Coldkey swaps:** a hashed coldkey can only swap to another hashed account, and a hashed ML-DSA or Falcon coldkey only to another registered post-quantum account. A weaker target fails with `HotkeyOwnerPolicyViolation`.
- **Proxies and hotkey owners:** the same rule applies to proxy delegates and to the coldkey that owns a hashed hotkey.
- **Standard ML-DSA and Falcon wallets** follow ordinary rules. They can swap to, or delegate to, a classical key. Only hashed mode locks quantum resistance in.

## Safe multisig and proxy addresses

A multisig address today is a hash of its members and threshold. Nothing stops that hash from also being a valid classical public key, so in principle a quantum attacker could sign as the multisig directly and skip the quorum. The same applies to pure proxy and derivative addresses.

New **safe** calls in the Multisig, Proxy and Utility pallets derive addresses that can't be classical keys. A safe multisig has a different address from a legacy multisig with the same members and threshold. Legacy multisigs keep their addresses. A multisig is only as quantum-resistant as its weakest quorum.

## Limits

- **Message signing:** ML-DSA and Falcon hotkeys can't sign arbitrary messages or authenticate HTTP requests.
- **Hardware wallets and browser extensions:** they need explicit support for a scheme before they can sign with it.
- **EVM:** stays on ECDSA.
- **Before root switches it on:** funds can be sent to a post-quantum address but not spent from it.

## The switch

Root controls registration and signing for all hashed accounts and all ML-DSA and Falcon accounts through `AdminUtils.sudo_set_hashed_accounts_enabled(enabled)`. The current value is in `AdminUtils.HashedAccountsEnabled`, and it starts off. Switching it off later pauses new registrations and signing for these accounts, but keeps their records. Ordinary Sr25519 and Ed25519 wallets are unaffected either way.

## btcli

```bash
# Standard (fixed-key) post-quantum wallets
btcli wallet create --crypto-type ms           # ML-DSA-65
btcli wallet create --crypto-type falcon512
btcli wallet create --crypto-type falcon1024

# Hashed (rotating-key) mode: add --type hashed
btcli wallet create --crypto-type falcon512 --type hashed

# Recover with the same scheme and mode
btcli wallet regen-coldkey --crypto-type falcon512 --type standard
```

## What it means for Taostats data

- **Signers:** post-quantum and hashed transactions use a `MultiAddress::Raw` signer. Read the first 32 bytes as the account. The signer's length identifies the type.
- **Signature field:** for ML-DSA and Falcon it is a constant marker. Label it, or show the proof from the signer bytes.
- **New pallet:** `HashedAccounts` (pallet index 33). The 0.2 τ registration deposits appear as reserved balance.
- **EVM mapping:** the runtime checks a new `EvmAliases` table before the usual SS58-to-EVM derivation.
- **Multisigs and proxies:** safe addresses use a new derivation, so recomputing a multisig from its members needs to know the mode.
- **Search:** convert a pasted `tao_` address to SS58.
- **Nonces:** a post-quantum account's nonce survives its balance being emptied, so don't treat a reaped account as reset.

Source: [PR #3220](https://github.com/RaoFoundation/subtensor/pull/3220) on the `release-487` branch (`pallets/hashed-accounts`, `runtime/src/hashed_auth.rs`, `docs/guides/wallet-crypto-types.mdx`) · [Quantum-resistant wallets, explained (Rufus)](https://s3.hippius.com/rufus/public/reports/mldsa-wallets-pr3220.html)