13 min read

Losing your keys without losing your coins

Creating forgiving recovery experiences

As we continue building our bitcoin wallet, we’re excited about ways we can make self-custody more accessible to a wider audience, especially by finding easy ways to recover when something goes wrong. We’ve been thinking about how to create a more forgiving, low-burden, flexible recovery experience. Everything here is still in development and open to change, but as we learn and build in the open, we want to share what we’re thinking and hear from more people about ways we can make it even better. Send us your thoughts at wallet@block.xyz or on Twitter.

Who we’re building for

As we laid out in our product principles, we are trying to build a better tool for a global, mainstream audience to safely self-custody and manage their digital assets, starting with bitcoin. Safety, in the context of a wallet, breaks out into two equally essential jobs:

  • Ensure you do have access (availability)
  • Ensure unauthorized people don’t have access (security)

These two jobs are almost always in tension. Any added protection to keep a bad actor out adds a risk that it may also trip up the owner, and any new backup or alternative way to access creates a new potential security hole. From our global research, we've learned that most people holding coins on custodial platforms are hesitant to move to self-custody wallets because they are nervous about making mistakes using them - and not because they think self-custody solutions are less secure. They feel stuck: worried about the lack of control they might experience in a custodial platform, yet also anxious about the unforgiving product experiences that exist in today's relatively technical self-custody wallets.

To make self-custody accessible to this kind of audience, we need to optimize not just for security, but for safety. That means building tools that balance the desire for perfect protection against practical realities - accidents happen, and people won’t always perform security procedures perfectly, especially ones that require new behaviors and deep understanding. We need to create forgiving recovery experiences that prioritize easier paths to get customers back on their feet when something goes wrong, with more tolerance for simple mistakes, and without a steep learning curve.

What we’re trying to build

There are already a lot of great wallet products out there that allow for secure long-term, self-custodial storage of bitcoin, and others that allow for quick and easy access to funds when they’re needed, but none that succeed at both purposes. As a result, most avid bitcoin owners we’ve spoken to eventually end up relying on multiple wallets for different purposes. This means managing the security of multiple different products, as well as the mental accounting needed to track which money is where and to manually rebalance between them. The future of money shouldn’t require transacting on a globally distributed payment network to send things to yourself. In addition to adding to the learning curve and expanding the mental burden of ownership, relying on this approach for self-custody contributes to limiting how many people can make use of it before others are pushed into becoming dependent on custodians instead.

We want to build something that includes lower-burden security practices, more forgiving recovery experiences, and that can be used for both easy spending and secure savings, all in one tool. As we said in our previous post about how the wallet that we're building works, we think we can do that with a 2-of-3 “multisig” design. (Before we settle on a name, we’re referring to the whole system internally just as “Wallet”). Wallet is made up of three parts - a mobile “App”, a specialized “Hardware” device, and our backend “Server” - with each controlling one of 3 keys, and all transactions needing approval from at least two of them. As a reminder, the customer controls two of these keys using the App and the Hardware, with Block managing the Server key on their behalf.

What we’re trying to avoid

With the flexibility and redundancy offered by a 3-part wallet design, and the above audience in mind, there are some elements we’re trying to steer away from when designing recovery processes:

Plaintext backup material (Seed Phrases)

We think one of the barriers to more mainstream adoption of self custody is the need to create and physically protect sight-sensitive backup material in order to stay safe. This means moving away from reliance on 12- or 24-word seed phrases that (to be secure) customers record on a medium like paper or metal, and live with the constant danger that anyone who gets even brief access to this material could immediately use it to steal all of their assets. Whilst experienced users are familiar with seed phrases, we believe newer users are intimidated by them. They also represent a relatively easy opportunity for bad actors to exploit customers who don’t fully understand their importance - whether by convincing a customer to share a seed phrase over the phone, tricking a customer into entering an already-compromised seed phrase at wallet setup time, or compromising a customer's iCloud or Google Drive account that contains a photo of the paper physical seed phrase card that came with their wallet.

