Wallet history — a timeline of keyset changes

Role

Design lead. Worked with PM to define the problem statement, scope of work, and worked with engineering to define technical constraints. This feature was shipped and is currently live in production.

First — what are vaults?

At Unchained, we would obsess over the client experience when it comes to their bitcoin vault security. Unchained vaults allow clients to safely secure their bitcoin, with no single points of failure — requiring 2 out of 3 keys to “unlock” their vault, and spend their bitcoin. Unchained always holds 1 key as a backup, in case clients have one of their keys compromised.

Source: Unchained blog

The challenge

Key replacements can be risky

With all multisig wallets, if one of your keys gets lost or compromised, you need to go through a key replacement ceremony. When you replace a key, under the hood, you are creating a whole new wallet with a completely new set of addresses. This means that bitcoin in old addresses (secured using the old set of keys) need to be moved into your new wallet. Crucially, this also means that accidentally depositing funds to an old address (for example, if an address is whitelisted on an exchange) can put the funds at risk, since you might no longer have access to the replaced key.

Broken recordkeeping

Additionally, consistent vault statements are necessary for individuals and businesses that need to account for all the transactions that have occurred over the lifetime of a vault, regardless of how many key replacements have been performed. If you lose a debit card, you don’t have to make a whole new bank account. You simply replace the debit card and update the card number with merchants, and your bank statements and transaction history persist. Bitcoin vaults should behave the same way! Recordkeeping with multisig is a challenge when every time a key replacement occurs, your transaction and address history is lost.

Exploration and research

Birds-eye view of different explorations and iterations

First few rounds of iterations

Going through multiple rounds of iterations, I’m able to rapidly generate feedback from internal (team) and external (client) stakeholders.

For the first couple rounds of exploratory iterations, the consistent feedback I was getting from our bitcoin engineers was that 1) these stacked, multiple banners were getting too complex and 2) they weren’t mapping to the correct mental model of a history of wallets.

Generating many sub-variants of this wallet selection view allowed me to get feedback from the design team on composition and layout, and feedback from engineering on matching the mental model to the wallet code. This eventually led to the timeline view.

Solution

With the new wallet history feature, vaults now retain the transaction history, just like a bank account, even through key replacements. Clients get a consistent, continuous experience for records of transactions and vault statements, across all the old and new wallets that make up their vault.

Clients also get notifications that alert them to any bitcoin sent to an old address, secured by a potentially compromised key. Like any good partner, Unchained helps guide them through recovering those funds to a new wallet that they control, and help cosign the transfer if necessary.

Warning banner if an old wallet has received money

Additionally, I chose to truncate and disable addresses that are discouraged from depositing to:

Truncated addresses, that discourage depositing.

Bitcoin is a multi-generational asset. Over a lifetime, accidents happen, and clients are inevitably going to need to replace keys that secure their vault. With the launch of the Wallet history feature, otherwise nerve-wracking tasks like performing a key replacement, or recovering funds from an old address, become routine instead of a hectic scramble.

Design spec ready for dev handoff!