Same app - same e-mail - same login method - different wallet/signer

[pedro]

I’d like to report a critical behaviour that I hadn’t observed on Web3Auth up until now.

At least one of our users has encountered a situation in which, using the same authentication credentials, logging in using the same app (therefore the same web3auth app), and the same authentication method, two different wallets resulted. What turns this into a more critical situation is that the user deposited funds onto the first wallet that was generated. Now it is seemingly impossible to obtain this address, even using the same authentication method, as another wallet address has taken its place whenever the user logs in. Multiple attempts have been made using the same authentication method.

The app uses the default verifier.

Please help me with the following points:

• Why has this happened, and is there any possibility that this situation repeats in the future?
• How do I instruct the user to recover funds from the first wallet? Can the private key to the first wallet be exported? Is there any other way to otherwise force a login with the first wallet?

I appreciate the expedited attention this issue deserves.

[maharshi]

Hi @pedro, thanks for reporting this. I will take this up to the team and will let you know once I have something.

[pedro]

Thanks so much, @maharshi.

Also, after perusing the community, though the steps taken by the user are different, the end result is eerily similar to the following topic:

User logging into account with social shows the wrong wallet address

@gareth Welcome Aboard! Web3Auth accounts are scoped to applications (clientId) which generate different wallet addresses. The other reasons are: Different verifiers being used Different client ids Different social logins (email passwordless and google is not same) Torus wallet accounts are different from Web3auth accounts. You may refer to the below documentation to learn more:

[maharshi]

Now that you mention this, I would like to ask you to go through this doc. These are different cases where the wallet addresses may change. Please let me know you are mindful of these, since there are a variety of reasons for the wallet addresses to change.

[dev15]

It may be relevant. Now I came across the situation that the EOA obtained from https://dashboard.web3auth.io/
is different from what I used to.
And it is affecting all of my clients right now.

[pedro]

Hi @maharshi , thanks for pointing out that document, it’s an excellent refresher. Going through each point:

• We use a single Plug and Play project.
• The project uses the default verifier – we do not have custom verifiers.
• It’s configured to the mainnet.
• Our app allows authentication using Google and passwordless e-mail (tkey-google and tkey-auth0-email-passwordless verifiers, respectively). We do not use the modal UI, and our custom UI only enables Google and passwordless e-mail authentication.
• Due to supporting only two authentications, each e-mail is only able to have two associated wallet addresses. We have several users who logged in using Google and passwordless e-mail and therefore have two different wallets.
• What happened in this case, however, is that a single user has three different wallets associated to one e-mail – which is supposed to be impossible if we are only interacting with two separate verifiers.

Perhaps checking out how our authentication process works will illuminate your understanding of the problem. Here is the link to our app: https://picnicinvestimentos.com/

Once again thanks a lot for your help.

[joao]

@maharshi and team, could you please give us some feedback here?

This is an expensive error that we are responsible for.

[joao]

We lost money (already reimbursed the client) because of an error that in all likelihood was caused by Web3Auth.

I understand that it might be a difficult issue to debug, but it would be appropriate to at least get some feedback that the issue was understood and is being handled.

[pedro]

Hi @maharshi ,

As @joao explained, given the seriousness of the issue, I’d also really appreciate an explanation. It’s been 5 days since initially reported and we’ve covered for the user’s loss with company funds.

It seems to me that it should be in Web3auth’s best interest to understand what happened in order to improve its product. If it’s not in web3auth’s interest, I must emphasise that it is our duty to understand what happened. The real reason is not to recoup financial loss; we’ve already settled that these funds are lost, but we’d like to understand what could have happened.

[maharshi]

@pedro Sorry for the delay. Although, there could be any of the multiple reasons for the change in wallet addresses but if you have verified according to the docs that those were not the possible causes for the change of addresses, then it could have happened due to the migration which was a one-time activity for better long-term experience of the users.