Suggestions for Key Derivation Paths

SS58 supports a rich key derivation path system, allowing hard and soft derivation from both indices and arbitrary length text at each junction.

Here's an example of how we manage their keys in practice that might help inform your choices for path organisation.

Root

We begin with a root phrase P, generated in the usual means, perhaps through subkey or Polkadot JS Apps (though there are many wallets and key management system that support SS58 now). P is not used directly, we assume it is a paper wallet and that the secret for it is kept on a cold wallet device like Parity Signer.

Network/Chain

The first junction point is for the chain or network. We typically keep a single path for a "network" even though there may be several candidate chains (as was the case in Kusama, for example). This is always a hard derivation.

We call this the Network Root, which should not be confused with the Root, at the level above.

Public

Following this, we immediately branch into keys that we want to be public using a hard derived path pub. All keys beyond this path will use soft derivation. This address may be published to allow others to determine and verify typical public keys.

Typical sub-paths off of //pub include:

• /id: The main public identity of the individual/organisation.
• /technical: The Technical Committee member identity/-ies of the individual/organisation, if different to /id.
• /council: The Council member identity/-ies of the individual/organisation, if different to /id.
• /1, /2, ...: The general public accounts of the individual/organisation for asset management and other activities that use multiple fungible accounts.

Hot

It may be useful to have a separate set of hot wallets since the private key may be derived and placed on a hot device such that the secrets can be derived from P in case of loss, and yet the cold root phrase is never compromised by being present on the hot device.

These wallets are derived from a hard path //hot. Right now the only way of moving this from a cold device is to use subkey on a cold device:

> subkey inspect "P//polkadot//hot"

And then manually copy the secret seed into the hot device. Support for importing derived secret keys from Parity Signer into Polkadot JS Apps is planned.

Hot Public Paths

Public keys (including, e.g., identity) may alternatively be derived from the //hot//pub path instead of the cold //pub path. Which is chosen depends on your risk appetite. For some users on some chains, it may be desired to have the main identity key be on a hot device. For others, it may be unacceptable. We have found both variants useful under different circumstances.

General/throwaway Accounts

General accounts used for asset management and other throwaway uses will generally be derived from the Network Root as //1, //2.

Examples

• P//polkadot//hot//pub/id: Hot public identity for Polkadot mainnet.
• P//kusama//pub/technical/2: Cold second tech committee identity for Kusama.
• P//polkadot//1: First cold throwaway account for Polkadot.
• P//kusama//hot//mobile//10: Tenth throwaway/general purpose account on a (hot) mobile device for the Kusama network.