Savings wallet
In this reference design, we look at a product that balances daily spending with what a bank would call a savings wallet where the user might store wealth long term. Safeguards against loss will be a higher priority than with a frequent spending product, and we might therefore accept more friction both when setting up the wallet and when transacting. If users have no prior bitcoin knowledge, we should expect to spend a significant effort educating them to put them in a position to safely operate the wallet product.
The following prototype includes initial onboarding, sending bitcoin, and key replacement, which are explained in detail further below.
Private key management
A 2-of-3 multi-key setup would seem the most appropriate here, although it will be a significant hurdle in first use. Other schemes could be considered but come with distinct downsides for amounts of value we can expect users to store in this use case. A single-key scheme with an automatic cloud backup, recovery phrase or single signing device could work at the lower end of the value scale, but start to look like less responsible recommendations with higher values due to their single points of failure.
An important question is the combination of key-storage devices and their distribution. We have many options here, and it might come down to the experience of the target audience and their expected access to the necessary hardware;
- As low friction as possible (co-managed, no purpose-built signing device)
- Middle ground (co-managed, one purpose-built signing device)
- Full sovereignty (one or more purpose-built signing devices)
- All keys off-line (two or more purpose-built signing devices)
For this reference design, we will go with the middle ground option, which will require one purpose-built signing device such as a hardware wallet. The second key will be created on the user’s main mobile device and automatically backed up to their cloud storage provider. The wallet application provider will hold the third key on a server for wallet recovery, key replacement, and automatic approval of low-value transactions (auto-signing). Neither of the two keys in the user’s control (mobile and signing device) will require recovery phrase backups, although this could be offered as an option.
The onboarding experience
The screens below show the sequence of actions the user is guided through to set up and secure all three keys used by the wallet. View prototype.
Introduces the user to the setup flow and informs them about having a signing device at hand.
PIN entry, which is used for encrypting key and user data. This could also be an email.
Overview of the key setup process.
Explanation of how Key 1 is set up. More on automatic cloud backup.
Choice of cloud storage provider.
Provider specific authentication steps.
Success message when Key 1 is created and secured.
Choice of connection method to the signing device.
Choice of signing device for Key 2 to provide accurate instructions.
Introduction to the key creation process via the signing device.
Step 1 is to export the XPUB on the ColdCard.
Step 2 is to connect the SD card from the ColdCard to the phone.
The card was detected and the XPUB copied.
Success message when Key 2 is created and secured.
Summary of how Key 3 is set up and the auto-signing functionality.
Final success message that the wallet is ready.
Note that this experience could be designed in a progressive way. Users would start with a simple single-key wallet and upgrade to a multi-key configuration as needed. This design is explored in the upgradeable wallet reference design.
Making small payments
Users will be able to conveniently make small payments in the app. Transactions are automatically signed by the wallet application provider, up to certain limits. This provides convenience for daily transactions while protecting larger savings. View prototype.
Basic home screen to access, send, and receive functionality.
The user has entered an amount within the auto-signing limits.
Once the user taps “Send”, the auto-signer approves and broadcasts the transaction.
Making large payments
For larger transactions, the wallet application provider will no longer automatically approve. Instead, the user needs to connect their signing device for manual approval. View prototype.
The user has entered an amount beyond the auto-signing limits, and a note appears about manual approval.
Prepare the user for the signing steps specific to their device type.
Connect the SD card to save the PSBT file.
Describes how to sign the PSBT file on the Coldcard.
Loading the (now signed) PSBT file back into the app.
Found it.
The user has one more chance to review the transaction before sending it.
Wallet Recovery and Key Replacement
Restoring a bitcoin wallet or replacing keys may be necessary for various reasons. The user may have lost their mobile phone, signing device, or access to their cloud account backup. Regardless of the reason, wallet applications must offer a straightforward recovery option for users to regain access to their funds.
Here are different scenarios where users may lose access to their wallet or keys and potential methods to resolve the problem:
The user lost their mobile device
At some point, users are likely to either lose their mobile device, purchase a new one, or delete the wallet app.
For them to recover their wallet again, they would need the following:
- The sign-in details of the cloud account that contains the backup key
- The PIN they created when setting up the wallet, to decrypt the cloud key
- Access to their signing device
They can use their PIN to unlock the cloud key and, with the help of the signing device, recover their wallet. If the user loses any 1 of these 3 things, they will not be able to recover their wallet again.
The user lost their signing device
It is less likely, but possible, that a user may misplace or lose their signing device, for example, in the event of a fire.
In these cases, they would need to have access to the following:
- The mobile device that set up the wallet
- The recovery key held by the auto-signer
With these 2 things in place, they can simply rotate in a new key. However, if the user lost their mobile device as well, they would not be able to access their wallet again. View prototype.
A simplified settings screen to access key recovery.
User options to identify which key they lost access to.
If recovery is possible, the user is informed about the process.
Additional messaging about recovery costs.
Repeat the device registration flow from the onboarding sequence.
A confirmation that the recovery is complete and the new wallet is ready for use.
The user lost access to their cloud account
Occasionally, users may forget their cloud account sign-in credentials or, on rare occasions, accidentally delete the backup file.
If this happens, they would need to have the following to replace their cloud key again:
- The mobile device that set up the wallet
- Their signing device
If the user lost their mobile device as well, they will not be able to replace their cloud key. However, if they still have access to their mobile device, but no longer want to use cloud storage, they should have other options available. View prototype.
The user has lost access to their cloud storage.
Several options for key backup are available.
The following steps depend on the user choice of backup method.
The user forgot their PIN
As previously stated, if a user misplaces their mobile device and can’t remember their PIN, they won’t be able to recover their wallet.
To reduce the chances of this happening, spaced repetition could help the user remember their PIN. However, if they realise that they forgot their PIN during a spaced repetition exercise, they should be able to simply change their PIN given they also have access to the recovery key held by the auto-signer.
Changing spending limits
Daily and per-transaction spending limits are a unique aspect of this application design. To avoid tampering, changing them also requires approval via the signing device. View prototype.
A simplified settings screen to access the auto-signer limits.
Overview of current limits with options to change them.
Inform users that limit changes require approval via the signing device.
Approval requires signing a message via the signing device.
Success message that limits were updated.
Design considerations
- Suitable for daily and monthly transactions
- Lots of edge cases and infrequent but important situations
- Key setup, rotation, recovery and signing flows
Technical considerations
- Complexities of multi-key setups
- Implement thorough backup code and instructions for users
- Usage could be simplified by having hardware devices designed/customized by the software maker (compare banks and their digital token signers common in Europe)
Resources