Password memorization

Collectively, people are terrible at creating and remembering secrets like passwords - especially ones that are complex enough to be secure. We want to be extremely careful in what we require people to store in their heads in order to keep their assets safe. Tools like password managers aim to reduce the burden of managing unique, high-entropy passwords for every site or service, but we don’t think use of these tools are universal enough yet to be relied on for a global audience.

Intense identity verification

We don’t think customers should need to hand over extensive identity documentation in order to maintain self-custody of their bitcoin. It excludes customers who don’t have reliable access to ‘supported’ documents, reduces privacy, and creates more operational and customer experience headaches than it adds in security.

Our recovery experience goals

Based on our principles, constraints, we want to build tools that deliver against these experience goals for Wallet customers:

  • With only a mobile app, hardware device, and a couple of minutes of basic setup, you can create a self-custody wallet that allows you to safely manage your funds, even if you lose access to one of your devices (App or Hardware).
  • When setting up your Wallet, you don’t need to remember any new secrets (except a PIN only if you don’t want to rely solely on a fingerprint to unlock the Hardware), or share any identity information beyond an email and/or a phone number for essential notifications.
  • You set your own limits for what money can be moved with only your mobile App (in tandem with Server), while the rest stays protected behind an approval required from your Hardware.
  • By optionally enabling Social Recovery (more on this below), you can pick a set of close personal contacts to rely on to help you recover from some situations faster, and even get back to safety if both your devices are lost (App AND Hardware).
  • With two of three keys in your hands, you have true ownership: we cannot move your money without you, and you can move your money using your keys without us.

Recovery experiences and tools to enable them

We explore here just a few of the most common situations our future customers are likely to run into at one time or another, and the tools we’re building to make recovering in those scenarios as safe and easy as it needs to be for our audience. This isn’t intended to be an exhaustive description of every possible method of recovery, or cover all adverse conditions customers may face (we’ll look to share more thinking there in the future) - just a focus on common loss events for individual Wallet parts. Some tools are useful in multiple scenarios, giving customers redundancy and fallback options for recovery if any of them are unavailable.

1 - Enabling your App on a new phone with Cloud Backups and your Hardware

You are walking down the street and fall, dropping your phone. As sometimes happens, a bad landing cracks the screen. You decide it’s time for a new phone anyway, buy a new one, and start setting it up. You go to check your App, and arrive on a landing screen suggesting you can enable your Wallet on this new device by approving with a tap from your Hardware. In the background, App has found a Cloud Backup you created when you first set up your wallet, and is ready to unlock it using a secret held on your Hardware. You retrieve your Hardware from the safe place you keep it, wake and unlock it with a finger you enrolled. A moment later your App shows it’s ready, and looks just like it did on your old device.

We think involving a mobile device as part of Wallet is important to make sending available and easy, but recognize that relying on a small fragile computer that goes everywhere you do exposes it (and the key it protects) to a lot of risks. Wear and tear, theft, and periodic device upgrades are likely to be the most common ‘recovery’ experience for customers, and so shouldn’t feel like an emergency. Relying on a customer’s native cloud storage to hold important app data is intuitive and easy to use, and protecting it with an extra layer of encryption through another part of the Wallet that you normally keep separate from your mobile device (the offline Hardware you can leave somewhere safe) adds enough security to use it for one of Wallet’s 3 keys.

Cloud Backups allows two encrypted copies of the App Key to be exported to customer-owned cloud storage during Wallet creation, one then decrypted by the Hardware Key, and the second decrypted by a secret held by Server and made available to App in rare emergencies (see 3.) below). The first backup is helpful for quick and easy setup of Wallet on new mobile devices, while the second copy protected by Social Recovery creates a path to recover from loss of both customer-owned hardware devices and their keys.

