You have probably paid with an app like Google Pay, PayPal, Apple Pay or a UPI app. They feel like wallets, but behind most of them sits a bank account or a card. A Bitcoin wallet works on a completely different model, and the rest of this case study only makes sense once that difference is clear.

When you pay this way, a bank holds your money. The app passes the request to a payment network, such as UPI in India or Visa and Mastercard for cards, and your bank approves it, debits your account and keeps the record. Every layer holds part of your data, and the bank can freeze the account, for example over missing identity checks or on a court order. Forget your PIN or password and the bank lets you reset it.

A Bitcoin wallet has no company in the middle. Your bitcoin is recorded on a public ledger that thousands of independent computers keep in sync, and only the holder of the private key can spend it. No bank approves the payment, no one can freeze it, and no one can let you back in if the key is lost.

The two flows below trace the same payment through each model, layer by layer.

Bitcoin wallets don't all work the same way either. They differ in who holds the keys, and that one choice decides what you back up, who can help when something goes wrong, and whether anyone can freeze your funds. There are four main models.

Custodial apps like Strike hold the keys for you and behave like a bank, so there is no phrase to lose. Self-custody wallets like BlueWallet and Phoenix hand the keys over, and with them the whole responsibility.

The handover is where things go wrong. It usually happens on a single screen, in the middle of setting up, when people are keen to get to the part where they can buy something.

A recovery phrase is a short list of ordinary words that is your wallet. The app on your phone is only a way to use it: whoever holds the words can rebuild the wallet, and spend from it, on any device.

With no company to fall back on, the whole wallet comes down to one secret. A Bitcoin standard called BIP-39 writes that secret as words: 12 or 24 of them, drawn from a fixed list of 2,048 and generated at random for each wallet. Every key and address in the wallet is derived from them. That list of 2,048 words comes back in Seed Sky, where it becomes the basis of a whole verification method.

Anyone holding the words (plus the passphrase, if one was set) can move the funds from any compatible wallet. Anyone who loses them has no reset link and no support line to call. In self-custody, a sheet of paper is the only spare key.

• Seed phrase
• Recovery phrase
• Mnemonic

Wallets, and this case study, use these names interchangeably. All three mean the same 12 or 24 words.

A passphrase is something else: an optional extra password, sometimes called the 25th word, that some wallets let you add on top of the phrase. With a passphrase set, the words alone open a different, empty wallet.

Making a phrase stronger is a deep topic. In short, it comes down to entropy: how much true randomness went into creating the words, and so how hard they are to guess. Wallets usually offer a few advanced options:

• 24 words instead of 12: 256 bits of randomness instead of 128.
• Shake the phone: the movement feeds extra randomness into generating the words.
• Roll dice: you create the randomness yourself, so you don't have to trust the phone's random number generator.
• Add a passphrase: not more randomness in the words, but a second secret on top of them.

• 
  StrikeIt is a custodial wallet, on Lightning and on-chain.Built to feel like a modern payments app for buying, sending and spending bitcoin. An account-based product: your bitcoin lives behind a login, not behind a seed phrase, because Strike holds and controls the private keys.
• 
  BlueWalletIt is a non-custodial, on-chain wallet.Open source and designed to expose Bitcoin's core mechanics without overwhelming the user, with advanced options such as multisig vaults and watch-only wallets. A key-based product: control begins with a seed phrase, not a login.
• 
  PhoenixIt is a self-custodial Lightning wallet.Built by ACINQ to make Lightning usable without manual channel management: it opens channels and manages liquidity automatically. A key-based product: you hold the seed phrase, while the network complexity runs in the background.

I walked through each onboarding and asked the same five questions:

• Q1When does responsibility shift to the user?
• Q2Is security explained, or only enforced?
• Q3Does the flow build confidence or break it?
• Q4Are Bitcoin concepts revealed or hidden?
• Q5Where does the cognitive load spike?

What each wallet asks of you and does for you, from the first screen onwards. Switch between them to compare. Don't forget to check the Essentials/Legends for understanding the Onboarding user flows.

Strike, BlueWallet and Phoenix are three of the best-known wallets in the Bitcoin space, and each sits at a different point on the custody spectrum. Walking through their flows side by side shows how each one treats custody: what it hands to the user, what it keeps, and how much of that it explains. That made it possible to take the strongest parts of each experience into the design of my own flow.

