TRADE-OFFS
What being an EVM-only wallet forced me to cut
Two constraints shaped everything. We supported EVM chains only, so I could detect that a destination address belonged to a different chain type but could not offer to bridge to it; the flow had to stop and explain rather than solve. And fee abstraction depends on a paymaster being available on that chain, which is not guaranteed, so every fee decision needed a fallback that does not read as failure.
WHAT I CHOSE | WHAT I CUT | WHY |
|---|---|---|
Asset first, network second | Chain-first navigation | Chain-first asks a question the user can't answer. Asset-first asks one they can, then narrows the networks to the ones where they actually hold a balance. |
Fee in dollars, paid in the token being sent | Gwei and gas-limit controls | Nobody arriving from a neo-bank has ever wanted to tune a gas limit. Advanced control was deferred behind the fee row, not designed away. |
Amount and fee computed together | The insufficient-balance error at signing | An error the system can prevent shouldn't become a screen the user has to read and recover from. |
Six labelled address states | A binary safe / unsafe badge | A binary badge makes "we don't know" look like "danger", and a warning that fires on every ordinary send is a warning people learn to dismiss. |
Trust check on the receipt | Transaction hash and explorer link | Receipts get forwarded to people who may not own a wallet at all. A 66-character hash is proof only to someone already fluent. |
MY CONTRIBUTION
What I owned on walllet's send flow
I joined walllet as its founding product designer. This was zero-to-one, no previous version to improve on, no house pattern to inherit. I worked end-to-end with the product lead and the wallet and mobile engineers, from the flow model to production specs.
WHAT I OWNED
The flow structure. asset, network, address, amount, checkout, receipt and the merged asset model that aggregates one token's balance across chains before the user ever meets the word "network". Network recommendation from the destination address type. The amount-plus-fee calculation and the behaviour of Max. The checkout fee model: dollars instead of gwei, the paymaster line, the exact-shortfall top-up. The six-state address taxonomy and every word of its copy. The receipt, Trust check, and the shareable transaction image.
An error the system can prevent should never become a screen.
DESIGN DETAIL
The five design decisions behind walllet's send flow
1. One list of assets, not one list of chains
The list opens on what the person owns. USDT is a single row with a combined balance, tagged with the number of networks it lives on. Only after choosing it does the network sheet appear and it shows only the chains where that balance actually exists, each with its own amount and estimated fee, with the cheapest one marked. The chain question still gets asked, but by then it is a comparison, not a quiz.
Asset first with an aggregated balance; network second, scoped to the chains holding that asset.
2. Contacts, so most sends never touch an address
Pasting a 42-character string is the least safe step in crypto and the one every wallet treats as normal. I designed contacts the way Revolut treats payees: a saved name, an avatar, a truncated address, your own wallets grouped separately, and exchange deposit addresses carrying a verification mark. Scan and paste stay one tap away for the first send to anyone new.
Contacts first, manual entry second; with the leading and trailing characters weighted so a visual check is possible.
3. Six things an address can be
Instead of judging an address safe or unsafe, I labelled what we could actually observe about it and let the user draw the conclusion. Known and verified addresses reduce hesitation on routine sends. New and first-time addresses add friction exactly where it belongs. Reported addresses are the only red state, which is what keeps red meaningful. The labels sit inline on the checkout, next to the address, with a tooltip in plain language, no modal, no confirmation gate.
Six states, one red. Warnings only stay useful if they stay rare.
4. A fee you can read, paid with what you have
The checkout quotes the fee in dollars and names what it is paid with, because a paymaster lets the fee come out of the token being sent, the same reason nobody at an exchange is asked to keep a separate balance for withdrawals. Amount and fee are calculated together, so Max fills in a number that already clears. When it doesn't clear, the checkout says the amount was adjusted rather than silently changing it; when the paymaster can't cover the chain, it offers the exact top-up needed instead of an error.
Fee in dollars, included in the amount, with the adjustment disclosed and the shortfall solved in place.
5. A receipt the receiver can read
Receipts leave the app. Someone sending a freelance payment screenshots the confirmation and posts it to the person waiting, who may have no wallet and no idea what Etherscan is. So the receipt drops the hash and gives both sides Trust check: a walllet-hosted verification page and a QR code, sitting next to the status, the time and the fee. The shared image carries the same blocks, which makes verification and distribution the same object.
Trust check replaces the transaction hash; the receipt has to work for someone who doesn't own a wallet.