Hippo WalletCrypto & fintech2024
Nine steps to one, and $3M moved in a quarter
Hippo Wallet had 42,000 monthly users, no transaction revenue, and a retention problem it had diagnosed as a marketing issue. It was a product gap: users were leaving the app to move money, and the fix opened a revenue line that did not exist before.
- Strategy
- Pricing
- Unit economics
- $3M
- Moved in the first quarter
- −83%
- Faster per transaction
- 22 pts
- Retention gap vs non-users
Context
Hippo Wallet is a crypto wallet holding assets across fourteen networks, with about 42,000 monthly users at the time. Non-custodial, which means the company never touches customer funds and a customer mistake is permanent.
The founders brought me in on a retention problem. Users signed up, funded the wallet, then went quiet. The working theory was acquisition quality, and the plan on the table was a paid campaign to buy better users.
I asked to look at the support inbox before anyone spent money on ads.
The challenge
Two quarters of tickets described the same afternoon. Users could hold assets on fourteen networks but could not move between them, so they had invented a workaround: send funds out to an exchange, trade there, then send the proceeds back by hand. Nine steps, three separate fees, two waiting periods, and one irreversible action — pasting their own wallet address for the destination chain.
I ran that route as a timed exercise with nine users on their own wallets. Median nine minutes and forty seconds of active work, up to an hour end to end, and roughly 2.9% of the amount lost to fees on a $500 transfer. Two of the nine pasted the wrong thing. In a test with small amounts that is an anecdote. With a real balance it is unrecoverable.
The commercial consequence was the part nobody had priced. Every one of those nine steps was revenue leaving the business. Users were paying exchanges two to three percent to perform a transaction the wallet could have performed itself, and the wallet was earning nothing on any of it.
Approach
- Weeks 1–3
Diagnosis
Support-ticket analysis, twelve user interviews, a 340-response survey, and a timed benchmark of the workaround. The output was a sizing of the leak, not a feature list.
- Weeks 4–5
Partner selection
Evaluated aggregators and exchange providers on coverage, settlement speed and commercial terms. Landed on two rather than one, so no single partner could hold the feature hostage.
- Weeks 6–9
Scope and pricing
Defined what shipped in version one, what waited, and what the wallet would charge. Two rounds of testing on a real build before the commercial terms were fixed.
- Weeks 10–14
Staged release
Five percent, then twenty-five, then full, with a per-partner kill switch and a pre-agreed definition of success.
The decision I pushed hardest on was deleting a field. The engineering proposal included a destination address input with a validation warning. I argued that the warning was the problem: the wallet already knows the customer's address on every chain it supports, so the question should never be asked. Sending elsewhere became an advanced option behind its own confirmation. That removed the entire category of permanent loss, which was the thing actually suppressing usage.
The second was pricing. The market standard for this service is around 0.85%. I argued for 0.15%, and for a rule rather than a number: the wallet's fee must stay smaller than the cheapest single line item of the route it replaces. Exchange withdrawal fees are flat, typically $3 to $8, so at 0.15% a customer has to move more than $2,000 before our cut matches even the smallest of them. No arithmetic a sceptical user performs on the confirmation screen can make the old route look better. That was the bar, and it cost us roughly five-sixths of the available take rate on purpose.
Results
- $3M
- Moved in the first quarter
- 9.4%
- Monthly actives using it by month three
- 61%
- Retention, users who transacted
Three months after release, with no paid acquisition behind it: $3M moved, growing from $410K in the first month to $1.57M in the third. Average transaction size settled around $210, which confirmed ordinary customers rather than a handful of large accounts. Time to complete fell from nine minutes forty to one minute thirty-six, and all-in cost on a $500 transfer from about 2.9% to 1.2%.
Fee revenue was $4,500 in the quarter — a $28,300 annual run rate on a line of business that had not existed, and one that costs nothing incremental to operate. That does not repay a fourteen-week build, and it was never modelled to inside one quarter. What the quarter bought is a working rail and a priced lever: the same volume at the market rate would be worth about $160,000 a year, and the rate is the one variable that moves without rebuilding anything.
The number that settled the original question was retention. Customers who completed at least one transfer retained at 61% over thirty days against 39% across the wallet. The problem was never acquisition quality.
We were about to spend the quarter buying users who would have churned for the same reason the last ones did.
What I'd do differently
I let the team define success as shipping. The rollout plan had a launch date and a failure threshold, but no adoption target, so the first month passed with everyone satisfied by a clean release while a measurable share of users opened the feature, looked at it, and left without transacting. Those were newer customers who did not understand what it did. A short explanation added in week nine recovered part of it, but I should have insisted on an adoption number before the build started, not a launch date.
I would also open the pricing conversation in week one rather than week six. By the time I proposed 0.15%, the founders had spent a month quietly assuming the market rate, and the argument cost more political capital than it needed to. The reasoning was sound and it held, but I was defending a reduction rather than framing a decision, which is a worse position to negotiate from.