Social Verifier Migration

Help - Plug n Play
1

Hello,

unfortunately a verifier got lost and I can’t add it as it seams to be already deployed. We run multiple “buckets” and it is just on one. As web3auth makes it really hard to reach support - how can I get into contact with someone manually resolving / connecting a deployed verifier with an app?

2

Hi Florian, thanks for reaching out and providing context!

Summary of Your Issue:
You’re running multiple “buckets” (projects/apps) and have a social verifier that appears to be “lost”—it’s already deployed, but you can’t add or connect it to your current app/bucket via the Web3Auth dashboard. You’re looking for a way to manually resolve this and connect the deployed verifier to your app, but haven’t found a support channel for this.

Details for Support Team

  • SDK: Web3Auth Plug n Play (PnP)
  • Platform: Web (exact framework not specified, but likely using the Modal SDK or No-Modal SDK)
  • Issue: Social verifier is already deployed (possibly under a different project/bucket), but cannot be linked or migrated to the current app/bucket.
  • Migration Context: User is aware of v9/v10 migration and dashboard-centric configuration, but this is a manual linking issue, not a code migration problem.

Next Steps / Suggestions

This is a dashboard-level, account-specific issue that requires manual intervention from the Web3Auth team. Unfortunately, verifiers are unique and can only be linked to one project at a time; if a verifier is “stuck” in another bucket or project, only internal support can reassign or merge it.

What you can do:

  • Please provide the following (if you haven’t already, or if support requests it):
    • The name of the verifier you’re trying to add
    • The app/bucket/project IDs involved (source and destination, if known)
    • Any error messages or screenshots from the dashboard when you attempt the action

Manual Support:
Web3Auth support typically handles these requests via their contact form, or you can email support@web3auth.io referencing this forum post for context. Please include the details above for faster resolution.

Reference:

You don’t need to provide code snippets or SDK logs for this issue, as it’s related to dashboard configuration and account management.

Let us know if you need help drafting your support request, or if you have additional details to share!

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

Hey @florian.bergmann
You’ve reached the right place for support.
I would love to know more details on this. Can you please explain what do you mean by your verifier getting lost?

4

Hi, unfortunately I haven’t received any feedback on my support email for two days after the initial reply.

As a client of over three years with an urgent matter, this is disappointing. By “getting lost” I mean: we’ve been using early versions of Web3Auth for years, but with the latest update, verifiers are now always loaded from the backend. The issue is that the “old verifier” we used during initialization in the JS code doesn’t appear to be linked to the correct account (since we manage multiple).

This could represent a significant security concern, which might explain the rapid SDK updates. I’m happy to discuss the details further in the support email so we can resolve this properly.

5

We don’t provide email as a support channel for Basic, Growth, or Scale plans — our official support for those tiers is here on the Web3Auth Community. Enterprise customers get access to dedicated Slack/Telegram groups.

Frequent SDK updates don’t automatically indicate security flaws. Like any evolving tech, Web3Auth continues to ship improvements and standardizations across platforms. Yes, vulnerabilities can surface — but fixing them quickly and moving forward is what ensures end-user safety. Staying on legacy versions is a bigger risk than updating.

To look into this further, please share:

  • The verifier name
  • The client ID you expect it to be linked to
  • The Web3Auth network parameter you’re using

That info will help us pinpoint what’s happening and guide you to a resolution.

6

So the only way to receive support for this issue is to post credentials and details about our project that could be lead to exploit the actual concern? chapeau…

I received a reply on my first E-Mail earlier this week. I haven’t received a response after providing the requested details. This silence leaves the impression that the issue may have revealed a deeper problem you’re working on internally - which makes clear communication even more important.

However, maybe this helps to understand why I also would recommend to remove this thread and try resolving it by email: My main concern is understanding how it was possible to use a verifier with a client ID from a different account. From my analysis, it seems that:

  • The client ID was primarily used as a billing entity and to restrict allowed URLs.
  • The verifier, however, did not appear to be bound to these restrictions.
  • This would mean that anyone could have used the verifier on any domain, trick users into connecting, and export private keys outside the intended domain.

In SDK v10 this issue appears to be resolved, as the verifier part has been removed.

Could you please provide a resolution and a clear explanation of why this was possible in earlier versions? Transparency here is critical, as it concerns potential misuse of private user data.

Hint: An E-Mail reply doesn’t hurt…

7

The issue was resolved by using the connectTo workflow as described in this guide. In our case (we assume), the standard flow failed because the verifier was linked to a different account than the project ID. The Web3Auth team confirmed that this setup is not a security risk.

Looking forward to the upcoming Web3Auth → MetaMask embedded wallet migration, along with a more consistent developer experience and up-to-date documentation.

Thanks to everyone who helped in getting this resolved.

1 Like
8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.