Wallet Address Change

I have a user on our testing environment (which runs on Sepolia and Arbitrum Sepolia) who initially signed up via email in December 2024. At that time, their wallet address was:

0xF0af42ceAb4c4e4694DbB5469337B9Ca3c20Cc9A

However, a few days ago, after signing in again, the same account returned a different wallet address:

0x7bbF3435fe7498Ad2f2EcC25f3d16380939B0876

I checked on Etherscan, and here’s what I found:

• 0x7bbF3435fe7498Ad2f2EcC25f3d16380939B0876 → 0 transactions (Etherscan link)

• 0xF0af42ceAb4c4e4694DbB5469337B9Ca3c20Cc9A → Has transactions (Etherscan link)

Has anyone encountered something like this before? Could there be an explanation for why the wallet address changed upon signing in?

Hi Felipe,

Thanks for reaching out to us with your concern.

It seems like you’re experiencing an issue where a user’s wallet address changes after signing in. This typically shouldn’t happen unless the method of key generation or some configuration changes between sessions. Here are a few things to consider that might help diagnose the issue:

  1. Web3Auth Initialization Configuration: Ensure that the initialization parameters haven’t changed for the user’s second login. Changes in the key derivation method, such as using a different verifier, could potentially lead to this. Could you share any code snippets related to how Web3Auth is initialized in your app, specifically for the email login?

  2. Testing Environment Details: As you mentioned using Sepolia and Arbitrum Sepolia, ensure these environments are configured consistently across both sessions. Any discrepancies here could potentially lead to different addresses being provided.

  3. Verification Process: Double-check if the verifier settings (if you are using a custom verifier) are consistent. Changes here could also impact the wallet address.

  4. Recent Changes: If there were any recent updates in your app or the Web3Auth SDK, these might affect behavior. Keep an eye on Web3Auth’s changelog for any breaking changes.

  5. JWT and JWKS (if applicable): If you’re using your own authentication mechanism, there might be a setting affecting how the keys are being derived.

This information will help us better understand the context and guide you more accurately. If the issue persists, please ensure all of the above settings are consistent across sessions. If there’s anything specific you notice during initialization or the login process, feel free to share more details!

Best,
[Your Name]

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

There was no change in the verifier.

These were the SDK versions back in December:

"@web3auth/auth-adapter": "^9.3.0",
"@web3auth/base": "^9.3.0",
"@web3auth/default-evm-adapter": "^9.3.0",
"@web3auth/ethereum-provider": "^9.3.0",
"@web3auth/no-modal": "^9.3.2",
"@web3auth/wallet-connect-v2-adapter": "^9.3.0",

And now:

"@web3auth/auth-adapter": "^9.5.4",
"@web3auth/base": "^9.5.4",
"@web3auth/default-evm-adapter": "^9.5.4",
"@web3auth/ethereum-provider": "^9.5.4",
"@web3auth/no-modal": "^9.5.4",
"@web3auth/wallet-connect-v2-adapter": "^9.5.4",