A channel state backup is typically a file which includes information about the user’s channel balances. This file can be downloaded onto the user’s device and used to restore the Lightning channel state on another device. This could be a database of the most current channel balance information, or a static backup (as an absolute last resort).
Manual channel state backups are for advanced users
Manual backups of Lightning channel state should only be performed with careful consideration. This is because the channel state backup may become outdated very quickly, and attempting to restore from an outdated backup could harm the user’s funds. In the interest of adhering to the principles of self-custody and transparency, you may choose to allow your user to perform a manual channel state backup. However, this is not recommended for the majority of users. If this option is available, keep it tucked away in a settings menu and prepend a warning that the option is only for advanced users.
Type - BIP39, Electrum, Shamir Shares (SLIP39), AEZEED
Passphrase (optional)
Derivation path
Fingerprint
By far, the most important piece of the wallet recovery data is the recovery phrase. While the derivation path and fingerprint are not required in all situations (for example, when recovering a wallet using the same app that it was created with), it is good to make sure the user has this information stored in order to prevent potential loss of funds.
This user flow usually requires users to manually back up their 12 to 24 word recovery phrase by writing it down on a piece of paper and storing it in a safe (but memorable location). In the case that a user’s device breaks or is stolen, the user can recover their funds and wallet by correctly entering their recovery phrase. The private key management section dives further into the technical details of this scheme.
Printable Template
You could help the user by providing them with a printable template for writing down their recovery phrase. Some non-sensitive data (such as the name of your wallet or the derivation path) could be included pre-filled in the template. An output script descriptor could be included as a QR code to ensure the wallet software knows how to restore the wallet properly. The user should be required to write in the sensitive data by hand. Here is an example template.
If you are designing an application that opts to use manual backups, the following sections outline how to best go about this with new users in mind.
Onboarding carousels are a great place to prep and explain to users that they will be given a recovery phrase. While some wallets skip this step, it might be appropriate to display it early on in some scenarios. Doing so in the initial onboarding process allows users to pause, internalize what a recovery phrase is, and ensures that they do not neglect this step later.
Tip: Let users transact even when not backed up
If you really want to skip showing a user their recovery phrase during the initial onboarding process, create an interaction (i.e. a vibration, modal pop-up, or similar) that prompts users to “back up” their recovery phrase at a later time. Perhaps before making any transactions or after several transactions.
When introducing the concept of a recovery phrase within the onboarding process, be succinct and clear in explaining what it is, how to store it, and how to use it. Examples of some microcopy that you might include before unveiling a user’s recovery phrase can be found below:
“You will be shown your recovery phrase on the next screen”
Prepares a user for what they are about to see.
“Your recovery phrase is a group of 12 random words”
Explains to users what a recovery phrase is.
“Your recovery phrase is the only way to access your wallet if your phone is lost or stolen.”
Explains to users what the purpose of a recovery phrase is and why it’s important.
“If you lose your recovery phrase, you will no longer be able to access your wallet. Never share your recovery phrase with anyone. Anyone who has it can access your funds.”
Explains to users what the consequences of their behavior is, and how it can affect the safety of their funds.
“We recommend writing these words down in order on a piece of paper and storing it somewhere safe that you will remember.”
Guides and gives users actionable items on how to safely handle their recovery phrase.
Drilling in the larger consequences of what it means to interact with a self-custodial product is important during these first interactions with a wallet. Education within these beginning stages will empower users to make smart decisions, furthermore informing how they understand and handle the safety of their funds.
Tip: Give users access to printable templates
Providing users with printable, designated materials to write down their recovery phrase can instill a sense of trust, organization (especially if they have multiple wallets), and guidance. It may also encourage them to treat this designated paper with importance rather than quickly scribbling it down on a random scrap. Check out an example template from the Wallet UI Kit here.
The goal is to encourage users to write down their recovery phrase on a physical piece of paper. You can discourage users from taking a screenshot by showing a warning modal or disabling the functionality altogether.
Tip: Be Clear about Numbering
Regardless of the option you decide to run with, it’s important that you explicitly instruct users to number each word (i.e. 1. sand 2. purple 3. flower). Typically, a manual recovery phrase backup scheme will ask users to recount, for example, the fifth word. It’s a bit of a pain for users to count which word corresponds to a particular number if they are not numbered initially.
In a one by one design, users are given their recovery phrase one word at a time. Users are then prompted to swipe/click through each word to complete their viewing.
By forcing users to go through a physical action of viewing the next word, the chance of someone accidentally skipping over a word decreases. Giving a user time on each word encourages them to ruminate on it, potentially increasing their chance of writing it down. Additionally, it discourages users from screenshotting or copying and pasting.
This would be a time consuming step if one’s recovery phrase is 24 words. This length could cause frustration.
Another technique is to use batches or groups. In this design, the wallet splits the 12 or 24 word recovery phrase into ~3-4 groups, each group containing 3-12 words.
If your wallet uses 24 words, splitting it into groups can be more digestible and less overwhelming. Organizing into smaller chunks could also help with word association, as a user might remember the smaller batches of words.
Depending on how you show these groups of words, there is room for users to falsely number the order. For example, some wallets put these groups into columns, which could trip up a user if they are writing their words from left to right, or up and down. To avoid this, be sure to explicitly number the words.
Option 3: Using Interactions to “Uncover” or “Reveal”
A clever way to give a user their recovery phrase is by creating an interaction where they have to “uncover” it. This can entail hovering over a blurred word to reveal it, or holding down a button to show it.
By creating this design interaction, it drills in how viewing, storing, and managing recovery phrases should be a private and secret matter.
Lastly, another design is to give a user the words all at once. In this design, all words are shown on one screen.
Here, there are no surprises in how long it is and does not require them to take any further action in revealing it.
Throwing 12 or 24 words at a user all at once can potentially overwhelm them if they are not familiar with recovery phrases in general. This also introduces the possibility of a user skipping over this one screen with contents that inherently determines the safety of their funds.
This step is a great way to ensure and test that the user in question actually stored their recovery phrase in a way that allows them to access and recount it. This typically entails prompting them to recall the words, which can be done in multiple ways that are laid out below.
Tip: Confirm User Understanding
Try to make sure users understand your team cannot access their recovery phrase if they lose it. This drills in the importance of them properly and securely storing it, reiterating that access to their funds is always in their own hands.
A common design for confirming a manual backup is to present users with a scrambled word bank consisting of the words that make up their recovery phrase. Users are then prompted to select the words in the correct order.
One way to present this is by giving them numbered fields (12 or 24 words depending on the length of the respective scheme) so that users can make sure they are entering it in the correct order.
Tip: Tell Users if they’re on the Right Track
Because typing each word out comes with more room for error, create a visual indicator that shows if the user is on the right track (i.e., make the box green if it is correct, make it red if it is incorrect). Since the words in recovery phrases come from a pre-defined dictionary, your app could also offer to auto-complete words as the user types them in. It can be frustrating for a user to get a general warning that a word is not correct after having them manually type it out and force them to sleuth out where a misspelled word or wrong order occurred.
You could also ask users to select (or manually type out) a random word from their recovery phrase. For example, you would ask them to “type out word number 5”, or “type out word number 11”. To ensure maximum security, make sure you do this with 3-4 different words. This design is less cumbersome for users, but might be a pain if they did not number the words.