John Etokhana milkyway.zone ↗
Case study · MilkyWay

Making liquid staking legible.

MilkyWay is a liquid staking protocol in the Cosmos ecosystem. I led product design from before launch, turning complex on-chain mechanics into a staking flow, validator-selection model, a Lite and Pro experience, and reward dashboards that non-experts could use with confidence.

I designed the 0→1 trust layer for a liquid-staking protocol: the staking flow, a guided validator default, a Lite and Pro split, and reward dashboards that turned irreversible, time-delayed, validator-laden mechanics into something a non-expert could complete with confidence. The protocol reached $30M+ TVL within months, in a market with strong staking incentives, which I treat as protocol traction, not a design result.
$30M+
protocol TVL within months, in an incentivized market
01
staking flow, validator selection and reward dashboards, designed from scratch
2
modes, Lite and Pro, so one product served newcomers and pros
Role
Senior Product Designer. Led product design
Timeline
Dec 2023 to Jul 2025. Remote
Platform
Web
I did
Staking flow, validator-selection model, Lite/Pro, reward dashboards, product and stakeholder research
app.milkyway.zone
MilkyWay liquid-staking dashboard: stake, withdraw and claim tabs, a validator list, and TVL, APR and price kept in view.
The liquid-staking flow I redesigned: stake, withdraw, claim, with the numbers that matter kept in view.
01
Context

Staking locks up your tokens to help secure a network and earn yield, but it freezes your capital. Liquid staking solves that. You stake, receive a liquid token, and can use it elsewhere while still earning. It is useful and hard to follow. Validators, unbonding periods, exchange rates, reward accrual. Most protocols show all of it raw and expect users to track it themselves.

MilkyWay's chance was to be the one that did not. To let someone stake with confidence without being a Cosmos expert first.

02
The problem

In DeFi, unclear design is a financial risk, and it costs trust in a category that is already short on it. The specific challenges:

  • Irreversible actions with real money, on unfamiliar mechanics.
  • Invisible time. Unbonding periods and reward accrual happen off screen, over days.
  • Validator choice. A decision most users do not feel ready to make, but cannot skip.
  • Tool dependency. Users were leaving to external dashboards to see their own position.
03
The decision

A note on evidence: I had basic usage signals, rough patterns like how often people took the default validator or stayed in Lite, alongside friction points in wallet connection and position visibility, drawn from product data, stakeholder input and community feedback. What I did not have was formal moderated studies or a mature funnel that could cleanly isolate design's causal impact. So I treat the usage patterns below as directional evidence, enough to guide judgment, not to claim design moved a number.

Validator selection was the sharpest fork. Choosing a validator is a real decision with real consequences, and most users do not feel equipped to make it. But hiding it entirely would strip the control that experienced stakers expect. Two directions:

Considered
Full control, expose everything
Pros
  • Power users get every lever and data point
  • Nothing is hidden
Cons
  • Newcomers stall on a decision they can't judge
  • Reads like the raw tools we were trying to replace
Chosen
Guided default, with a way in
Pros
  • A sensible default so newcomers can stake in one step
  • Commission, uptime and voting power still there for those who want them
Cons
  • More design work to earn trust in the default

What I chose, and what I gave up. I led with a sensible default and kept the full signal one tap away. It costs more design effort to make a default people trust than to dump every option on screen, but it is the difference between a newcomer staking and a newcomer bouncing. I made the same call on time: unbonding periods and reward timing are written in plain language, so the invisible time became visible instead of buried in protocol terms.

app.milkyway.zone
Validator selection: a searchable list with commission, uptime, voting power and active status, sitting behind a sensible default.
Validator selection: newcomers can accept a sensible default in one step, while commission, uptime and status stay one tap away for people who want them.

In practice, the majority of users appeared to take the recommended validator, which supported making the default path clear while keeping validator details available for advanced users.

app.milkyway.zone
The whole flow, start to finish: enter an amount, take the guided validator, then a plain-language review before you confirm. Nothing irreversible happens without a clear last look.
04
One product for newcomers and pros

