I’m currently integrating the Web3Auth MPC Core Kit and have a question regarding the support for account index with the ed25519 curve. I would appreciate some clarification on the following points:
Why does the ed25519 curve not support account index?
Is this a technical limitation, or is it something that hasn’t been implemented yet?
Are there plans to support account index with the ed25519 curve in the future?
If so, when might we expect this feature to be available?
If this feature is not currently planned, we are considering implementing it ourselves. Any guidance or support you could provide would be highly appreciated, especially in terms of best practices or collaboration opportunities.
Looking forward to hearing from the Web3Auth team or the community.
Hi Jiawei — thanks for the clear questions, and great that you’re digging into the MPC Core Kit. I’ll summarize the likely causes and options so the Web3Auth/MPC team can pick this up quickly.
Question: Why ed25519 doesn’t support account index, are there plans to support it, and guidance if you want to implement it yourself.
Short answers
Why ed25519 doesn’t (commonly) support account index
This is usually a technical limitation, not just an omission. Unlike secp256k1/BIP32 where non-hardened child derivation allows deriving child public keys from an extended public key, ed25519 uses SLIP-0010-style derivation which is effectively hardened-only. Hardened-only derivation prevents deriving child public keys from a parent public key alone, which complicates the typical “account index” UX (derive multiple accounts from one extended public key) and also complicates MPC workflows that rely on pubkey-only operations.
In MPC specifically, producing independent account keys per index requires deterministic, compatible derivation of the shares. That’s more complex with ed25519 because you cannot use the same non-hardened derivation strategies used for BIP32/secp256k1.
Plans to support it
I don’t have visibility into the Web3Auth roadmap from here. If you need an authoritative timeline, I recommend opening a feature request or issue with Web3Auth (GitHub) or asking the Web3Auth team directly in their support/discussion channels so they can confirm whether they plan to add account-index support for ed25519.
Helpful links to contact the Web3Auth team or track a feature request
If you want to implement it yourself — guidance & best practices
Approach options
Hardened-per-index derivation (SLIP-0010): Use a hardened derivation path per account index (e.g., m/44’/coin’/account’) — this is compatible with ed25519 but means you cannot derive child public keys from a parent XPUB, and each account requires private material for derivation.
Deterministic share derivation at MPC layer: Keep a single master secret share and deterministically derive per-index shares (e.g., use an HKDF/KDF with the index as info to derive a new seed per account index, then run your MPC keygen from that seed). This keeps everything deterministic while isolating indices, but must be designed so shares cannot be combined to leak other indices.
Best practices
Use hardened derivation semantics (or a KDF/HKDF) so you don’t accidentally expose private key material via public derivation paths.
Keep index metadata and derivation path/versioning in on-chain or local storage so you can recover accounts and handle upgrades.
Test cross-client signature compatibility (some ed25519 variants differ in encoding/serialization).
Get a cryptographer review for any custom MPC/derivation scheme before production use.
Implementation notes (high level)
Decide whether you derive per-index seeds outside MPC and then run MPC keygen for each index, or derive per-index key material inside the MPC protocol.
If deriving outside MPC, securely derive seeds with HKDF(master_secret, index) and then instantiate MPC keygen using the derived seed.
If deriving inside MPC, ensure the protocol supports deterministic, independent share derivation without weakening threshold security.
What I can do next / what would help the team
If you’d like, I can help draft a small feature request template you can paste into Web3Auth’s GitHub issue (include the use case, expected behavior, and any compatibility constraints).
If you plan to implement this yourself and want feedback, sharing which MPC Core Kit version you’re using and whether you’re implementing on web/native would help (no need to share code yet). Otherwise the Web3Auth team will likely ask for that.
Thanks again — this is a very reasonable question given ed25519’s derivation behavior. If you want I can draft an issue description for Web3Auth for you to submit. Would you like that?
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours
The use of MPC Core Kit is limited to legacy enterprise customers. No new developments are going on that product. If you are an existing enterprise customer on this, please let our team know of your dedicated chat, we will be accordingly servicing your needs.