Pali Wallet — the first UTXO + EVM browser wallet

Pali is the only browser extension wallet that supports UTXO, the transaction model Syscoin’s native chain runs on. For thousands of users, it’s the only way to move SYS without relying on a desktop app or going through an exchange.

When I joined, v2 had just launched. It had shipped support for EVM-compatible networks, a major capability leap, but it had also shipped a lot of bugs. User confidence was low. And in the background, a hard deadline from Google was counting down.

---

Fixing the team first

The team was small, smaller than Luxy, with a tighter scope. Which meant the process fixes were faster, but no less necessary.

Same playbook: I introduced structured 1:1s, sprint planning and reviews, clear ownership per engineer, and regular syncs between frontend and the backend services the wallet depended on. With a smaller group, the effect was quicker, within a few months the team had a predictable cadence and engineers had clarity on what they were responsible for.

That foundation mattered a lot for what came next, because what came next required months of focused, parallel execution.

---

The v2 problem

Pali v2 had added EVM support on top of the existing UTXO layer, bridging two fundamentally different transaction models in a single browser extension is a non-trivial engineering challenge. The implementation had gaps. Users were hitting bugs on basic flows: sending transactions, switching networks, connecting to dApps.

In any space, bugs are more than UX friction, they erode user trust fast, and trust is the entire product. We needed to stabilize v2 without waiting for the MV3 migration to be complete, which meant running two workstreams simultaneously.

We systematically went through the issue tracker, triaged by severity and frequency, and worked through the most damaging bugs first. Session by session, the stability improved.

---

The MV3 deadline

Chrome’s Manifest V3 migration was not optional. Google had set a deadline for all extensions in the Chrome Web Store to migrate away from the older Manifest V2 architecture, and missing it meant removal from the store. For an extension that thousands of people depended on, that was not an acceptable outcome.

For context, the Manifest V3 isn’t a configuration change. It’s a different extension architecture: background pages become service workers, network request modification APIs changed entirely, the permission model shifted. For a wallet, which has persistent state, active connections to dApps, and security-critical flows, this meant a significant rewrite across frontend, background services, and content scripts.

We had months and no guideline or other project that “has done it before” we could look up towards. Google itself had sparse documentation on how to do things, and there was a lot of trial and error during the process. We mapped the full scope, broke it into workstreams, and made the call to bring in a more experienced technical lead to anchor the engineering side. Hiring the right person mid-project is a judgment call that’s easy to delay; I made it early, and it made the difference in holding the timeline.

The migration shipped. The extension stayed live through Google’s deprecation window.

---

Mobile

Alongside the browser work, I spun up a mobile team from scratch and shipped Pali Mobile as a greenfield product, bringing the EVM wallet experience to iOS and Android. UTXO remained a feature in the roadmap long after the team was disbanded.

Starting a new team while managing a complex migration on the browser extension required clear separation of concerns: different standups, different priorities, different risk profiles. Mobile was greenfield: move fast, ship, iterate. Browser was critical infrastructure: move carefully, test everything, don’t break what people depend on.

---

Outcomes

• 22.2k downloads, 11k+ weekly active users
• MV3 migration shipped on deadline — extension remained live throughout Chrome’s deprecation
• v2 (and then v3) significantly stabilized; user sentiment recovered
• Pali Mobile launched on iOS and Android

---

What I learned

Stability is a feature, and it’s undersold. The v2 launch prioritized capability (EVM support) over reliability. In a wallet, that’s a dangerous trade. Users will forgive a missing feature. They won’t forgive losing funds or failed transactions. We spent months paying back that debt, time that could have been spent on new capabilities if the launch bar had been higher.

Hiring ahead of the problem is almost always the right call. I brought in a senior tech lead mid-project because I could see the MV3 scope was larger than the existing team could absorb cleanly. That decision felt expensive in the moment. In retrospect, it bought the timeline.

Running two teams with different tempos is a skill. Mobile and browser extension operated at different speeds by design. The discipline is resisting the urge to unify them. They had different constraints, different risk profiles, and different definitions of “done.”