Finding: for Ed25519 and ECDSA account creation, AddAccount stores the Sr25519-derived public key, but the exact getKeypair call the UI makes throws “Soft derivations are not supported”, because the shipped path contains a soft segment the ed25519 and ecdsa HDKD rejects. I executed the exact AddAccount and getKeypair call sequences at the pinned checkout: the Sr25519 control matches, and both Ed25519 and ECDSA throw.
Impact, corrected: the account cannot sign at all, so funds sent to the displayed address are locked there. The creating user is the victim; no attacker is needed.
Suggested fix: derive per scheme, or restrict the creation selector to Sr25519 until the other schemes are supported.
Location: AddAccount dot tsx line 64 declares the scheme enum with Sr25519, Ed25519 and Ecdsa, and the form stores the user selection. Line 93 in onSubmit always builds the derive function with sr25519CreateDerive and the mini secret, regardless of the selected scheme. Lines 95 to 102 build every derivation path entry and every stored public key from that Sr25519 derive function. Lines 104 to 111 insert the keyset with scheme set to the user selected scheme. Creation ignores the selected scheme while storage preserves it.
Later, keyring dot ts lines 27 to 31 define createDeriveFnMap mapping each scheme to its own derive function. Line 309 starts getKeypair, and line 342 selects createDeriveFnMap by the stored scheme. So derivation at signing time honors the stored scheme while creation did not.
Executed comparison at the pinned checkout, hdkd 0.0.11, node 24, the exact AddAccount and getKeypair call sequences, fixed test mnemonic, shipped path shape:
Sr25519 control: stored public key 0x76136fa9b874abd4b46f171000d00363337f59b87adff71cee77d6998765a16d, getKeypair derives the identical value. Match.
Ed25519: stored key is the same Sr25519 value above. The exact getKeypair call with ed25519CreateDerive throws “Soft derivations are not supported”. No keypair produced at all.
Ecdsa: stored key is the same Sr25519 value above. The exact getKeypair call with ecdsaCreateDerive throws the same error. No keypair produced at all.
Impact: the account cannot sign at all. Funds sent to the displayed address are locked there, because both signing entry points in createBackgroundRpc dot ts call getKeypair before signing, so the throw blocks the transaction path and the payload signing path. The creating user is the victim; no attacker is needed. Import fails closed for these schemes, creation fails open, which is the divergence.
Suggested fix: derive per scheme at creation, or restrict the creation selector to Sr25519 until the other schemes are supported.
Are you talking about the extension? If so, it will be heavily updated in the coming week. One more thing: only sr25519 will be used going forward because of the new design, so I believe your issue will be resolved automatically.
Hi. Yes, this is the extension. The finding is at the pinned commit: AddAccount always derives with sr25519CreateDerive regardless of the selected scheme while storing the user’s scheme choice, and getKeypair later dispatches on the stored scheme — so Ed25519 and ECDSA accounts are created but can never sign.
Understood on the redesign going sr25519-only. Until that ships, the creation selector still offers Ed25519 and ECDSA, and any account created under those schemes today locks funds at an address nobody can sign for. Restricting the selector to sr25519 in the interim would close it.