I walked through every screen of each wallet, from the first launch to its deepest settings, and asked the same questions at each step. Pick a wallet, then move through its flow part by part with the arrows or the line at the bottom. Numbered markers sit on the exact element a note is about, and dashed arrows show where a tap leads. Recorded walkthrough, personal data blurred.

My own walkthrough only shows one side of the story, so I went to the people using these wallets every day. I read reviews, ratings and support threads for all three apps, from app-store reviews to community forums, looking for the pain points they share and the ones unique to each.

The table below brings the whole analysis together. It answers the five questions I judged every wallet on, from when responsibility shifts to where the cognitive load spikes, so the three can be compared side by side in one place.

Many wallets, including both self-custody wallets I audited, treat the recovery phrase as a display step. The words appear, a checkbox asks if you saved them, and the app moves on. Checking the copy is optional, when it exists at all.

Beginners fill the gaps with what they know from other apps. They screenshot the words, paste them into a notes app, or assume the wallet can restore them later the way a bank resets a password.

1. 01Get the overall average of 90+% accuracy on the wallet for users when they verify the phrase.
2. 02Offer more than one way to verify, so each person can use the one that suits them.
3. 03Improve accessibility, error prevention and education at the exact step where they matter.
4. 04Make checking the phrase something a wallet can ask for again later, not only at setup.

The reviews and threads sorted naturally into three levels of experience. I wrote each up as a person, so the findings had a face when I came back to them during design.

I mapped each person from first motivation to how they felt about the wallet afterwards. The curves differ, but the low points line up: fees, channels and backups that nobody explained until they cost something.

None of the dips came from Bitcoin being hard. They came from the app doing something important without saying so. A recovery phrase fails the same way: nothing seems wrong until the day the paper is needed.

Some of these people are safe at the backup step: they already know the phrase's importance. The newcomer has neither. They meet the recovery phrase once, on one screen, mid-setup, and a mistake stays invisible until the day they need it.

Aman is who the flow is built around: a student with a first wallet freshly installed, keen to buy and send small amounts, with no patience for jargon or detours. If the flow works for Aman without a search engine, it works.

Lining each person up against the backup step kept me honest about who every decision served. I asked one question per person: at the backup step, what do they need, and what in the design answers it?

The project ended at a working prototype, so there's no launch data. This is the measurement plan I'd ship with: one north star, and a few signals that show where the flow breaks if it does.

The redesign turns that one screen into a sequence: learn, acknowledge, reveal, store, verify, seal. The checkpoints can't be skipped. The education around them can, for people who already know it.

I also wrote down how I wanted people to feel at each step, because the old flow left them rushed, confused and a little afraid.

Before any pixels I sketched the screens to settle the structure: what each screen asks, where the one decision sits, and how someone backs out.

I deliberately focused on getting the structure right rather than filling every screen. More feature cards, screens and settings can be added as the product needs them, but the design language had to be set here.

Creating a wallet leads straight into the backup. The phrase is explained, guarded by a disclaimer, revealed in private and stored offline before anything else happens.

Most loss starts with a wrong idea of what the phrase is. People assume it works like a password that can be reset, or that the wallet can recover it by email. So the explanation and the warning are separate screens, each with room to be read.

The disclaimer says it plainly: lose the phrase and nobody can restore access. Three illustrated rules follow, and nothing moves until the person ticks “I understand”.

Many people also don't take the phrase seriously and plan to screenshot it or keep it in a notes app, which is why the warnings get this much room.

The words stay blurred until the person presses and holds, so they never sit on screen by accident. The reveal screen asks whether anyone is looking over their shoulder, and offers advanced options (24 words, a passphrase, dice) for people who want them.

To continue, they confirm the phrase is stored offline and swipe instead of tap. It takes a second longer, which is the point.

A “back up to cloud” button is the easy win, and plenty of wallets have one. Digital copies leak through malware, syncing and shared galleries, and industry practice is offline storage, so I left it out.

Once the phrase is on paper, the wallet asks for proof that the copy is right. Nothing opens until one of four methods passes.

Verification is where the 100% goal lives. One method would have been simpler, but every single method shuts somebody out: typing is slow on small keyboards, voice fails in a busy room, small chips are hard with low vision.

So the hub offers four. Click & Make comes first because it's the most familiar, and Seed Sky sits below a divider so the new idea never crowds the known ones.

