Wallet discovery
The catalogue of available wallet providers moves fromuseWalletOptions to a single function.
Each entry carries the provider
key, display name, icon, and installationUrls so you can render install links for wallets the user doesn’t have. For the full wallet picker (search, install links, deeplinks), see Connecting external wallets.
Connect vs. connect-and-verify
The React SDK decided when to prompt for a signature. Now you choose explicitly. The recommended default isconnectWalletOption({ walletKey }), which takes a wallet options catalogue key — the closest equivalent of connecting through the React SDK’s useWalletOptions flow. It picks the connection path the wallet supports on the user’s device (installed provider, URI pairing, or the wallet’s in-app browser) and returns an unverified WalletAccount, which you pass to verifyWalletAccount to link it to the user. See Connect a wallet by catalogue key for the full reference.
The provider-key functions are the lower-level path. They drive an already-registered wallet provider only — installed extensions and redirect providers such as Phantom on mobile — and cannot reach URI-pairing or in-app-browser wallets:
connectWithWalletProvider({ walletProviderKey })— connect only (read the address, no signature).connectAndVerifyWithWalletProvider({ walletProviderKey })— connect and prompt for a sign-in signature, proving ownership and linking the wallet to the user.
- TypeScript
- React
Hardware wallets
The dedicated hardware-wallet selection view is gone; check support and account type with functions.Multi-wallet
Automatic multi-wallet prompts (a new wallet detected, switching the active wallet) are gone, and the SDK doesn’t track a selected wallet for you. Read the full set withgetWalletAccounts() and build your own selection UI — see Connected wallets management.
Errors you now own
The React SDK rendered built-in screens for these cases; in the JavaScript SDK you catch the typed error and render your own UI.Wallet screening (Chainalysis sanctions checks) still runs server-side during verification and is configured per environment in the dashboard — nothing changes there. What changes is that you handle the blocked result and render the UI. The token-gating (
gate_blocked) and allowlist (missing_from_list) cases are still surfaced via their raw API error codes.