PaymentsPay by Sovren · Shipped 2026
A new wallet in four weeks.
I was tasked with opening Pay to more chains and a card. The wallet was built on one token, so every feature meant custom chain work. I bet the rebuild on Privy, which Stripe bought, kept our login and event stream, and prototyped the app before the spec. Production took four weeks, against a six-month estimate.
Pay was built around one token, so every new rail meant rebuilding the wallet.
When you created a Pay account, you were really creating a wallet on the SOVR chain. That was the whole architecture. It worked while SOVR was the product. It stopped working once we wanted Pay to be an open wallet: hold USDC on Base, move between chains, spend from a card. Every one of those meant custom chain work on our side, and we'd be maintaining it forever.
Patching it wasn't going to get us there. The wallet layer had to be rebuilt without losing the 35% DAU/MAU we had moved it to.
Keep the login, keep the event stream, keep the chain. Replace the wallet underneath.
This wasn't a clean-sheet app. Pay sits inside the Sovren ecosystem with the social app and the other products, so three things couldn't move:
- Identity. Same IDP login, so an account on the social app is still a Pay account.
- Events. Same CDP event stream, so everything Pay does still shows up across the ecosystem.
- The chain. SOVR holders, and the features they used, had to keep working.
Inside those lines we rebuilt it from scratch. New wallet infrastructure, new app, new UI.
Privy, because Stripe owns it, and Stripe is one of the biggest payment rails in the world.
The whole rebuild rested on one assumption. Privy makes embedded wallets. You sign in and a wallet is created for you, with no seed phrase and no separate wallet app. Stripe announced it was acquiring Privy in June 2025, a few months after closing on Bridge, its stablecoin infrastructure company. At the time Privy was running more than 75 million accounts across over 1,000 teams.
My bet was that a wallet owned by Stripe would stay open, keep getting connected to new rails, and still be around in five years. That mattered more to me than any single feature. If our wallet layer plugs into Stripe, we get what Stripe builds next without re-architecting again.
It also covered the near-term list. Privy wallets run on Ethereum and EVM networks like Base, plus Solana and others. Swaps run on the same chain or across chains. Cards spend stablecoins straight from the wallet, with Bridge handling identity and funds and Stripe Issuing creating and authorizing the card.
- Situation
- We needed a wallet layer that was multi-chain now and would keep growing without another rebuild.
- Call
- Build on Privy, with Stripe's ownership as the reason it lasts.
- Cost
- Our roadmap leans on a vendor's roadmap. If Stripe changes direction on Privy, so do we.
I pulled down our existing code, swapped in Privy, and had a working prototype in days.
This is where it moved fast. I took the existing Pay codebase and used AI to replace the wallet architecture with Privy. I had a working app on the new infrastructure in days. I didn't wait on a spec to get there. The prototype was how we found out what the spec should say.
With the wallet working, I rebuilt the UI around what Privy made possible: swapping tokens across chains, issuing debit cards, paying a request in one tap. And I brought the design up to date with Apple's Liquid Glass.
The PRD and technical requirements came out of the prototype, and each round took days.
Because I could change the working app myself, review rounds took days instead of weeks, and we ran more than ten of them. Someone would push on a screen, I'd change it, and we'd look at it again the next day. Then I wrote the PRD and technical requirements from what the prototype proved and reviewed them with engineering, so they got a spec that already matched a working app.
The second round is a good example of what that loop caught:
- Glass came off the content. It stayed on the tab bar, header and action bar. Cards went solid so balances were easy to read.
- Assets got grouped by network. You can see what's on Sovren, what's on Base, and what a third-party custodian holds.
- Send became three labeled steps, a review and a receipt. Sends on chain can't be reversed, so the review screen is there on purpose.
- Paying a request became one tap and Face ID.
- Markets came out of the first release.
Not every SOVR feature fit in the new app, so the old one stayed up on the web.
This is the part that didn't work the first time. The requirement was to keep every existing SOVR feature in the new product, and the new product wasn't built around SOVR anymore. Carrying every chain-specific feature over would have pulled us right back into the custom chain work we were rebuilding to get away from, and put the four weeks at risk.
So we didn't carry them all over. The original codebase stayed live on the web for a period, with access to everything it did before. Our blockchain users are technical, and a web app for those features met their needs.
- Situation
- Full SOVR parity in the new app would have meant rebuilding the chain-specific work we were trying to leave.
- Call
- Ship the new app without those features and keep the original app running on the web for a period.
- Cost
- Two codebases running at once, and some users going to the web for things they used to do in the app.
First meeting to production in four weeks.
Four weeks from the first meeting on the project request to a new Pay app in production. The original estimate was three months to testing and six months to production. It shipped with seven engineers and two QA. Same login, same event stream, SOVR still supported, and a wallet that now runs across chains, swaps between them, and spends from a debit card.
The speed came from the order we did things in. The working prototype came before the spec, so most of the debate happened on a real app, and each round took days.
The bet, the prototype, the design, the spec, the migration plan.
Mine
- Choosing Privy, and the case for it.
- What had to stay (IDP, CDP, SOVR) and what could be rebuilt.
- The AI prototype on our existing code.
- The new UX and every round of changes.
- The PRD and technical requirements.
- Keeping the original app on the web for SOVR features.
Not mine
- Privy's wallet infrastructure, and the card program behind it.
- The IDP and CDP services.
- The production build: seven engineers and two QA.
Whether the bet holds for years, and what people do with it.
The Privy bet is a long-term bet, and four weeks doesn't settle it. It proves we could get onto Stripe's wallet stack fast. Whether Stripe keeps Privy open and keeps connecting it to new rails is the part we'll know in a couple of years.
Shipping fast says nothing about usage yet. I don't have numbers on how many people swap across chains or use the card.
The web fallback worked because our SOVR audience is technical. I wouldn't count on it with mainstream users, who won't go find a second app.
The number I'd want first: the share of active wallets that use a second chain or the card in their first 90 days.