TRADE-OFFS
Why merging tokens by name would have been dangerous
The obvious implementation is to group rows by ticker. It is also the one that gets people robbed: anyone can deploy a contract called USDT with the right icon, and symbol-matching would fold it into a real balance. Merging had to be a verification question, not a string comparison and that set the cost of everything else.
WHAT I CHOSE | WHAT I CUT | WHY |
|---|---|---|
Merge only verified contracts on verified chains | Merging by ticker symbol | A copycat contract must never inherit a real token's row. The cost is a maintained verification list, and a legitimate token on an unverified chain sitting apart until it is added. |
Chain on the token page and at transaction time | Chain as a navigation layer | Crypto-native users need the per-chain truth and deserve to get it. They just don't need to walk through it to reach their own balance. |
Cross-chain swap | Same-chain swap with a chain picker | One balance implies one swappable balance. A chain picker inside swap would have exposed the fragmentation the model exists to absorb, and pushed the complexity back onto the user instead of into routing. |
One entity and one rule for all five surfaces | A list design per feature | Five asset lists that each behave slightly differently is how a wallet becomes confusing without any single screen being wrong. |
MY CONTRIBUTION
What I owned on walllet's asset model
I joined walllet as its founding product designer. This was a model decision before it was a screen decision, cheap in month one, structural by month six.
WHAT I OWNED
The asset entity itself: aggregated balance, the network badge, and how rows sort. The merge rule and its boundary, verified contract on a verified chain merges, everything else keeps its own row. The token detail page as the per-chain source of truth. The points where chain re-enters the interface and what it must show when it does. And the written pattern that designers and engineers built against, so home, search, send, receive and swap render one list rather than five.
Chain never disappears. It stops being the way you navigate.
THE PATTERN
How the merged asset model behaves on each surface
Home: one row, one balance, one badge
Each asset is a single row with its combined balance. The badge next to the name carries the whole compromise: it names the chain when there is one, and reads as a network count when there are several. It never pretends an asset lives in one place, it declines to make that the user's problem on the first screen. Tapping through opens the token detail page, where the balance breaks out per chain.
Search: you find assets, not positions
Searching USDT returns USDT, one result, one balance, the row they already recognise from home. Returning three results for a token someone holds once in their mind teaches people the product is more complicated than their goal.
Send: asset first, then the chains that actually hold it
Choosing the asset comes first; the network sheet opens second and lists only the chains carrying a balance, each with its own amount and estimated fee, cheapest marked. This is the model's argument in miniature: the chain question still gets asked, but by then it is a comparison rather than a quiz.
Receive: the same entry point
Receive starts from the asset too, so the mental model holds in both directions rather than reverting to a chain menu the moment money comes back the other way.
Swap: a merged balance behaves like one balance
Swaps route across chains the way they do on an exchange. Someone swapping USDT for ETH picks two assets, not two networks, and the routing resolves where each side sits. Had swap required both sides on one chain, the merged balance would have been a promise the product broke at the first interesting moment.