Polkadot Standards Proposal (PSP) to define Hierarchical Deterministic (HD) key derivation paths

Continuing the discussion from Polkadot Vault (former Parity Signer) derivation paths.

I think that as more and more awesome ecosystem wallets come online a Polkadot Standards Proposals (PSPs) that defines a derivation path standard for our ecosystem with detailed rational as to why we do that ala BIP44 and SIP44 is called for.

What I presently see as “Standards”:

  • https://github.com/satoshilabs/slips/blob/57f96e37a4a4afba71f2b9f67b85be19610b0dfb/slip-0044.md defines Kusama and Polkadot derivation paths, that AFAIK have never been used in wallets.
  • //<network name> and aldo //<network name>/<incrementing number> in prior iterations of Vault and perhaps the Polkadot extension wallet at least at one point was the default derivation path for any wallet created.
    • In the context of the Academy I put together a small subkey demo that follows the “standard” as I understood them via an older version of the docs on that CLI tool.
  • I think an (unspoken/undocumented?) standard is now the account being the root key without any derivation at all. It is in subkey now for example.
  • Our SS58 registry is effectively SLIP44 for Polkdot AFAIK, but also I am not sure it’s really understood how to use and why it’s needed to have the same keys map to different accounts by end users very well, including me :sweat_smile: .

With all wallets defining how to handle derivation path defaults ad-hoc, I doubt any strong interoperability would be possible. IMHO compatibility/portability for our wallets with the same secret recovery information by default would be a a big win for everyone. For example ledger cannot interoperate with other wallets quite sadly for an semi-related reason, and users hate that interoperability isn’t possible when they want/need it.[1]

Would you desire and support a PSP to define a standard?

  1. Of course the security implications of migration need to be considered, but not what is demanded by users in my experience, including me. ↩︎


They are used by Ledger.

It’s not, because SLIP44 defines derivation paths and SS58 defines prefixes (which do not have any effect on the account, only the display format).

This is because of BIP39 seed derivation, and not derivation paths, as the Wiki link you included explains.

I wrote a suggestion quite a few years ago; pretty sure it was on the wiki but doesn’t seem to be there now.

Having had to muddle with dozens of scraps of paper for various seed phrases over the years, I am 100% against using the root key (i.e. the secret key immediately derivable from the seed-phrase) as an account. I have not used any software which has attempted to standardise this, but I would send a clearly worded piece of correspondance to any ecosystem teams if I did see it. To be perfectly honest, I think the basis of what we had in Signer v4 was fine; the biggest issue was forming a convention on exactly what path should be used to create the account (or accounts) for any given network.

I would propose a few:

//network: Primary high-security account for network, named according to the network’s chain spec.
//network//0, //network//1, …: Secondary high-security accounts for network.
//network//pub: Primary high-security public account for network (i.e. one which the user is happy to be associated with their “real” ID).
//network//hot: Primary low-security account for network (e.g. one whose secret key the user exports from the Vault to carry on an internet-connected device).

Realistically, simple wallets might only expose their user to the first of these, but if the standard is used then the seed phrase can be exported between wallets and will readily work.

I see no great need to have different seed phrases for different networks; indeed as we move into having thousands of chains and the distinction between a “network” and a “contract” becomes increasingly blurred, then I think it will become obvious that just as we will tend to store all seeds on a single device, we will branch all keys off a single seed.

As for Ledger I fear it’s just not a device which is well-suited to Polkadot in general with its upgradability, different chains and transaction types. It’s designed largely for Bitcoin clones and works reasonably for that use-case. It’s definitely not a great fit for general Web3 usage and while there’s an argument to be made in favour of pan-industry standardisation, I’m not super convinced about straightjacking the ecosystem with a Bitcoin-centric standard.


Here’s a hackmd with the above in it. Polkadot Key Derivation Paths - HackMD


@bjorn @joepetrowski , Gav, Eva & Josh - Bjorn Markus Jakobsson & Kier Finlow Bates appear to be submitting blanket patent applications. I would imagine a lot of the work infringes on Parity Technologies’ contributions to the space. It is overwhelming how many they are submitting in quick succession. Probably enough to hinder adoption unless counterclaims are made.

  1. Bjorn Markus Jakobsson Inventions, Patents and Patent Applications - Justia Patents Search
  2. Keir Finlow-Bates Inventions, Patents and Patent Applications - Justia Patents Search

I must have missed this when it was first posted in May. I added an issue to add Gav’s suggested derivation path standards to the Wiki here: Add derivation path standards · Issue #5413 · w3f/polkadot-wiki · GitHub

Thanks a lot for the write up!

There is one thing that I don’t quite understand, though:

Root-Public key should be shown in UI as an SS58 with a prefix index of 1 (BareSr25519) or 3 (BareEd25519) - depending on crypto used.

What’s the purpose of displaying the root public key in the UI?

It’s clearly not for receiving funds, correct? So, is it so that the user can sign data with the “Root Secret” and then provide the Root-Public key to verify the signature?

I’m clearly missing something in here. I would really appreciate some guidance on this :pray:

The public root is what identifies the hierarchy. If you’re ever moving accounts between devices or restoring an old account tree, then it’s there to confirm that you’re putting in the right seed phrase.

It’s not (or at least shouldn’t be) an account itself, so it should use a neutral SS58 prefix and identicon.