The wallet still holds my NFT, Trump Digital Trading Card #18488, so I have confirmed the wallet and asset still exist on-chain.
The official CollectTrumpCards wallet login currently redirects to auth.web3auth.io/v8/start, where Web3Auth returns:
“Unsupported Version — This version of Web3Auth is not supported anymore. Please update to the latest Web3Auth SDK.”
This wallet was originally created through the CollectTrumpCards credit-card purchase flow using Torus/Web3Auth email/social authentication. I am the original purchaser.
I need to know whether there is any supported end-user method to authenticate to/recover the existing wallet, rather than generating a new wallet.
If recovery requires the original CollectTrumpCards Web3Auth client ID/verifier configuration, can Web3Auth tell me what information the application operator must provide or what migration they must perform so I can regain access to the existing wallet?
I can provide screenshots of the error, proof of purchase, the NFT, and candidate email accounts privately if required.
The on-chain NFT and address confirm the asset is still at 0x95826c4572719f6cf21feec19909a59c2971d6c2, but on-chain ownership doesn’t provide a way to reconstruct the wallet’s signing key.
There is no supported end-user-only recovery flow that lets us authenticate you into a wallet created by another application’s legacy Torus/Web3Auth integration. The v8/start error means CollectTrumpCards’ login is still calling an unsupported legacy version; only that application’s operators can update the integration and restore a working login path.
Whether the existing address can be regained depends entirely on how the original authentication was configured:
Built-in social login under the application’s client ID: the address is derived from the same provider + identity + verifier combination. It can be reached again only if the project re-enables that login and migrates without changing the wallet-determining configuration (client ID, verifier/connection name, network). Changing any of those produces a different address.
Custom authentication (the project’s own JWT issuer or custom verifier): the identity system belongs to CollectTrumpCards. We don’t hold their issuer or verifier and can’t reproduce that login or derive the wallet. If no MFA/recovery factor was ever enabled on the account, there’s no independent recovery route on our side.
So the actionable path runs through the application operators: they need to treat this as a migration of their existing production configuration, not as a new Embedded Wallets project. They must identify the original client ID, verifier/connection name, network, and the exact provider and user identity used for the December 2022 purchase, then ship a supported SDK login flow that preserves that legacy mapping. Their developers can find their project’s client ID and connection configuration at https://dashboard.web3auth.io. Our migration guides confirm that legacy SDK versions have to be migrated to current versions — for example, the React Native guide at React Native SDK migration guide | MetaMask developer documentation — but the exact steps depend on which platform and SDK their login actually uses, so we can’t state their path from here.
To work out which case applies to you, you can reply here with:
The exact CollectTrumpCards wallet/login URL that previously authenticated you.
The original login method: Google, Apple, Facebook, email passwordless, or another provider (the provider name only — please don’t post the email address itself publicly).
Whether that same login still works anywhere in the CollectTrumpCards product today.
The project’s client ID or verifier/connection name, if its operators will share it.
Please do not post or send a seed phrase, private key, password, OAuth token, or one-time email code to anyone, including us — no legitimate recovery step requires them. Screenshots and proof of purchase may help CollectTrumpCards identify your account on their side, but they can’t substitute for the original authentication configuration and don’t let us derive the wallet key.
Next step: ask the CollectTrumpCards operators to either re-enable the original login or complete the SDK migration while preserving their existing client ID and verifier. Once you know the original provider and they can confirm the client ID/verifier, post it in this thread and we can explain exactly what their migration has to preserve so your existing address is reachable again.
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.
The CollectTrumpCards wallet/login URL I am currently using is: https://wallet.collecttrumpcards.com/
It redirects to auth.web3auth.io/v8/start and returns “Unsupported Version — This version of Web3Auth is not supported anymore.”
I do not remember the original authentication method used in December 2022. I purchased the NFT by credit card and recall that the wallet was created as part of that process. I have several possible Google/email accounts from that period, but I do not know whether the original authentication was Google social login or passwordless email.
The login does not work today because of the Web3Auth v8 Unsupported Version error described above.
I do not know the original Web3Auth client ID, verifier/connection name, or network configuration. I have asked CollectTrumpCards support for assistance and can request these details from their technical team.
My existing wallet address is: 0x95826c4572719f6cf21feec19909a59c2971d6c2
The original mint transaction for NFT #18488 is: 0x122db3190845a5c455ca4a8237cda6ed2caaf67d08e000fb779a20f976d4a3a5
I will not post any email addresses, seed phrases, private keys, passwords, authentication tokens, or verification codes publicly.
I would appreciate review by the MetaMask/Web3Auth Community Team to confirm the appropriate recovery/migration path for this legacy integration.
The “Unsupported Version” page means CollectTrumpCards’ legacy Web3Auth v8 integration is no longer usable as deployed. By itself it does not mean the wallet address or the NFT is gone — the assets remain at 0x95826c4572719f6cf21feec19909a59c2971d6c2 on chain. What is blocked is the login path that derives your key.
Because MetaMask Embedded Wallets (Web3Auth) wallets are non-custodial and derived from the authentication method used at creation, we cannot sign in as you, migrate, or export that wallet without knowing how CollectTrumpCards configured authentication in 2022. We do not hold user keys, and we cannot reconstruct access from a wallet address or transaction hash.
The recovery path depends on which of these the project used:
Built-in social login (e.g. Google) under CollectTrumpCards’ client ID: the same Google account used at mint time would derive the same wallet, but the project still needs to restore a working login path (an updated SDK integration on their client ID) for you to reach it.
Passwordless email login under their client ID: same situation — the original email identity plus a restored login flow.
Custom authentication (their own verifier, JWT issuer, or configured identity provider): CollectTrumpCards controls the verifier and the token issuer. We cannot recreate that login or restore the wallet independently. See Using custom authentication | MetaMask developer documentation for what a custom verifier setup involves.
If MFA / a backup factor was ever enabled: there may be an additional recovery factor. We cannot tell from here whether one exists — the project operators or your own records would have to confirm it.
Since you don’t recall the original method, the deciding information has to come from CollectTrumpCards. Please ask their technical team to confirm:
Whether the wallet used built-in Google/email login or a custom verifier/JWT flow.
The legacy Web3Auth client ID and verifier/connection name tied to these wallets.
The original network/environment (e.g. legacy Torus network vs. Sapphire) and whether MFA or any export/backup mechanism was enabled.
Whether they can re-deploy a supported SDK version against the same client ID and connection so affected users can sign in again, or otherwise offer a migration/export path.
Point 4 is the practical fix for most projects in this situation: upgrading the integration to a currently supported SDK while keeping the original client ID and connection configuration preserves the same derived addresses. The quick-start examples at GitHub - Web3Auth/web3auth-examples · GitHub show what a current integration looks like, and their team is welcome to reach us here on the Builder Hub with the client ID and verifier details if they need help with that migration.
You’ve already shared the only identifiers that are safe and useful in public — the project URL, wallet address, and transaction hash. Please continue to never share a seed phrase, private key, password, authentication token, or verification code with anyone, including us.
Once you have CollectTrumpCards’ answer on the original login provider and client ID/verifier name, post it in this thread and we can advise on the concrete migration path from there.
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.