Designing stablecoin wallet infrastructure from 0 to $450M+ TPV

Founding Head of Product & Design/2024 - Present
tldr;

Overview

I built Blockradar as a team of 3 at the stage where the "product" was just an idea. Stablecoins could be the most practical financial rails for emerging markets, but only if we could make them feel normal. My job became turning that conviction into a system global fintech companies could actually trust with money, by shaping the product from first principles.

When you strip stablecoins down to what matters, you realize the challenge isn't blockchain. It's uncertainty. People don't fear "onchain", they fear not knowing what's happening, what happens next, and what to do when something goes wrong. So I designed Blockradar around clarity: clear states, clear intent, and calm control.

That mindset carried through everything I built: Gateway (with Circle), arc-powered rails, Checkout (Stripe for stablecoins), Yield, and Autosettlement, until the platform grew into infrastructure used by 100+ fintechs across Africa, LATAM, the Middle East, and Southeast Asia, processing $350M+ in volume.

roleFounding Head of Product & Design
timeline2024 - Present
teamClement Hugbo
skillsProduct DesignInteraction DesignBrand IdentityMotion DesignCreative DirectionProduct and Design Strategy
the problem

How do we make a complex financial system feel boring, in the best way?

When we started, the real problem wasn't "build a stablecoin wallet." It was that stablecoins were being sold as magic, but they were being experienced as stress. You could send money across borders in minutes, yet teams still ran operations like it was fragile: screenshots, manual reconciliations, "did it go through?" messages, and support threads that lived next to block explorers. That mismatch creates a trust cliff. Once money is involved, anything that feels unclear becomes "unsafe," and if a product feels unsafe, no feature matters.

Boring meant predictable. Boring meant legible. Boring meant people could build on it and sleep.

research

Understanding behaviors under pressure

My research was less about collecting opinions and more about understanding behaviors under pressure. I watched how operators react when a transfer is delayed, what questions founders ask when a partner is evaluating you, and what finance teams need before they'll move funds at scale. I tried to map "where anxiety lives" inside a money flow, because anxiety is usually where product adoption dies.

I also learned quickly that stablecoin infra has two audiences at once: the end users who want a smooth experience, and the operators behind the scenes who need power, visibility, and control. If you over-design for one group, you break trust with the other. So every feature had to resolve that tension.

the solution

First-principles design across money flows

Money flows as state machines

The first was that money flows are basically state machines: there's always a current state, a next state, and an expected timeline, plus failure states that must be honest. We build infrastructure for fintechs and global companies, not custody of funds, so our role is to support their transactional purposes and help them manage their own users and customers. So instead of designing screens, I designed "truth." I asked: what are the states we can guarantee, what are the states we can't, and how do we communicate uncertainty without sounding like we're hiding something?

Trust is created at the edges

The second was that trust is created at the edges. The "happy path" is easy; the hard part is what happens when a payment is underfunded, sent on the wrong network, stuck pending, or needs review. I treated those moments like first-class design problems, because they're the moments users remember. Checkout forced us to confront a simple idea: if stablecoins are really "money for the internet," paying with them should feel as easy as paying with a card. I kept describing it as "Stripe for stablecoins," not because of aesthetics, but because Stripe's magic is clarity. So I designed Checkout to remove intimidation: paid, pending, expired, underpaid, wrong network, each state had to be explicit and actionable.

Autopilot vs control

The third was that operators need two modes: autopilot when things are calm, and control when things are not. That principle shaped how we built automation like Autosettlement while still leaving room for visibility and overrides. Autosettlement was where my "autopilot vs control" principle got tested the most. When money moves automatically, users need to know exactly what triggers it, what happens during it, and what the system will do if something doesn't match expectations. So I designed Autosettlement like setting a rule in a financial system, not like flipping a feature toggle. And when something goes wrong, the product has to be honest and helpful: show what failed, what it tried, what it will try next, and how to intervene.

Gateway + Circle + Arc

Gateway was where Blockradar had to look and behave like real infrastructure, not a crypto tool. When Circle came into the picture, that bar moved even higher. So I designed Gateway around mental models fintech teams already understand: routing, settlement, traceability, while hiding unnecessary blockchain noise. Working closely with the Circle team building Arc, I was able to design a seamless flow for stablecoin settlement and onchain routing without the complexities of multiple cross-chain transactions.

learnings

Key Takeaways

Impact

Over time, Blockradar grew from early-stage product building into stablecoin wallet infrastructure used by 100+ fintechs across multiple regions, scaling to $450M+ in processed volume. But the deeper impact, for me, is that we made a category that often feels chaotic start to feel operational. We didn't just ship features, we shipped reassurance.

Design as risk management

Blockradar taught me that in fintech, design isn't decoration, it's risk management expressed as experience. The cleanest UI isn't the one with the fewest components; it's the one that reduces uncertainty. And first principles matter because in new categories, templates lie. When you start from "what must be true for this to be trusted," you end up building products that scale with time, partners, and real-world messiness.