CRPKO Subaccount

This week I'm focused on the mobile design for CRPKO. The web app is in a good shape. Abdulha is fixing something on the infra side and we're demoing tomorrow. Mohan, our new Product Designer, joins end of this week or end of the month.

I'm picking up the Subaccount feature first. It's the right shape to start with: clear scope, an existing implementation to learn from, and a feature where the design grammar across competitors is mature enough that I can reference instead of invent.

I'm anchoring on ByBit as the first reference. It's clean and has minimal complicity feature compared to others like Binance, so it's an ideal good start.

The instinct is to anchor against the cleanest baseline first, then layer complexity intentionally. Binance has institutional density that CRPKO doesn't need for v1; if I anchored there I'd be designing-down instead of designing-up. ByBit gives me a tight, valid baseline. Same instinct as the Catalogue First, Then Restructure approach.

I implemented what Jaswant had already built, based on the API contract and Technical PRD using base assets. I captured that in Figma and edited a little: I moved Subaccount from a section inside Profile & Settings into its own side-nav primary item.

Then I started the research. I'm using Codex linked with Mobbin, Refro, and Lazyweb MCP for ideation. For Indian platforms which aren't in those tools (CoinDCX, CoinSwitch, Mudrex, Delta Exchange), I'm using web search.

Codex's read across the references: ByBit is the cleanest model for CRPKO. Binance/Binance.US is institutional-style with dense tables. Delta Exchange is closest to CRPKO's trading-workspace idea, and importantly, Delta India says withdrawals happen from main account only. That's a regulatory constraint CRPKO probably has too. CoinDCX shows the API-level pattern: main → sub, sub → main, sub → sub, with subaccount-initiated transfer unauthorized.

Codex's framing: financial account hierarchy screens benefit from persistent context, dense tables, clear status, and direct transfer/action affordances. That's the design grammar I'm carrying into the work.

This image is a HTML quick prototype I'm doing based on what we have in the codebase, combined with MCP + web search. The reason this matters: it lets me design against the data we're actually getting from the backend, instead of just designing based on what others are doing without knowing what capabilities are present.

Before this, Figma prototype was the default, and most of the cost ended up in the implementation phase, when the design hit the backend reality and got reshaped. Now with AI we can prototype directly close to the current UI, using the real data shape. That makes the implementation effort way cheaper, and the design fidelity way higher.

Two things this prototype answers from earlier open questions: the subaccount cap is 5 (visible in 3 / 5 subaccounts used), and the status states are Active / Suspended / Deleted with affordance changes. Suspended subaccounts get View only, Transfer disabled, with a Transfers paused subtext. Status drives affordance directly.

Other moves the prototype locks in: INR-denominated values with lakh-comma format (₹40,34,257) for the Indian market, a multi-wallet model with Spot + USDT-M + INR-M as first-class wallet types, and a persistent context sidebar that shows the selected workspace's full wallet split plus a Quick Transfer affordance (From: Funding → To: Futures Hedge). The subaccount labels (Main, Futures Hedge, Strategy Lab) match the trader's mental model of strategy-as-workspace, not account-number.

A few things the prototype doesn't yet resolve, in priority order: