In this case study, we look at a product that balances daily spending with what a bank would call a savings account 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 onboarding. 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 case study 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 third key will be held by the wallet application provider 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.
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 case study.
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.
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.
Signing device key replacement #
Should they lose either their main mobile device, or the purpose-built signing device they can replace the lost key (rotate in a new key) with the help of the recovery key held by the auto-signer. However, if they lose both the mobile and signing device they will not be able to recover their funds, unless they had also backed up either of the respective recovery phrases. View prototype.
Cloud storage key recovery & replacement #
If a user loses access to their cloud storage, or accidentally deletes the backup file, they can easily restore the backup. If they no longer want to use cloud storage, alternative options should be available. View prototype.
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.
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)
Case study resources