We received the end-of-support notice for React Native SDK v8 (project redirect appwalletalivio://web3auth, sapphire_mainnet) and are migrating to @web3auth/react-native-sdk 9.0.0 following the official migration guide.
Setup:
Google + email passwordless, grouped connection (groupedAuthConnectionId = web3auth-email-google-group)
Account abstraction: Safe smart account (Pimlico), EVM + Tron derived from the same key
In v8 we used useCoreKitKey: true
Problem:
Following the guide (useCoreKitKey removed), the same user gets a DIFFERENT private key and therefore a different wallet. We verified it on the same session:
state.privKey → new EOA / new Safe / new Tron address (wallet never used)
state.coreKitKey → the EOA / Safe / Tron address the user has had since v8 (with funds)
The Safe calculation itself is identical; only the key changes.
v9.0.0 still accepts useCoreKitKey in its options and getFinalCommonPrivKey returns coreKitKey when it is set, so with useCoreKitKey: true existing users keep their wallet. But the guide marks this option as removed, and the docs assistant told us it is not supported in v9.
Questions:
Is useCoreKitKey: true supported in v9 for existing users, and will it keep working?
If not, what is the supported way in v9 to keep the same key (coreKitKey) for users created with v8 + useCoreKitKey?
Is there a dashboard setting for this?
Also a possible bug: in init(), unionBy(projectConfig.embeddedWalletAuth, …, “authConnectionId”) keeps the standalone google/email connections instead of the ones inside the grouped connection, so the auth page fails with “Invalid auth connection or custom auth connection data not available”. We work around it by replacing those entries with the grouped ones before connectTo.
We cannot release v9 until we know how to keep our users’ wallets. Thanks!
Thank you for providing the detailed information and for highlighting these issues.
We understand that preserving existing wallet addresses and private keys is critical when migrating from v8 to v9.
Since useCoreKitKey is marked as removed, we cannot confirm that using it in v9 is officially supported or guaranteed to work in future releases. We recommend keeping your current v8 implementation until the key migration path is clarified.
The grouped connection issue also warrants further investigation. Let me check with the team.
Hi Shana.
Thanks for the reply. There’s a contradiction we need to resolve before we can plan this.
You recommended keeping our current v8 implementation until the key migration path is clarified. However, we received the end-of-support notice stating that as of September 30, 2026, apps on the deprecated React Native SDK version can no longer log in to the Web3Auth Network, and that users of those apps would lose access to their wallets. Our project was listed as affected.
So staying on v8 isn’t viable — it would lock our existing users out. We’re already on v9 with useCoreKitKey: true, which is currently the only thing preserving the wallet addresses our users already have.
Given that, we’d like to understand:
How long can we rely on useCoreKitKey in v9? We understand it’s marked as removed, but today it’s our only way to keep existing users’ addresses intact.
If we pin an exact 9.x version where it works, is the derivation behavior frozen for that version, or could a patch release within the same line change it?
Is there an official path planned to derive, in v9, the same key v8 returned? If so, in which version?
This is a wallet holding user funds: a change in key derivation means our users lose access to their assets. We need to plan around a supported path rather than an API that’s already marked as removed.
Hi, please note that I’ve shared your questions with the team and am currently awaiting their feedback. I’ll keep you updated once I receive a response
Staying on v8 is not a workable plan. The September 30, 2026 cutoff stops deprecated React Native SDK builds from logging in, so the v9 app you are already running is the one that keeps those wallets reachable.
useSFAKey is not the React Native replacement. That rename belongs to the Web SDK. The React Native migration guide tells a new web3authConfig.ts to delete both useCoreKitKey and useSFAKey:
The published React Native package still implements useCoreKitKey. In 9.0.0, and again in 10.0.0, it is an SDK init option, and getFinalCommonPrivKey() returns coreKitKey when the flag is true. When the flag is omitted, it returns privKey. That is the split you measured: coreKitKey is the v8 wallet, and privKey is a new one. The current examples omit the flag, so they take privKey:
How long can you rely on useCoreKitKey in v9? 9.0.0 is the only published 9.x release, and it honors useCoreKitKey: true. There is no published date on which that package stops doing so. 10.0.0 still has the same branch. Keep the flag set for users created with v8.
Does pinning a 9.x version freeze derivation? Pin @web3auth/react-native-sdk@9.0.0 exactly, not ^9.0.0. That exact package does not change underneath you. A range would install a later 9.x release if we publish one, and that release could change derivation. 10.0.0 has not changed this branch, but a later release can.
Is there a path in v9 to the same key v8 returned? Yes. In this SDK that path is useCoreKitKey: true, which selects coreKitKey. There is no useSFAKey option in the React Native SDK, and neither the migration guide nor the current examples show another config field or a dashboard setting that selects coreKitKey. Removing the flag is what moves an existing user onto the new key.
For this app, leave useCoreKitKey: true on the 9.0.0 package you have already verified. Do not drop it to match the migration checklist.
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.
Keep useCoreKitKey: true and pin @web3auth/react-native-sdk@9.0.0. That keeps the existing wallet. Do not stay on v8.
The migration guide says to remove this flag, and useSFAKey is not a React Native option. In 9.0.0 the flag still works: on, the original key is used; off, a new wallet is created. There is no other way to keep the old key.
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.
Hi @shanerr, thanks for forwarding our questions to the team.
The two AI-generated replies posted today say that useCoreKitKey: true is still honored in 9.0.0 (and 10.0.0), and that we should pin 9.0.0 exactly. That matches what we see in testing: with the flag on, an existing Google user gets their original wallet. We have pinned 9.0.0 without a caret. The replies are unverified, though, and this affects real user funds. We need confirmation from the team before we ship.
Support commitment. Will useCoreKitKey: true keep working in 9.x, and for how long? Is there a written commitment, or a date after which it may be removed or change how the key is derived? The migration guide marks it as “Removed”, so we need to know whether relying on it is safe.
Migration path. Is there an official way for existing users to move from the coreKitKey wallet to the new privKey wallet? For example, a key export, a documented derivation, or a recommended fund-transfer flow. Without one, following the guide as written gives every existing user a different, empty wallet.
v10. Does 10.0.0 still honor useCoreKitKey, and with what guarantees? 9.0.0 is the last 9.x release, so we need to know whether upgrading later would break the key.
Grouped connections bug. Can you confirm the issue in init()? It merges projectConfig.embeddedWalletAuth with the SDK’s own connection list using unionBy(…, “authConnectionId”). Our dashboard lists web3auth-google-custom and web3auth-email-custom both standalone and inside the grouped connection, and the standalone entry wins. The auth page then shows “Invalid auth connection or custom auth connection data not available”. We work around it by swapping in the grouped entries before connectTo. In which version will this be fixed?
For now we are holding the release and staying on 9.0.0 with useCoreKitKey: true. A direct answer to questions 1 and 2 would let us decide how to proceed. Thanks!