getWalletOptionsCatalogue returns the catalogue of external wallet options a user can sign in with through this client. It collapses what used to be multiple per-source calls (installed providers, URI-based connection options, in-app browser entries, install links) into one ordered list, where each entry already carries every connection path the user can take for that wallet.
Use it to render a single, canonical wallet picker without writing per-source merging or deduplication logic.
Usage
getWalletOptionsCatalogue always includes installed wallet providers. Set includeMobileOptions: true to additionally surface URI-based connection options (mobile handoff and QR code), in-app browser entries, and install links. This adds one network round-trip, so prefer skipping it if you only ever show installed wallets.
Parameters
Return value
An array of WalletOption. Each WalletOption has:
Connection options
Each WalletConnectionOption is a discriminated union by type, ordered within connectionOptions from best to worst:
withWalletProvider — connect through a wallet provider already registered with the SDK (browser extension, vendor SDK, etc.).
- Fields:
chain, source ('selfAnnounced' | 'windowInjected' | 'sdk'), walletProviderKey.
- Call
connectWithWalletProvider({ walletProviderKey }) to connect, or connectAndVerifyWithWalletProvider({ walletProviderKey }) to connect and verify the wallet account in one step.
- URI connection (
type: 'walletConnect' | 'metamaskSdkUri'): start a mobile wallet handoff or render a desktop QR code.
- Fields:
chain, deeplinks: { native?, universal? }, type.
- For
'walletConnect', mint the URI with connectWithWalletConnect<Chain>. On mobile, append it to the wallet’s deeplink with appendConnectionUriToDeeplink.
- For
'metamaskSdkUri', call connectWithMetaMaskUri<Chain>. The SDK opens MetaMask on mobile. Use the returned URI only for a desktop QR code.
inAppBrowser — a mobile wallet that exposes an in-app browser entry URL.
- Fields:
chain, url (template containing {{encodedDappURI}}).
- Substitute
{{encodedDappURI}} with encodeURIComponent(window.location.href) before opening.
When connectionOptions is empty but installationUrls is populated, the wallet is install-only — render an install affordance using the appropriate platform link rather than a connect button.
For install-only wallets (and the “install” fallback path on any other wallet), the SDK ships a small helper that picks the most relevant install URL from installationUrls for the platform the user is on right now:
The helper detects the platform (iOS, Android, Edge, Opera, Firefox, Safari, or Chrome) and returns exactly the field that matches it, with no fallback to a different platform. If the wallet’s manifest doesn’t ship a link for the detected platform, the helper returns undefined so you don’t end up handing a Firefox user a Chrome Web Store URL.
That said, installationUrls exposes every link the wallet’s manifest publishes — android, chrome, edge, firefox, ios, native, opera, safari — and you’re free to surface several of them at once so the user picks where to install. The helper is a convenience for the common single-button case, not a constraint.
Ordering
With walletOptionOrdering: 'relevance' (default), wallets are bucketed into three tiers, in this order:
- Installed — has at least one
withWalletProvider connection option.
- Connectable: has at least one URI connection or in-app browser option, but no installed provider.
- Install-only — only
installationUrls is populated.
Within each tier, well-known wallets (MetaMask, Coinbase, Phantom, …) rank above unknown wallets, which fall through to alphabetical order at the tail of their tier. The inner connectionOptions array is always ordered by option-type priority (withWalletProvider > URI connection > inAppBrowser).
With walletOptionOrdering: 'alphabetical', the outer list is sorted by name only — no tiering. The inner ordering is unchanged.
React
useGetWalletOptionsCatalogue fetches on mount and re-renders when the catalogue changes:
See also
Last modified on September 9, 2026