Skip to main content
After initializing Portal for your user, it’s crucial to determine their wallet’s lifecycle state to ensure a healthy wallet state. We provide several helper methods to easily derive the state of your users’ wallets:
The previous methods doesWalletExist(), isWalletOnDevice(), isWalletBackedUp(), and isWalletRecoverable() are deprecated. These methods silently return false when an error occurs, which can mask underlying issues. Use the OrThrow variants above instead — they propagate errors so you can handle them explicitly.
As of 9.1.0, isWalletOnDeviceOrThrow() returns false when the user has no usable wallet share on the current device, rather than throwing. Having no wallet on this device is a normal lifecycle state, not an error, so it no longer surfaces as one.If you wrapped the call in a try/catch to treat the throw as “no wallet on device”, that catch block no longer runs for this case. Branch on the returned Boolean instead:
Keep your try/catch for genuine failures — the method still throws when the client isn’t set, when the chainId is malformed, or when a share left over from an older SDK version can’t be parsed. Just don’t rely on it to signal “no wallet on device”. See absent shares versus unreadable shares for the underlying change.
These methods can be used together to understand the user’s wallet state and determine the next steps. For example:
Each method also accepts an optional chainId parameter (e.g., "eip155:1") or a PortalNamespace to check the state for a specific chain instead of globally. And that’s it! You’re now helping your users maintain a safe and secure experience with their wallets while using your apps.