Setup: During App onboarding, App asks for access to cloud storage and strongly encourages a simple 1-click ‘Backup Mobile Key’. The wallet can still function without this, but won’t have as many options for recovery.

Requires: App write- and read- access to create and find backups in customer-owned cloud storage, and customer access to either their Hardware OR emergency contacts (through Social Recovery) use/decrypt.

2 - Replacing your lost Hardware with Key Rotation with Delay and Notify

You moved last week, and still haven’t found your Hardware device after unpacking most of the moving boxes, and you’re worried you’ve lost it. You hope it turns up, but just in case you order a new one to replace it, and in your App’s security center you tap ‘I’ve lost my Hardware’. You hadn’t set up any optional protections like Social Recovery, and so it begins a long countdown as it prepares for a Key Rotation with Delay and Notify. It explains that during the delay it will send out notifications to your email or SMS (or both, if available) you opted to provide during setup. You start to see emails every so often showing how much time is left in your delay window, and guidance on how to take action to cancel with your Hardware if it wasn’t you who actually requested assistance. In the meantime, you can still spend smaller amounts of bitcoin based on the spending limit you set for your App.

Once your new Hardware is in hand, you pair it with your App with a few taps by enrolling a fingerprint or setting a PIN. After the delay window is complete, ‘finalize recovery’ becomes available, letting you use your App to send a transaction sweeping all your funds into the control of your App and new Hardware.

A permanently lost key (either Hardware or App) can be replaced by ‘rotating in’ a new one by using the remaining customer-controlled key + Server’s key to move funds to the control of a new 2-of-3 address. Because Wallet won’t require a login/password elsewhere and identifies customers through key possession, there is a risk of theft by any would-be attackers temporarily compromising a single customer-owned device/key. To mitigate this risk without relying on things like formal identity verification, this recovery flow is time-gated to allow a rightful owner time to be made aware of and cancel any fraudulently-triggered recovery attempts by a bad actor. Notifications of recovery countdowns are broadcast persistently to any online App part of a Wallet undergoing recovery, and periodically to any other customer-provided communication channels such as email or via SMS. If that delay completes without anyone canceling by proving control of the key being replaced, then Server can more safely treat that key as lost and proceed to cooperate in replacing it.

Setup: Enabled by default through basic Hardware device pairing. Communication channels for recovery attempt notifications set up by the customer - email and/or SMS as optional.

Requires: Access to just one of the customer-controlled Wallet keys (Hardware OR App), along with a wait.

3 - Recovering from losing *both* your App and Hardware with Social Recovery

Disaster has struck and a fire broke out in your home, destroying many of your possessions, including your phone AND your Hardware which was stored in a safe. With 2 keys gone, you can’t access any of your assets - but all hope is not lost! You still have Server, your Cloud Backup, and your friends and family to rely on for help. Once you’ve set up a new mobile device and downloaded App, it walks you through recovering from your cloud backup using Social Recovery. When requested, Server starts by showing you a unique one-time code, and explains you’ll need to connect with your emergency contacts and share that code with them - after they are sure it’s really you who needs help. Meanwhile, Server sends a text or an email to your sibling, your spouse, and your best friend - all the people you set as emergency contacts for your wallet. It explains why you’re asking for help, and includes a link to follow to a simple webpage to enter the code you’ll share.  App asks you to get in contact with at least two of them via voice or video, share your unique code, and ask them to complete the process by entering it in the link they received. Once Server sees at least 2 of them have done so it sends a secret it holds to your mobile App to allow it to decrypt one of the backups you created when you set up your Wallet. From that backup, your App key is restored, and now you can use Delay and Notify Key Rotation to recover the remaining lost Hardware.

