CB Tools

A decentralised exchange is a swap, plus the liquidity pools that make the swap possible, plus the farms that pay people to supply that liquidity, plus the staking that pays them to hold the token, plus the referral program that pays them to bring friends. Each one is a different mental model, and all five live under one navigation bar.

CB Tools carried all of it, and the interface says so plainly: the footer lists Swap, Liquidity, Staking, Pools, Docs, Whitepaper, Audit, Analytics, News, Partners, Team, Contacts. The nine-dot launcher in the header opens the wider ecosystem. The home page carries a diagram of the token economy itself, two funds and a fee flow, because the product was selling a mechanism and not just an interface.

My job was the interface for all of it.

Farms are a table of yield pools. Every row has a state machine underneath it: wallet not connected, connected but contract not approved, approved but nothing staked, staked and earning, finished. Five states, and every one needs a different button.

I drew it in two presentations, switchable from a toggle. The grid puts each pool in a card with the state as a single button at the bottom and a Details disclosure holding liquidity, contract and pair links. The list puts the pools in a dense table and, on expand, lays the state machine out as three numbered steps: get the token, unlock the wallet and stake, harvest.

The numbered-step expansion is the decision worth pointing at. In the card the state is one button and the user has to infer what comes next. In the list the whole sequence is visible at once and only the current step is lit. Same data, same states, two different levels of hand-holding, and the user picks which one they want.

The part of the work that does not photograph as screens and matters most.

Liquidity is a single 1920 by 13,666 frame holding roughly eighteen states of the add-and-remove flow stacked vertically: empty pool list, import pool, pair selected, amounts entered, share preview, the amber price-impact warning, the removal slider, the confirmation. Not eighteen pages. One vertical map you read like a spec, which is exactly what a developer needs when the flow is conditional rather than linear.

The transaction modals live on a board 11,980 by 2,408: about twenty-four states in a row, dark on top and light below, covering the whole path from selecting a token to a submitted transaction.

Wallet panels have real skeleton loaders as their own component set, with the shimmer blocks matching the shape of the content that replaces them. The product waits on a blockchain, so the waiting state is a design surface, not a spinner.

The analytics product of the ecosystem. The token page runs three columns: contract and pool information on the left alongside a safety check panel covering honeypot, buy and sell tax, pausable transfers, proxy contract, creator liquidity share and blacklist. The middle holds the chart and a six-tab trade book with filters over amount, value, price and date range. The right holds swap and portfolio. Both side columns collapse.

The multichart grid is the headline. The empty state promises sixteen tokens at once, and the file delivers on it with thirteen distinct layouts: one chart fills the canvas, two split it, three sit in a row, then the grid starts mixing sizes, three large over four small, two wide over two rows of four, three by three, four by three. Charts do not just shrink as you add them, the whole grid re-forms.

Charts are added through a modal that counts against the cap and re-ordered by dragging, with a dashed drop zone.

Theming was designed in from the first screen, with the means that existed then: paired day and night styles, naming discipline, state matrices. Figma variables did not exist at the time, they arrived two years later, so all of that logic rested on convention.

Once the tooling caught up, I came back to this product and rebuilt the layer under the Charts screen as a real token system. It came to 285 variables in six collections and twelve modes: four themes including two high-contrast, two brands, two densities, two typefaces. 43 component sets, 332 variants, 26 text styles bound across all five font fields, 13 effect styles with bound colours, 3,421 icons.

The proof sits in the same file: the same Charts terminal assembled entirely from the system, plus seven renders of one mobile component tree, one per mode. Nothing is redrawn between them, a collection switch does the work. A scan walks 4,730 nodes and finds no violations, and 44 of 44 contrast pairs pass WCAG across four themes.

The original day and night styles are deprecated rather than deleted: 12,399 fills still use them, and each carries its nearest new token in its description. That makes the migration incremental instead of a rewrite.

The design was handed to the engineering team and the product was built. There was no public release: a client decision, and one that sits outside the design. So there are no business metrics here, and I am not going to invent any.

What can be verified is in the figures below: scope, breakpoint coverage, themes, and the system built over this product afterwards.