Multiple wallets
Visual representation of the users wallets.
Bitcoin applications may want to offer their users the ability to actively manage multiple wallets. To guide this reference design, we will look at a scenario of a user who has a partner and child, with all family funds being held in bitcoin. The funds are split up across multiple wallets, based on different use cases (each of which has unique security needs and ownership dynamics). However, all wallets are managed in the same application.
Note that this page builds on the other reference designs, which are contextually linked. It may be helpful to refer to them regularly.
Let’s assume the user has the following wallets set up:
A spending wallet (lightning) used for personal day-to-day purchases.
A shared wallet, co-managed together with a trusted partner. Amounts are on the low side and convenience is priority over security. A 1-of-2 multi-key setup.
A child account, which exists on the application layer only. The actual wallet used is the spending wallet (#1), so there are no extra keys to manage.
A savings wallet, using a 2-of-3 assisted custody model. Holds funds the user manages for the family.
A view-only inheritance wallet. User has a separate PIN for revealing the balance and wallet details. All keys are managed externally.
An archived single-key wallet, which the user migrated away from (see the upgradeable wallet) some time ago in favor of the savings wallet (#4).
Other scenarios for separate wallets could include additional layers like Ecash, or features like separate stablecoin balances. Unless you are intentionally designing a general-purpose application, try to design with specific use cases in mind that you can derive decisions from.
Whichever types of wallets you decide to include in your product, try to guide users towards ones that best fit their use case. Below is an example of structuring a series of questions that result in a recommended wallet configuration. Users still have the option to adjust before committing.
Each option takes the user down a different path.
The amount to store impacts recommendations on the number of keys.
Users can choose a shared model where custody is split across several people.
Based on previous choices, a wallet configuration is provided.
Degrees of separation
A big part of constructing a multi-wallet application are considerations around separating or combining elements across wallets. Again, this should be strongly informed by your target audience and their use cases.
The daily spending wallet is optimized for lightning payments by a single user. This focus leads us to decisions like a unified balance and automated swaps of incoming onchain funds to the lightning network.
In this reference design, we optimize for users who want to (or need to) explicitly split up funds and manage them separately. This leads us to:
- Different combinations of keys per wallet
- Separate balances and activity lists per wallet
- Wallet-specific settings
- Conveniently allow switching between wallets
However, we guide users towards using a single, primary private key to construct several wallets, as shown in the diagram below.
This simplifies the backup process to reduce the risk of loss of wallet. This is acceptable from a security perspective, because the wallets with larger amounts are either view-only (keys are external), or additionally protected by requiring multiple signatures (from the partner, hardware wallet, or assisted custody provider respectively).
Remember to guide users during wallet setup towards best practices around progressive security. Even with strong guidance, you often still want to allow users to deviate, to accomodate their unique use case and context.
Provide clear guidance when setting up new wallets for users.
Allow customization and help users make informed decisions.
We also keep a single contact book across wallets. Whereas for balance and transactions, we default to separate views by default, with the option for a unified view. More on that below.
Certain aspects of the application need to be flexible. For example, when a user scans a QR code of an invoice, an appropriate wallet can be automatically chosen. But this might not match the user intent, so they should be able to easily switch.
Let’s take a closer look at some of the important screens and user flows.
Payments screen
Compared to the daily spending wallet, the only addition to the payments screen is an indicator for the currently selected wallet, right above the amount input. This indicator also functions as a button to expand the wallet switcher modal.
The modal lists all available wallets, along with their balances. In our scenario, the balance of the inheritance wallet is not visible, since the user has set up a separate PIN for it. They are concerned about accidentally exposing this information to bystanders.
The currently selected wallet is clearly indicated.
The wallet selector modal for quickly switching context.
Balance & activity
By default, balance and activity only include information from the currently selected wallet. A wallet switcher is available again right above the balance. This switcher includes the option to select multiple (or all) wallets, so users can more easily get an overview of all their funds. This selection carries through to the search functionality.
The activity screen also includes a wallet switcher.
Multiple wallets can be selected.
Search also allows for multi-wallet selection.
Sending
Users can choose which wallet to send from.
A wallet indicator and switcher in the send flow is a necessity to keep users informed about which funds will be transferred. Applications may automatically switch wallets to match the given payment information. For example, if the user selects a contact that only has a lightning address, the application should switch to the lightning wallet.
Users should be able to easily override these if they want to act differently based on their current needs and goals.
For example, an application may decide that the on-chain wallet is most appropriate for a payment because the lightning wallet is low on liquidity. However the user might be in a rush and prefers to use lightning even if it means paying a swap fee for the additional liquidity.
Note that it is not possible in this design to transfer funds from multiple wallets at once.
Transfers
In addition to the new “from” selector, the “to” field also needs to be become more flexible to allow for transfers.
Transfers between wallets on different layers may require some additional setup procedures and the use of a third-party service (like a lightning service provider).
Sending to another user-owned wallets makes it a transfer.
Choosing a payment destination also lists other wallets as options.
Receiving
Payment requests the user shares include the currently selected wallet as well. And when receiving bitcoin, ensure users can easily see which wallet the payment was received to, and navigate there with a tap.
Payment requests indicate the selected wallet.
Notifications include the wallet funds were received to.
In-app notifications also include cross-wallet receipts.
Settings
Application and wallet-specific settings are clearly separated.
Settings are organized into application-wide settings and wallet-specific settings. It should be possible to backup all wallets at once, as well as individually.
A user may choose different security options across wallets, for example, to reduce friction for small lightning payments, and better security for wallets that store larger amounts.
Archival
Based on the principle of progressive security, the upgradeable wallet reference design presents an application in which users can move from one security model to another.
An example is a switch from a single-key to a multi-key wallet, because the users funds have increased in value. By necessity, this requires a new wallet to be created and funds moved over.
This, and other scenarios, may result in users having multiple older wallets that they no longer actively use. But, they may still want to keep an eye on those wallets in case an unexpected payment arrives.
This introduces the need for a wallet archive. Wallets in this archive are tucked away and generally not accessible in the primary user flows. However, the application still looks for incoming transactions and notifies the user accordingly.
Archival and fund migration confirmation screen.
Users are notified when receiving funds to an archived wallet.
Application-layer accounts
Accounts that one person completely manages for someone else (like in a child-parent relationship) do not necessarily need to be rooted in a dedicated onchain or lightning account. The application can reserve a certain amount of bitcoin and present it as a separate account. The child can request a payment to be made, which will be forwarded to the parent for approval. If you support this feature, ensure that this dynamic is clearly communicated to prevent misunderstandings and potential abuse.
Visualization & personalization
Because wallets are such primary organizational elements, a card format is sometimes chosen to give them a unique look that helps users recognize them even more quickly. Some applications also let users customize the appearance, which helps with recognition even more. It can also be appropriate to communicate wallet properties, like the layer and wallet type (single-key, multi-key, view-only…), if those are helpful to the user in the current context.
Rectangular cards that are also used to switch wallets.
Square cards are more compact. Note the indicators of layer and wallet type.
Some wallets allow for customizing each wallets visual for personalization.
On wallet accounts
Different applications use the terms wallet and account to refer to different things (see the glossary wallet page). A specific meaning to be aware of, and decide whether to support, is that of account path levels in hierarchical deterministic wallets (see BIP 44).
To put it simply, multiple separate wallets can be derived from the same recovery phrase, by choosing a different account number. This feature may be helpful to explicitly separate funds meant for different purposes.
However, users should be aware that the accounts have identical security properties. This feature is not broadly adopted. Ensure that both wallet import and export consider this and provide appropriate options.