Hick's law says more options take longer to choose from. Offering four was a deliberate cost, paid so that no one is shut out.

People tap the jumbled words in the order they wrote them. Only the phrase's own twelve words appear, not all 2,048, which keeps the screen readable. The phrase is checked once, as a whole, when they press Verify.

A real restore picks from all 2,048 words. Showing that list during setup would swamp the screen and the person, so Click & Make shows the twelve words of this phrase, jumbled.

Word-by-word feedback feels friendlier, but it lets someone pass by trial and error: tap a word, see if it was right, try the next. That proves nothing about the paper. So Click & Make checks the whole order at once, allows three attempts, then locks the wallet for ten minutes. The only practical way through is the written copy.

The last screen doesn't just say done. It shows 12/12 words verified and an accuracy score, worked out from wrong attempts against correct ones. A 75% tells someone, gently, that their copy deserves another look.

Both results end with a cue to try the other methods, Seed Sky in particular, so the wallet's most distinctive feature gets discovered.

For confident users, and a good test of whether the handwriting is legible. The whole phrase goes into one field with a running 0/12 to 12/12 count. Nothing here touches the clipboard either.

Built for people with visual or motor impairments. They tap once and speak the words in order. The transcript stays hidden behind tap to view, and listening back plays through the earpiece only, so the room doesn't hear the phrase twice. Speech recognition has to run on the device, so the words never reach a server.

Speaking a phrase out loud can be overheard. Leaving voice out would have kept verification closed to people with visual or motor impairments, so it stays, with guards around it. When a screen reader is on, it first asks the person to make sure they are somewhere private before saying their recovery phrase aloud.

The fourth method, and a completely new one: verification by visual rather than by words. This is where the earlier groundwork pays off: an understanding of the problem space, the logic behind the feature, and the maths and implementation detail that shaped this design decision.

A list of twelve words is hard to check by eye, and the eye is exactly what people use when they glance at their backup. Shapes are easier. Seed Sky turns a phrase into a constellation that only that phrase can draw, so a wrong or swapped word breaks the picture.

The BIP-39 standard defines 2,048 words, each with a fixed index from 0 to 2047 and an 11-bit binary value, as the list below shows.

That list can be laid out on a grid by any logic we choose. So which logic? For security, the grid's exact structure stays proprietary, but it can combine several transformations, such as these.

The custom grid gives every word a coordinate. Together, a word's index, bit value and coordinate place it deterministically on the visual canvas.

Entering the phrase plots its words in order and joins them, so the path is unique to that phrase. A seeded scatter works best: it puts words that sit next to each other in the list far apart on the canvas, so even a near-miss like *about* for *above* moves a star visibly.

The sky shows only stars and lines: no words, no indices, no grid and no scale. On top of the base mapping, each wallet applies its own rotation, mirroring and phase shift, so how the 2,048 words were arranged can't be read off the picture, and neither can which point a star stands for. On its own, the drawing can't be turned back into words.

It is still derived from the phrase, though, so it is treated as sensitive: shown only during verification, never stored, synced or shared. It can't restore a wallet, only check one, and it works purely at the visual layer, so the BIP-39 standard underneath is untouched.

Over time people recognise their wallet by its shape. Once a security review confirms the transformation holds up, the constellation could become the wallet's avatar: a quiet reminder that the phrase exists and belongs to them, without ever showing it.

1. 01Test against the targets: these are design outcomes, not measured ones. The next step is a usability round with beginners and screen-reader users against the targets in Defining success, starting with first-attempt accuracy and drop-off between reveal and verify.
2. 02Instrument the funnel from reveal to store to verify, to see where friction turns into drop-off.
3. 03Let data shape the buttons: with real usage and average time per step, the button interactions can be refined. A back button already sits on almost every step, so a Continue button that carries no weight could go; in many places it does carry weight, so each call depends on the data.
4. 04Test at scale: usability testing so far was limited and closed. Large-scale A/B tests across persona cohorts would reveal far more.
5. 05Study accessibility in depth: the impact on accessibility, and how the flow works with screen readers, needs a more detailed study.
6. 06Finish the tertiary design: tooltip content, kebab-menu settings, interaction and information cards, adding entropy, the wallet recovery flow, biometrics before the phrase is revealed, and owner-voice recognition in the voice flow. Many decisions from this case study carry straight into interaction design.