We plan to offer Social Recovery as an additional opt-in layer of protection that provides another alternative to identifying you as the real owner during a recovery event. This can be used to expedite Delay+Notify Key Rotation, and even unlocks a recovery path in a (more rare) scenario where something goes wrong with both your keys at once. Instead of relying on passwords and/or government-issued IDs to authorize yourself, Wallet can let you rely on people you trust to confirm you are who you say you are, so that Server can safely help you restore your Wallet even with one or both your keys missing or unavailable.

Setup: Optional - suggested at some point but not required to use Wallet. App prompts you to set 3 people you trust (or devices/accounts you own) and are comfortable relying on to serve as Emergency Contacts (ECs). App asks you to name and provide a contact channel for each of them (email and/or SMS). Server sends a message to added ECs with a request for a code to be entered on a website hosted by Wallet (where they are encouraged to make sure it's really you who needs help), and simultaneously, makes that code available to the customer to be shared with their ECs in person or over phone/video. Setup is complete only when this process is finalized for 3 different ECs.

Requires: A majority of ECs (2-of-3) be responsive to the owner when contacted, following the same code share / entry as in setup. At least one part of the customer controlled wallet is still accessible (App with Key, Hardware with Key, OR cloud storage). Also requires that the Server be reachable to facilitate.

Where we need your help

We think the above is a good sketch of the kinds of forgiving, low-burden recovery experiences we want to allow customers to depend on. There is still lots to test and explore as we look at implementing them, starting with a handful of questions below we’d like your input on. Please send us your thoughts on these at wallet@block.xyz.

Notifications - Without formal ID-documentation-based verification, we think tools like Key Rotation with Delay and Notify need to be effectively communicated to customers via notifications so that attempts by would-be attackers can be shut down by the rightful owners. While some customers may religiously (a) enable in-app notifications and (b) pay attention to them, our global research among our target customer base has shown loud and clear that customers want to be emailed or texted when there is a security-related event in their wallet. In fact, many customers told us they want to get all of those notifications as it helps them feel confident that it’s a real communication from Wallet as opposed to a phishing attempt. This means depending on other tools like email and SMS for messaging, and in setting delay windows long enough to confidently protect users, without being so long that they feel punishing for real recovery events.

  1. What are the right communication channels (email, SMS, in-app notifications, other messaging apps, or something else) to rely on to best serve a global audience?
  2. If such channels are opt-in, are we positioning new, less technical customers who don’t provide any in a good enough default state to stay safe?
  3. If such channels are mandatory to provide (and verify), does the Wallet start to abridge too much customer privacy and overburden setup?
  4. How long (and how customizable by the customer, if at all) should enforced delays be to balance security vs. availability?

Social Recovery - We think there’s a lot of potential in empowering a customer to use their chosen, trusted select few peers or family members to help them in case they lose 1 or both of their keys, rather than on centralized authorities and traditional identity verification. That said, we recognize that doing so is a pretty unfamiliar experience for most of our target customers who are used to relying on the “forgot my password” flows they see in custodial wallets that have KYC experiences to use in response.

  1. Do you have 3+ friends or family you’d feel comfortable asking to rely on if you ever need help recovering part of your wallet, in a process as simple as following a link and entering a code? How would you explain the tool so that you were sure they understood its purpose, and their role in protecting you?
  2. How can we can ensure customers connect directly with their emergency contacts to really verify who is requesting help, so that this tool doesn’t become a phishing target?
  3. We started by considering ways that ECs could directly hold backup material for customers to allow for Social Recovery without Server as an intermediary, but found in some early interviews that requiring emergency contacts to download an App they aren’t otherwise using was likely a big barrier. How can we more directly rely on a circle of peers for assisting in recovery that doesn’t create a much higher barrier for acting as an EC?

While these are specific questions we're thinking about right now, we’re also open to all types of feedback: What about the above make you excited, or skeptical? What seems missing, or perhaps unnecessary? What process or part of the wallet doesn’t seem as robust as it needs to be for new to bitcoin customers to use safely and easily? In addition to wallet@block.xyz, you can also reach us on Twitter.