Hi Liam — thanks for the clear report and the screenshot. I hear you — this looks like a reconstruction/threshold-share problem after the v9 → v10 upgrade, and I’ll help get this to the support team quickly.
What I’ve pulled from your message
- SDK: unified v10 package
- SDK version: v10.4.0
- Platform / flow: web, social/OAuth login using the default social verifier; you previously used a no-modal flow on v9
- Symptom: single social account now errors during key reconstruction (other social accounts still work)
Is this likely “not enough shards to reconstruct”? Possibly — that error usually means one or more of the key shares needed for threshold reconstruction aren’t available. Common causes after upgrades: migration logic didn’t find/restore stored shares, local storage or indexedDB cleared, the user is on a different device/browser, or the verifier identity changed (OAuth subject/sub, email, etc.). It could also be a bug in the migration path from v9 → v10 for certain social verifiers.
What will help us investigate (please provide only what’s missing):
- Exact error text or a copy/paste of the console error (the screenshot helps, but plain text is more useful).
- Browser + version and OS where the user saw the failure.
- Which social provider (Google, Apple, Facebook, etc.) for that failing account.
- SDK initialization snippet and the login snippet you use (the code where you create/init the SDK and call login) — you mentioned default verifier and typical setup, but the exact options matter (uxMode / noModal / redirect / popup, verifier string, clientId, etc.).
- Any differences in flow between the working accounts and the failing account (same provider but different email/identity?), and whether the user has used multiple devices or cleared site data.
- Browser console logs and network capture around the failing login (the full stack trace + network request/response for reconstruction). If you can reproduce, open DevTools → Console / Network, reproduce, and paste logs or attach a screenshot of the console showing the stack trace.
Quick triage steps you can try now
- Ask the user whether they are on the same browser/device that worked on v9, and whether site data (cookies/localStorage/indexedDB) was cleared or they used incognito.
- Try reproducing the same login on the same browser/device with v9 (if available) and with v10 to confirm a regression.
- If you can reproduce locally, capture console + network logs and attach them.
Notes about outcomes and recovery
- If it truly is “not enough shares,” reconstruction will fail unless the missing shares are restored (from another device, backups, or a recovery flow provided by your integration). There’s no way to reconstruct the key without the required shares. That’s why logs and storage state are key to diagnosing whether shares were lost/migrated incorrectly.
Useful docs
- MetaMask docs: https://docs.metamask.io
- Builder Hub: https://builder.metamask.io
(If you want I can try locating any v9→v10 migration notes that might be relevant — tell me whether you used any non-default options during init.)
If you can paste the requested code snippets and the console error text (or higher-res console screenshot) I’ll bundle everything for the support team and suggest next steps. If you prefer, attach the network HAR or a copy of the console output and I’ll analyze it before escalating.
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.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours