02 — Email Recovery
High-stakes recovery that feels like resetting a password.
About
Gnosis is a fully self-custodial wallet. There are no seed phrases, no recovery cards, no support team that can reset your account. When users lose access, it is catastrophic and traditional Web3 recovery options ask people to manage a 12-word phrase they will inevitably misplace.
We decided to use email as the primary recovery method, so my job was to make this flow feel as simple and familiar as any mainstream ‘reset access’ experience, while under the hood it’s doing something quite complex on-chain.
Role
Senior Product Designer
Team
Recovery & Security
Challenge
Self-custodial recovery without seed phrases
01 · TECHNICAL & Emotional safety
Two main challenges
Technical: My idea wasn’t the feature, it was the experience. Engineering defined what was technically required. Big shoutout to Johanna, our Web3 engineer, she basically owns that flow. There was no product spec. Only a 200-comment research novella from Web3 engineers, because our PM was on parental leave for 3 months I had to be my own PM.
Engineering and Growth (stepped in for our PM) spent weeks debating options: ZK-based recovery, social recovery, different vendors like Privy, Turnkey and Cometh. They eventually aligned on a guardian-based pattern with a cooldown delay. Basically, a smart-contract module that lets a trusted guardian switch owners after a 72-hour delay, with a way to cancel if it was malicious.
The other constraint was emotional. That's where my job started. I read through the whole research to pull out the non-negotiables:
· self-custody, no seed phrase
· long cooldown and cancel option
· email as the identification channel
· recovery should work for 'normies', not just crypto-savvy users.
I designed how it should feel: predictable, safe, and familiar. Users come here already stressed. Guardian recovery is too technical for our target audience, and they just want back into their wallet. Any mention of ‘transactions’ or ‘funds’ could easily trigger panic.
02 · Designing for Trust Under Passkey Risk
My role
I was the designer responsible for turning all of this into a coherent, user-facing flow. I started by mapping every state, every path, every edge case, including what happens if someone logs in with the old passkey, with the new one, or from a malicious attempt. From there I designed the flow, validated assumptions with engineers, and made sure to add clear warnings and offer support.
03 · When things go wrong
Troubleshooting that doesn't blame the user.
Troubleshoot first: Before starting a full recovery, I gently walk users through basic checks and offer support contact. This prevents unnecessary recoveries and reduces support load.
I mapped the entire recovery state and disussed in in a call with all engineers and quickly realized they love to over-engineer things.
I wanted Simple mental model: The visible flow is deliberately Web2: ‘Trouble logging in?’ → troubleshoot → enter recovery email → OTP → 72 hour security cooldown → activate new passkey → success. One obvious next step at a time.
What happens after OTP? There are 3 branches. Next is the "recovery not yet started" branch. I needed to structure Figma very clearly for dev hand-off, so there wouldn't be any misinterpretations.
04 · First Branch
Recovery not started
3 main branches: Not started / in progress / cooldown complete
Here I explain 72-hour timelock and show countdown
Old passkey continues to work during cooldown
User can cancel recovery any time if they suspect abuse
I won't show you the 2nd branch because recovery in progress is simply the last screen you see here, but let's move to the next branch to see what happens after the cooldown.
05 · Third branch
Cooldown complete
This is the branch after the 72h cooldown
The old passkey does no longer work and the user has no other choice than to activate their new passkey.
Here engineers originally wanted an extra screen to justify a second on-chain transaction with ‘no funds are being moved’. I pushed back, because introducing blockchain language in the middle of a simple recovery flow would create confusion and fear. We agreed to trigger that transaction behind the scenes, even though it was more work technically.
Quick success confirmation
What happens though when there is a malicious attempt? The new passkey someone else has and what does the user see when they log in with their old passkey?
05 · Edge case
User logs in with old passkey
If the user logs in with their old passkey during recovery, in case they accidentally find the old passkey again or during a malicious attempt:
They can cancel the recovery immediately.
If the user logs in with the new passkey, cancelling is not possible. The new passkey only exist in their password manager and is not yet finalized on-chain.
There is no way for us to detect, if the new passkey is the Safe account owner.
Deliberate UX decision not to allow access to the app, I wanted a decision from the user. Either user waits 72h or cancel the recovery.
Key Design Decisions
'Forgot password' not 'seed phrase'
Six familiar words moved this from a feared feature to one users explain to friends. Language is the design.
Troubleshoot before you recover
Walk users through basic checks first; offer support contact. Prevents unnecessary recoveries and reduces support load.
Persistent cancel during cooldown
The visible cancel button catches the majority of recoveries that turn out to be the original user finding their device.
Hide on-chain transactions, don't explain them
Pushed back when engineers wanted an extra screen justifying a second on-chain transaction. Triggered it behind the scenes instead.
Outcomes & Learnings
01
Recovery completion rate jumped after replacing seed-phrase language with "forgot password" framing. Users stopped abandoning the flow.
02
The visible cancel button caught the majority of recoveries that turned out to be the original user finding their device. Exactly as predicted.
03
Key learning: in high-stakes flows, language is the design. Six familiar words moved this from "feared feature" to "feature users explain to friends."