In 2022, a researcher documented the MetaMask onboarding flow step by step:
Step 1: Install extension
Step 2: Create password
Step 3: Write down 12-word seed phrase
Step 4: Confirm seed phrase in random order
Step 5: Figure out how to acquire ETH for gas
Step 6: Navigate to the app
Step 7: Connect wallet
Step 8: Encounter popup showing 0x095ea7b3000000000000...
Step 9: Decide whether to sign
Nine steps before the first real action.
No explanation of what a seed phrase is. No indication of what gas costs. No preview of what the app will do once connected. This flow was documented, criticized, and known internally — and it persisted for years because no one owned it.
This is the audit that never gets run before launch.
What smart contract audits do not cover
The standard Web3 launch checklist is built around one failure class: protocol failure.
| ✅ Covered by standard audits | ❌ Not covered |
|---|---|
| Smart contract vulnerabilities | First-visit conversion failures |
| Tokenomics exploits | Trust gaps before wallet connection |
| Security review | Error states that were never designed |
| Legal compliance | Mobile breakpoints |
| Oracle manipulation | Empty states that explain nothing |
Georgios Konstantopoulos, CTO of Paradigm, has written about the gap between protocol quality and interface quality. The most technically sophisticated protocols fail at the interface layer because the team was built to ship contracts, not experiences.
The fix is a structured walkthrough before launch. It takes less than an hour and consistently surfaces problems that internal teams miss — because internal teams already know how the product works.
The counterargument: ship fast, fix later
There is a real case for launching with known UX problems. Move fast, get real feedback, iterate. This is how most successful Web2 products were built.
The counterargument in Web3: first-session failures are more expensive.
In a SaaS product, a confused user closes the tab and comes back tomorrow. In a Web3 product, a confused user at the signature step may:
- Lose funds with no recovery path
- Authorize something they did not intend to
- Permanently associate the product with being unsafe
The audit is not about perfection. It is about catching the specific failure modes that destroy trust before the product has a chance to demonstrate its value.
How to run it
Step 1 — The three-second test
Open the landing page. Look at it for three seconds. Close it. Write one sentence: what does this product do?
❌ "A decentralized liquidity coordination layer for next-generation asset primitives"
✅ "Deposit stablecoins, earn variable yield, withdraw anytime unless a pool is locked"
Run this with someone outside the team. Their sentence will be more accurate than yours.
Step 2 — The requirements test
Before connecting a wallet, answer as a new user:
- What chain does this run on?
- What do I need to get started?
- Can I explore without connecting?
- Where is the audit report?
If any answer is unavailable before wallet connection, it needs to be on the page. Do not let the first error message do the explaining.
Step 3 — The connection moment test
Look at what is on screen before the wallet popup opens.
Most apps: [Connect Wallet]
Better: You're connecting read-only.
No funds will move until you deposit.
Works on Ethereum and Base.
[Connect Wallet →]
The wallet connection is not a button. It is a trust checkpoint.
Step 4 — The signature test
Perform the first real action. Then ask:
- Did the app explain what the wallet would say before the popup opened?
- Did it confirm what changed after signing?
- If the transaction was rejected, is there a clear recovery path?
Most products get the success state right. Almost none design the failure state.
Step 5 — The risk test
Find the most dangerous action in the product. Ask:
- Does the risk appear before the action — not after?
- Is it specific or generic?
❌ "DeFi involves risk"
✅ "You may be liquidated if ETH falls below $2,400"
- Can a user complete the action without understanding the consequence?
If the last answer is yes, that is a design problem — not a disclaimer problem.
Step 6 — The error test
Break something intentionally. Enter an invalid amount. Submit with insufficient gas. Try to withdraw more than deposited.
❌ Transaction failed
❌ Error: execution reverted
❌ Something went wrong. Please try again.
✅ Not enough ETH for gas. Current cost: ~$8 (45 gwei). Add ETH to continue.
✅ Amount exceeds your balance of 234.5 USDC.
✅ Bridge is congested. Your funds are safe — try again in a few minutes.
Step 7 — The mobile test
Open the product on a phone.
- Does it load without errors?
- Are all buttons at least
44pxtall? (Apple HIG / WCAG 2.5.5 minimum) - Can you complete a transaction without zooming?
For a growing segment of users — especially outside North America — mobile is the only platform. If the mobile experience is broken, a significant portion of the potential audience never converts.
Step 8 — The second visit test
Leave the site. Come back the next day.
- Do you know where you left off?
- Is your position, reward, or balance visible within three seconds?
Retention is a design problem, not just a product problem. The interface should make returning feel valuable.
What this audit catches
Running these eight steps consistently surfaces:
- Conversion failures that happen before wallet connection
- Trust gaps that no security audit covers
- Error states that were never designed
- Missing mobile breakpoints
- Empty states that say nothing useful
None of these require a redesign. They require specific fixes to specific flows — usually days of work, not weeks.
Most Web3 launches ship with several of them unaddressed. The ones that do not are the ones that convert.
What this means practically
- Run this with a non-technical person, not a team member. The team knows too much to find the real problems.
- Start from zero each time. Disconnect the wallet, clear cache, open incognito.
- Prioritize failure states over success states. Success states are usually designed. Failure states are afterthoughts.
- Treat mobile as a primary target — not a post-launch optimization.
- Schedule the audit before the announcement. Fixes require time that does not exist after launch week.
A protocol can be airtight and still lose users at the first wallet popup.
The audit that matters most is the one nobody schedules.
I work as a Web3 creative director helping crypto teams catch interface failures before users do. somaryuu.xyz











