Building Orokai
A self-custodial DeFi interface where checking a price, staking, paying and tracking a transaction stop being four products. Five design decisions, what each one cost us, and what it took to hold them across two runtimes and two chain ecosystems.
Project Details
CLIENT
ROLE
Interface design & engineering
Surfaces
Web, iOS, Android
Ecosystems
EVM & Cosmos
Surfaces
Web, iOS, Android
Custody
Non-custodial
The brief
Friction that isn't the chain's fault
Checking a price. Staking a token. Paying for something in crypto. Tracking the transaction afterward. Four separate actions, and in most DeFi products, four separate apps. Nobody wakes up wanting to manage five browser tabs to do one thing.
Working on Orokai's interface, we kept running into the same question: is this friction actually necessary, or is it just what everyone's used to building? Five patterns came out of that process. Each maps to something researchers in behavioral design have understood for decades — the problems DeFi UX runs into aren't new or crypto-specific.
What follows is the design side of that work stated as decision records: the context, what shipped, and what each decision cost. The last part is usually the part that gets left out.
One hub instead of five apps
Apps in one workflow 5 → 1
Context
Every extra app isn't just extra time logging in and learning a layout. Each switch resets context: the user re-locates what they were doing and re-decides it's worth continuing. Four of those per workflow.
What shipped
Price checking, staking, payments and transaction tracking in one hub, with a single navigation model repeated identically on web and native.
What it cost
One surface now has to speak two chain ecosystems. EVM and Cosmos accounts share no address format, fee model, or signing flow. Consolidation moved that into @orokai/web3 — ours to maintain, instead of theirs to survive.
Live mid-price, refreshed every 4s.
→ to earn on this, open the staking portal
Pool open. Minimum deposit 0.01 ETH.
→ approve it in your wallet extension
Invoice expires in 14 minutes.
→ sign the transfer in your wallet
Fee 0.00012 ETH. Cannot tell you what the contract does.
→ did it land? open the block explorer
Submitted 40s ago. Not pushed — reload to check.
→ check the price again, back to the feed
5 tabs open
4 layouts to learn
4 places to give up
Do these first
Total rewards
Passive income
Activity
1 interface
Five steps into one
Taps to send a payment 5 → 1
Context
Confirm the amount, then the network, then the fee, then the destination, each on its own screen. Thorough from the builder's side; five chances to stop from the user's.
What shipped
One screen carrying a single intent through all five stages, with defaults derived from the route, the account's history and current fees — not from a blank form.
What it cost
Defaults have to be right, because nobody checks them. Every autofilled value needed its own validation path — the reason @orokai/web3-validation is a package and not a helper file. A wrong default is worse than an extra tap.
Fewer options on the first screen
Hick's law · settings before the first tap 14 → 3
Context
Decision time rises with the number of choices. It isn't that people can't handle options — it's that each one adds a tax on decision speed, and the tax compounds once everything is visible at once.
What shipped
Three fields lead, filled from what the account already told us. The other eleven sit behind “more options” — reachable in one tap, never removed.
What it cost
Power users pay a tap they didn't pay before. We took that trade deliberately: the cost lands once, on the people best equipped to absorb it, and preferences persist per account so it isn't charged twice.
Send
a = 200 ms · b = 150 ms · n = 14
Illustrative curve using constants from the original Hick–Hyman studies — not a measurement of Orokai.
Warnings that teach instead of scare
Miller's law · alerts before confirming 6 → 1
Context
Working memory holds only so much. Stack six warnings and people stop reading them individually — they pattern-match “lots of red text” to “confirm and move on”, which is the opposite of the point.
What shipped
Education moved earlier: an interactive academy and guidance woven through the steps a user is already taking. One alert survives at the moment of action — the one carrying real risk.
What it cost
Removing a warning is a liability decision as much as a design one. Every alert we cut had to be demonstrably answered earlier in the flow, and we had to be able to point at where. That review is slower than adding a banner.
This transaction cannot be reversed once submitted.
You are interacting with a contract Orokai has not verified.
Network fees may change between now and confirmation.
Token prices are volatile and may move during execution.
Ensure the destination address is correct before continuing.
Orokai does not take custody of your assets at any point.
You have never sent to this address before. Send $1 first to check it?
Onboarding without assumed vocabulary
Jakob's law · modules on day one 12 → 3
Context
People judge a new product against every other one they've used. Almost nothing in daily life prepares someone for a wallet, a network, or a KYC step — and DeFi products are mostly built by people who forgot that.
What shipped
Progressive disclosure: three modules on day one, the rest surfacing as the tasks that need them arrive. Interactive tutorials in place of static instructions.
What it cost
Progressive disclosure means state. What someone has unlocked, completed and already seen becomes data the API owns and three clients have to agree on — web, iOS and Android, without drifting out of sync.
Typical DeFi dashboard, day one
12 modules, no order of operations, no clue which one comes first.
Orokai
Next: add funds. We'll walk you through it, one step at a time.
3 of 12 modules shown. The rest unlock as they become relevant — nothing is taken away.
Five decisions, four surfaces, one shared core
Each decision above is a UX statement that has to survive contact with two runtimes and two chain ecosystems. The only way that stays consistent is to implement the rule once, in a shared package, and bind it per platform — rather than writing it three times and hoping the three stay equal.
Monorepo
- Bun 1.3 workspaces
- Turborepo pipelines
- Biome · lint-staged · Husky
- Docker Compose
Web
- React Router 7
- Vite 8
- Tailwind CSS 4
- TanStack Query · Virtual
Mobile
- Expo 56
- expo-router
- EAS build pipeline
- iOS & Android from one tree
Chain
- viem — EVM
- CosmJS — Cosmos
- chain-registry
- zod validation schemas
Shared packages
- @orokai/web3
- web3-react · web3-react-native
- web3-validation
- translations — EN / PL
Backend
- TypeORM migrations
- Seeded dev environments
- Onboarding & progress state
- GitHub Actions CI
| Decision | Web | iOS / Android | EVM | Cosmos |
|---|---|---|---|---|
| 01 · One hub | Shared navigation model | Same model, native shell | One account abstraction over two address formats | |
| 02 · One step | Defaults resolved in shared logic, rendered per platform | EIP-1559 fee estimation | Gas price & denom per chain | |
| 03 · Fewer options | Same three leading fields; preferences persisted per account | Advanced settings differ by ecosystem — the disclosure does not | ||
| 04 · One alert | Risk checks run before the UI, not inside it | Approval & contract checks | Signing-mode checks | |
| 05 · Progressive | Unlock state owned by the API, mirrored by both clients | Module availability depends on the connected ecosystem | ||
Same four actions, one place to do them
Checking a price, staking, paying, tracking a transaction: still four actions. Now one hub, fewer decisions along the way, and warnings and onboarding built for the person actually using it — with the complexity moved into a codebase we maintain rather than a workflow they endure.
Why does DeFi feel more complicated than it needs to be?
Most of the complexity isn't in the underlying technology, it's in how products present it. Spreading one task across multiple apps, showing every option at once, and stacking warnings without context all add friction that has nothing to do with blockchains being inherently hard to use. That is a design problem, not a technical one.
Does consolidating tools mean users give up control of their funds?
No. Orokai is non-custodial. Bringing price tracking, staking and payments into one interface reduces how many places a person has to navigate; it does not route funds through a third party. Keys stay with the user — the platform builds and relays the transaction they sign.
How do these decisions stay consistent across web and mobile?
The rules live in shared packages rather than in each client. Account handling, validation and chain access are implemented once and bound per platform, so a change to a default or a risk check lands everywhere at the same time instead of being reimplemented three times.