Desktop-first onboarding for a browser wallet
Razor Wallet is a browser extension wallet for the Movement blockchain. The redesign focused on reducing friction without softening the security steps that make a non-custodial wallet trustworthy.
Web3 wallets often ask people to make three high-stakes decisions before they have a real sense of the product: accept terms, create a password, and store a recovery phrase. The original Razor Wallet flow had more steps than it needed, which gave users more chances to drop off.
The goal was to cut the flow down, keep every security requirement, and make each screen feel clear instead of intimidating.
The standard wallet onboarding pattern asks too much too early. Users are expected to agree to terms, create a password they cannot recover, and write down a 12-word phrase that controls access to their funds before they have had a single meaningful interaction with the product.
For a devnet launch aimed at developers and early adopters, that means every abandoned sign-up is a lost signal. For a mainnet launch aimed at general users, it becomes a lost customer.
Most wallets bury the reason for each step in a help article no one reads. This redesign puts the explanation beside the action, on the same screen, at the moment the user needs it.
| Screen | Purpose |
|---|---|
| 1. Splash - Terms of Service | Entry gate with legal acknowledgement |
| 2. Welcome - Wallet Choice | Route returning vs new users |
| 3. Create a Password | Security layer 1 - local access |
| 4. Secret Recovery Phrase | Security layer 2 - wallet ownership |
| 5. Congratulations | Confirmation and entry into the product |
The first screen establishes the product identity and gates entry behind a single consent action. It is almost entirely negative space: brand, one sentence, one checkbox, one CTA.
That is deliberate friction. The checkbox forces an active acknowledgement instead of a passive scroll-past, but nothing else competes for attention.
The copy matters here because the buttons are really user self-identification statements. A returning user should know instantly which path is theirs; a new user should feel clearly invited to continue.
The main weakness in the current draft is tone. The screen works, but the body copy leans too far into marketing language for a flow that is otherwise plain and functional.
This is the first moment where a user might pause and ask why the product needs more from them. The layout answers that question without forcing them into a separate help screen.
The left panel handles the action. The right panel handles the explanation. That separation keeps the screen calm, readable, and easy to scan.
This is the most consequential screen in the entire flow. The design has to avoid both extremes: warning overload and under-explaining the risk.
The structure returns to the same two-panel layout, which gives the user visual familiarity after Screen 3. The left panel handles the phrase. The right panel answers the actual questions people have in the moment.
The final screen closes the loop, confirms success, and gives the user one clear way forward. The Razor logo appears here as a reward signal after the effort of the setup flow.
The CTA should stay final and simple. Done works better than any eager onboarding language because it ends the chapter instead of opening a new one.
The redesigned flow launched on devnet.
The result was a five-minute reduction in average onboarding time without removing any of the security steps that make a non-custodial wallet trustworthy.
Devnet users are not casual. They have seen enough wallets to recognise bad onboarding quickly, which makes the numbers here meaningful.
Security and simplicity are not opposites in Web3 onboarding. The better question is whether you explain the why at the right moment, on the right screen, in plain language.
A few extra mascot explorations from the Razor world, kept here as a small visual appendix after the case study.
