Should IdToken be unique between Solana and Evm Instance?

Help - Core-Kit MPC Core Kit SDK
1

Hi Web3Auth Team,

I’m currently integrating both EVM and Solana wallets using your MPC Core Kit, and I’m using different TSS libraries:

  • @toruslabs/tss-dkls-lib for EVM (DKLS)
  • @toruslabs/tss-frost-lib for Solana (FROST)

I want to clarify the correct handling of tokenId and verifierId when initializing both instances for the same Google account.

Based on testing and documentation, my current understanding is:

  1. tokenId (Google id_token) must be different for each TSS instance (i.e., one for DKLS and another for FROST), otherwise I get a “duplicate share” error.
  2. verifierId can remain the same (e.g., the user’s email) across both instances, since the TSS libraries have different internal tssTags to distinguish key shares.

Could you please confirm if this is the correct and recommended approach when using MPC-TSS across chains?

Thank you so much in advance!

2

Thank you for your detailed question and for outlining your integration approach!

Summary of your setup:

  • SDK: Web3Auth MPC Core Kit (v3)
  • TSS Libraries:
    • @toruslabs/tss-dkls-lib for EVM
    • @toruslabs/tss-frost-lib for Solana
  • Authentication: Google (OAuth), same Google account for both chains
  • Question:
    • Should the idToken (Google id_token) be unique for each TSS instance (EVM/Solana)?
    • Can the verifierId remain the same for both?

Clarification & Recommendation

1. idToken (Google id_token)

  • Correct: You need to use a fresh/unique idToken for each TSS instance (DKLS for EVM, FROST for Solana).
  • Reason:
    • Each TSS instance (even for the same user) creates a new key share and expects a new authentication flow.
    • Re-using the same idToken across instances can lead to “duplicate share” errors, as you observed.
    • This is because the backend expects a unique authentication proof for each key type/curve.

2. verifierId

  • Correct: The verifierId (typically the user’s email) can remain the same across both instances.
  • Reason:
    • The underlying TSS libraries (tss-dkls-lib and tss-frost-lib) use different tags and key types, so the shares are stored and managed separately.
    • The verifierId is just the identifier for the user, not the key type.

Documentation Reference

Summary Table

Instance TSS Library idToken (Google) verifierId (email)
EVM (secp256k1) @toruslabs/tss-dkls-lib Unique Same
Solana (ed25519) @toruslabs/tss-frost-lib Unique Same

You are following the correct approach.

  • Always generate a new Google idToken for each login/init per TSS instance.
  • Use the same verifierId (email) for both.

If you need more implementation details or run into issues, feel free to share your initialization/login code snippets or any error messages/screenshots for further assistance!

Let me know if you have any other questions or if you need sample code for this flow.

Note: This response was generated by an AI bot and may require further verification. The Web3Auth support 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. Web3Auth Developer Office Hours

3

please help me confirm :pray: @TomTom