End User Wallet Recovery

Embedded Wallets (Web3Auth)
1

I am an end user attempting to recover a historical embedded wallet created through a now-deprecated Slingshot Finance or SlingshotDAO application. I do not possess the application’s source code, SDK configuration, logs, or package manifest. I am trying to determine whether this wallet was created using Web3Auth/MetaMask Embedded Wallets and, if so, what historical authentication configuration must be reproduced to derive or recover the same wallet.

1 Like
2

We can’t determine from a wallet address alone whether Slingshot Finance or SlingshotDAO built their wallet on MetaMask Embedded Wallets (Web3Auth), and we can’t reconstruct the historical authentication configuration without the project’s records.

For an Embedded Wallets wallet, recoverability is determined by the original authentication path — not by the blockchain address:

  • Built-in social login under the app’s client ID: the wallet key is derived from that same login (same provider, same account). The project must still offer that login, or its operators must re-enable it or provide an export path. We can’t sign you into the app on its behalf.
  • Custom authentication: if Slingshot used a custom verifier, its own JWT issuer, or a configured identity provider, that authentication belongs entirely to the project. We do not hold its issuer or verifier, and we cannot reproduce the login or restore the wallet on the project’s behalf.
  • MFA: if you enabled MFA on that wallet, additional recovery factors (device, backup phrase, security question, etc.) may be manageable from the Embedded Wallets User Account Dashboard. If MFA was never enabled, there is no separate recovery factor to fall back on — the original login is the only path.

See the User Account Dashboard docs for what end users can manage (recovery factors, devices, connected apps) and for the dashboard link. If no authorized application appears there for the login you used, that points toward the wallet having been created under the app’s own client ID or custom verifier rather than an account-linked authorization — i.e., the custom-authentication case above.

To look at your specific case, please reply with: (1) the exact Slingshot project name and the historical URL you used, (2) the login method (Google, email, Discord, wallet, etc.), (3) the public wallet address, and (4) the client ID or verifier name, if you happen to have it. Do not post a seed phrase, private key, password, OAuth token, or recovery code — we will never ask for those, and anyone who does is trying to scam you.

In parallel, the most practical step is to reach Slingshot’s operators directly: only they can confirm the client ID or verifier name, re-enable the original authentication route, or run an export if their application controlled one. Post what you find back here and we’ll help interpret it.

Sources

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.

3

  1. Project: Slingshot DAO

  2. Main site: https://slingshotdao.com

  3. Historical dApp: https://app.slingshotdao.com

  4. Provider: Web3Auth

  5. Wallet type: self-custody MPC wallet

  6. Authentication: social login

  7. Additional security: users were prompted to configure 2FA/MFA

  8. Approximate target-wallet activity: April 16, 2025

  9. Target: 0x90FAD3b9fC325bEe151B65d37FEAB7b1030bA2f0

    I do not yet know:

    • The Web3Auth client/project ID
    • The Web3Auth network
    • The verifier name or type
    • The social provider used for this particular wallet
    • Whether MFA was configured

    Given the documented Web3Auth integration and the domains above, can MetaMask identify or internally escalate to the historical SlingshotDAO integration owner and determine the client ID, network and verifier name? If you cannot disclose those values directly, can you contact the registered project operator or confirm which information they must provide?

    Can you also confirm whether logging into the User Account Dashboard with each candidate social identity would reveal MFA factors or connected applications created under this SlingshotDAO integration?

4

We’re not able to identify SlingshotDAO’s historical client ID, network, verifier, or registered integration owner from the wallet address, domains, or activity date, and we can’t contact or escalate to a project operator on a user’s behalf. That information is project-scoped configuration and historical record — only the SlingshotDAO operators can confirm it.

The key to recovery is the exact original authentication route. Knowing only “social login” plus an MPC/self-custody wallet isn’t enough to identify the provider or verifier used for 0x90FAD3b9fC325bEe151B65d37FEAB7b1030bA2f0. A different social provider — or even a different account with the same provider — derives a different wallet entirely.

Please ask the operators of https://slingshotdao.com to provide or confirm:

  1. The Embedded Wallets/Web3Auth client ID.
  2. Whether the deployment used Sapphire Mainnet or Sapphire Devnet.
  3. The verifier/connection name and type (built-in social vs. custom JWT issuer).
  4. The exact social provider and account identity associated with this address.
  5. Whether that login route can be re-enabled, and whether they can offer an export/recovery path.
  6. Whether MFA was enabled for this user, and what recovery options the app supported.

In the meantime, on the User Account Dashboard, you can try signing in with each candidate original social identity — use the dashboard link on the User Account Dashboard docs, which also explains what end users can view and manage (recovery factors, devices, security/MFA, connected apps). A few caveats:

  • If the correct identity shows SlingshotDAO as a connected/authorized application, that’s useful evidence tying the identity to that integration, and any MFA factors shown are the factors available to that signed-in account.
  • If no authorized application appears, that does not prove the wallet doesn’t exist. It more likely means the wallet was created under the project’s own client ID or a custom verifier — in which case the project itself must restore or confirm the original login path, since we can’t reproduce a project’s verifier or token issuer.
  • If MFA was never configured for this account, there’s no independent recovery factor, and the original login remains the only path back in.

