Cutting swap failures by 40% in 90 days
A crypto wallet is only as good as its worst transaction. A teardown of the swap funnel in a 35,000-MAU wallet, the experiment plan that followed, and what moved the number.
- Role
- Product Owner, wallet core: swap, buy, onboarding
- Scale
- 35,000 MAU · 5,000 DAU
- Outcome
- −40%swap failure rate in 90 days
- Proves
- Growth sense, prioritisation, working from data
01Context
Best Wallet is a self-custody, multi-chain consumer crypto wallet. I was Product Owner from May 2025 to January 2026 as an independent contractor, owning strategy and roadmap across transaction flows, onboarding, payments and token discovery, with engineering, design, marketing and support in a Scrum setup.
Swaps were the core monetised action. Every failed swap was lost revenue, a support ticket, and a user deciding whether to trust us with the next one.
02Problem
User pain. A swap that fails in a self-custody wallet is uniquely bad: the user may still have paid gas, the error usually says nothing useful, and there is nobody to call. Support tickets about stuck or failed swaps were the single largest category.
Business pain. Swap success rate sat directly under revenue and under retention. But the team had no shared number for it, no alert when it moved, and no way to tell a routing problem from a UX problem from a congested chain.
03Approach
Instrument first. I implemented end-to-end event tracking across the swap, buy and onboarding funnels with Amplitude and Segment, and made swap success rate one of the product's North Star metrics next to DAU/MAU and activation.
Then take the funnel apart. Failures were segmented by step (quote, approval, signing, broadcast, confirmation), by chain, by route and by error type, then cross-read with support tickets to separate what users felt from what the logs said.
| Hypothesis | Bet | Call |
|---|---|---|
| Routes go stale between quote and execution | Overhaul routing logic and re-quote behaviour | Biggest share of failures. Do first. |
| Transient errors kill recoverable swaps | Resilient error handling and state management | Cheap, compounding. Do with the first. |
| Congestion strands transactions | Manual gas, speed-up and cancel | Validated by user research and tickets. Second wave. |
| Users misread slippage and amounts | Education and copy | Real, but small. Parked. |
04Decision
We shipped three things, in that order: an overhaul of transaction routing logic; resilient error handling and state management so a recoverable failure recovers instead of dying silently; and advanced transaction controls (manual gas fee configuration, speed-up and cancel) for high-traffic moments.
Around them, the operating layer: KPI dashboards and alerting so a regression is caught by us before it is reported by users, and a standing loop with customer support to debug production incidents from event data and fix the systemic cause rather than the ticket.
05Outcome
Fewer congestion-related failures during high-traffic events, a lower repeat-incident rate, and A/B tests running continuously on activation and conversion once the tracking existed. In the same period I led go-to-market for the Solana integration and delivered an AI support chatbot on Intercom for self-serve support.
What surprised me. How much of a 'blockchain problem' was a state-management problem. A large share of failures were swaps that would have succeeded if the app had simply waited, retried or re-quoted.
06Reflection
I would have set up the alerting before the analysis, not after. For the first weeks we were studying a number that could move without anyone noticing.
And I would split 'failure' into user-visible and silent failures from day one. The 40% is a blended number; the user-visible half is the one that drives trust.