As far as I understand, besides the ed25519 and sr25519 signatures, there is a compatibility mode for ECDSA keypairs that should use the secp256k1 curve.

non-compatible keys

Both Bitcoin and Ethereum use the secp256k1 curve parameters for their accounts and signatures. But how do the Substrate ECDSA keys differ from Bitcoin/Ethereum keys? Why are they not compatible?

2 Answers 2


The process of how the private keys are derived is slightly different. This applies to both the how the (parent) key is generated and then subsequent derivations on this.

In BTC/ETC and most (all other) blockchains, when you enter the mnemonic, it normalized that and then does the pbkdf2 rounds on it. In Substrate, the mnemonic is first taken to entropy before the pbkdf2 rounds are applied. This means that the same mnemonic will yield 2 different private keys in the Sustrate vs other blockchain projects.

On top of this, you have the derivation, which is also different, the HD paths vs the Substrate paths.

Having said all this, there are some wallets (most notably those supporting multi blockchain currencies) that uses their "normal ed25519/secp256k1" keys on a Substrate environment. So one you have a key and can sign, it doesn't matter. The difference is rather how you get to the key.

As a note, when connecting to an ETH-compatible chain, e.g Moonbeam, the apps UI does give an option to use ETH-standard mnemonic -> seed as well as the ETH standard derivation paths.

  • I see. So if I select private key instead of mnemonic and select ECDSA, it should be compatible because it's skipping the derivation step?
    – q9f
    Commented Apr 8, 2022 at 13:30
  • 2
    100% - it is just incompatible derivation steps that is at play here.
    – Jaco
    Commented Apr 8, 2022 at 13:48

In Substrate related blockchains the account id is derived from the public key using SS58 encoding. See here: https://docs.substrate.io/v3/advanced/ss58/

  • Thank you. I'm aware of SS58 encoding. But what prevents me from using the same private key for Bitcoin, Ethereum, and Polkadot?
    – q9f
    Commented Apr 8, 2022 at 12:46
  • At the end of the day a secp256k1 private key is only a 256bit integer. Thus, as is, a "raw" private key is not bound to any blockchain, is just a number. I think that the dialog in your post is suggesting you that the AccoundId (i.e. encoding of the public key) is not compatible with the other blockchains because of the encoding. Commented Apr 8, 2022 at 12:54
  • My question stems from the screenshot of PolkadotJS that says: ECDSA (Non BTC/ETH compatible. Sorry, I should have been clearer.
    – q9f
    Commented Apr 8, 2022 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.