The second fork was how much of the machinery to show at all. Under liquid staking sits real depth: pools, AVS, operators, restaking, higher-risk strategies. Expose all of it and a newcomer freezes; hide it and an experienced staker loses the control that made them pick an advanced protocol in the first place. Averaging the two into one middle-of-the-road UI would have served neither.

The trap
One flattened UI for everyone
Pros
  • Simplest to build and maintain
Cons
  • Too much for newcomers, too shallow for pros
  • Loses trust at both ends of the market
Chosen
Lite by default, Pro on demand
Pros
  • Lite gets a first-timer staked safely, decisions pre-made, risk and yield in plain terms
  • Pro exposes pools, AVS, operators and restaking for people who want the levers
Cons
  • Two surfaces to design, test and keep coherent
  • A cliff between them if the handoff is clumsy

What I chose, and what I gave up. I made Lite the default and put Pro one toggle away. It is a segmentation-by-intent bet: the same product carries a nervous first-timer and a professional without watering down either. What I gave up was the simplicity of a single UI, and I took on the harder, ongoing job of keeping two modes coherent so the step up to Pro feels like a door, not a cliff.

app.milkyway.zone
Lite staking: a simple grid of stakeable tokens with the underlying complexity tucked away behind a sensible default.
Lite keeps the default path a simple grid of tokens with the hard decisions pre-made. Pro unfolds the pools, AVS, operators and restaking underneath, the depth you can see in the position dashboard next.

Most staking behaviour happened through Lite, while Pro served the users who wanted deeper control across pools, operators, AVS and restaking, which is the split the two-mode design was built for.

05
Bringing the data home

The most common community and support themes were about where to see a staked position, when rewards became claimable, how unbonding worked, and why balances looked different across tools. Users often relied on external ecosystem tools to understand position, rewards and protocol state, so I built yield and reward dashboards that brought that visibility into MilkyWay. This was daily work with backend, frontend and research, turning real protocol mechanics into clear flows and pressure-testing them against how people actually read on-chain data.

MilkyWay position dashboard: your liquid-staked balance, rewards, exchange rate, restake and bridge, with TVL and APR in context.
The position dashboard reads your stake, rewards and exchange rate in one place, so understanding what you hold no longer means opening a second tab.
Claim view with plain-language timing: rewards shown as claimable in a set number of days rather than raw unbonding epochs.
Invisible time made visible: unbonding and rewards are written as "claimable in N days," not raw protocol epochs.
06
Outcome
$30M+
protocol TVL within months, in an incentivized market
3 mo
to that TVL, during an incentivized market window
01
flow, validators, dashboards and two modes, designed from scratch

I want to be careful with the TVL number. In DeFi it rides incentives and the wider market at least as much as UX, so I read $30M+ as the protocol succeeding in a good window, not as proof that my design moved the dollars. The design contribution I can stand behind is narrower and more useful: I created the 0→1 staking flow, the guided validator default, the Lite and Pro split and the in-product reward dashboards, and together they cut the amount of protocol knowledge a person needed before they could act, while keeping the depth and control an experienced staker expects. That is the outcome I would put my name to, in a category where confusion is a financial risk.

07
What I'd do differently, and what I take from it

What I did not solve well: I shipped the clarity work on judgment and observed friction, without the instrumentation to prove it. If I ran it again I would define the design-owned metrics before launch: wallet-connect to stake completion, drop-off at validator selection, how often people took the default validator, Lite versus Pro usage, dashboard return rate, and how often people still relied on external tools to understand their position. In a category this noisy, that instrumentation is what separates what the design moved from what the market, incentives and protocol mechanics moved, the difference between a story and a result.

What I keep: take complex, high-stakes mechanics and make them feel simple and safe without dumbing them down, and treat defaults and disclosure as real decisions, a good default lets a beginner act while an expert keeps control. It is the same skill an agentic product needs, where the machinery is more powerful and trust is harder to earn.

© 2026 John Etokhana etokhanaj@gmail.com