The dashboard is a tool for end users to manage their own accounts — it isn’t a discovery tool for reconstructing SlingshotDAO’s project configuration.

Please don’t share a seed phrase, private key, password, OAuth token, or MFA/recovery code here or with anyone — we will never ask for them, and anyone who does is trying to scam you.

If SlingshotDAO supplies the client ID, Sapphire network, verifier/connection name, and original provider, post those non-secret values back in this thread and we’ll help you interpret whether they point to a viable login/recovery route.

Sources

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.

5

This is a deprecated project. It shut down. Does the User Account Dashboard still allow the derivation pathway used by projects that integrated custom interfaces but no longer pay their bills derive the proper wallets?

6

No — the User Account Dashboard can’t reconstruct a shut-down project’s integration configuration, and it can’t independently derive or sign into a project-created wallet. Whether the original wallet is still reachable depends on the authentication path SlingshotDAO configured, not on whether the project is still paid up or active.

  • Built-in social login under SlingshotDAO’s client ID: the wallet is deterministically tied to that original login, but a working login flow still has to exist. We can’t sign a user in on a project’s behalf, so the project’s operators would need to restore login or provide an export path.
  • Custom authentication (custom verifier, SlingshotDAO-issued JWT, or a project-configured identity provider): the verifier and token issuer belong to the project. We don’t hold them and can’t reproduce that authentication or restore the wallet once the project is gone.
  • No MFA/recovery factor set up: there’s no separate factor available as an independent recovery route.

The User Account Dashboard only helps once you can already authenticate to the account — it isn’t a discovery or wallet-reconstruction tool. Details: User Account Dashboard | MetaMask developer documentation

To work out which case applies, please reply here with: the SlingshotDAO app URL, the login method you used (for example Google, email, or a SlingshotDAO account), the public wallet address, and the client ID or verifier name if you have it. If the user account dashboard (https://account.web3auth.io) shows no authorized app for that login, that points to an app-owned client ID or custom authentication rather than a path we can recover independently.

Please don’t share a seed phrase, private key, password, JWT, or recovery code — we never need them. Only SlingshotDAO’s operators can re-enable the original project login if that authentication path still exists.

Sources

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.

7

I recovered the configuration from SlingshotDAO’s archived April 2025 JavaScript:

Client ID: BJKCIoPMW834sLeBMIS5S-lk0YmrOo8Ld2CXPs5IhjmayxFpkiyqPjNsjeQKS6Iu0csQ6zk_zSe9Ehu1T3rzUOc
Network: sapphire_mainnet
Historical origin: https://app.slingshotdao.com

Web3Auth’s public configuration endpoint still recognizes the project, lists that origin, and reports key_export_enabled: true. The archived application also includes an eth_private_key/getPrivateKey() export path.

Can you now identify the project’s supported built-in auth connections or confirm whether its login configuration used a custom verifier? If this remains project-only information, please specify exactly what the operator must restore in order to initialize this existing client without creating a different wallet.

8

@system Should I wait on another AI reply or expect something else?

9

Hi @Andy2 please wait for reply from the team - I’m sharing this internally

10

No problem, thank you for responding.

11

@shana Could you tell me how what is the typical team response time please and how they will reach out?

12

Any guidance on timing? @shana @system

13

Hi @Andy2 I’ve notified the team someone should get back to you soon

14

Ok I will be here. Thanks

15

Hey Andy

Did you try to contact Slingshot DAO? Unfortunately it seems they were using some custom login system and using web3auth to just generate key. We do not have access to their login system to be able to generate your account. Unless they set up a way for key recovery, being a non custodial system, it is impossible for us to make a way for you to recover back the key.

16

Hey @yashovardhan,

I have and located people involved but they haven’t been responsive for almost a month now. The SlingShotDAO and the SlingShot Finance App were separate entities but closely affiliated and had cross team members but it seems when the app was acquired by MagicEden things fell apart and that is making things much more difficult.

When you say “custom login,” what was the configured token issuer or authentication provider? Do you retain the historical verifier configuration, including issuer/JWKS URL, verifier name, network and identity field? I’m not asking you to impersonate the issuer—these details would help identify which service must be restored.

17

@yashovardhan Any other information?

18

@yashovardhan @shana For client ID BJKCIoPMW834sLeBMIS5S-lk0YmrOo8Ld2CXPs5IhjmayxFpkiyqPjNsjeQKS6Iu0csQ6zk_zSe9Ehu1T3rzUOcon sapphire_mainnet, Chain ID 42161, http://app.slingshot.dao.com, what authentication connections were configured in April 2025?

Specifically, was this project using standard Web3Auth social/email-passwordless connections, or a custom JWT/grouped verifier? Please provide the historical connection/verifier names and identifier fields to the verified project operator.

The recovered initialization did not contain an application-defined custom JWT verifier or loginConfig override. The archived frontend code shows the standard Web3Auth AUTH adapter and no visible custom JWT configuration. It supports that initialization occurred by Web3Auth using the project’s client ID and sapphire_mainnet, then invoked Web3Auth’s AUTH adapter for social or email-passwordless login.

It looks like there was a custom interface but no custom authentication or verifier. The site sent web3auth ID token to /api/me.

I have not heard back from anyone and I would appreciate some help here.

1 Like