Rebuilding Lynx as the product kept expanding
Lynx grew from a leveraged trading product into a multi-chain suite with liquidity, rewards, partner deployments, and real-money games. I rebuilt its interface and helped shape the new product layers.
- Role
- Product and full-stack engineer
- Status
- Live product / ongoing
- Scope
- Product / Trading UX / Multi-chain / Colyseus / Pyth / Redis
I joined Lynx to rebuild a V1 frontend. The brief widened as the product did: first the trading experience, then the design system, rewards, partner variations, and finally Arcade.
Joining Lynx
The first job was fixing the trading product
Lynx lets people trade leveraged markets on-chain. When I joined, the first version worked, but the frontend looked dated and the trading flow was harder to read than it needed to be.
I was brought in to rebuild the interface. Before changing it, I had to understand the product: markets, positions, collateral, pending transactions, and the actions available in each state.
The brief sounded visual at first. It quickly became product work, because a new skin would not fix unclear decisions or missing feedback.
Trading foundation
The interface had to explain what was happening
Trading screens become dense easily. Price, leverage, position size, balances, fees, confirmations, errors, and live P&L can all compete for attention.
I rebuilt the design system and reorganised the main flows around the information a trader needs at that moment.
Pending states and transaction feedback became part of the journey. The interface showed what had happened, what was still processing, and what the user could do next.
The result was not a prettier version of V1. It was a calmer trading product with a visual language we could reuse as Lynx grew.
Platform shape
The same product had to work in many forms
Lynx was no longer just one perpetuals screen. It included options, liquidity pools, portfolios, rewards, and partner-branded deployments across several chains.
Not every deployment exposed the same product. A partner could change the branding, available chains, markets, routes, or features.
The interface needed to absorb those differences without feeling assembled from exceptions. Shared primitives gave each version the same underlying logic.
Rewards
Trading activity became a season people could follow
I built the seasonal points system across frontend and backend. It awarded points from trading volume and P&L, while also rewarding liquidity providers.
Each season could have its own duration and run across several chains. The product turned that activity into progress, rankings, and a leaderboard people could understand.
At the end, Lynx or a partner could export the full dataset and use it for distribution.
We did not need a large anti-farming system. Trading purely for points still carried fees and real market risk, so the product’s economics discouraged most abuse.
Arcade
Arcade made the market easier to enter
Arcade came from the idea that market products could be playful without becoming meaningless. It offers short games instead of asking people to learn a professional trading screen.
I work with the CEO on the product, then own the game design, UI, frontend, and real-time server.
In one game, players join a short round, choose up or down, and watch every position appear on a live BTC chart. Gridy turns the same market movement into a field of multiplier squares.
Pyth provides the prices. Colyseus creates the multiplayer rooms and keeps every client on the same version of the round.
Inside an Arcade round
Play felt immediate, but the server kept the result honest
- 01On-chainDepositA wallet deposit topped up a separate Arcade balance.
- 02LedgerInstant entryPlayers joined rounds without waiting on-chain for every action.
- 03RoomLive stateColyseus synchronized the chart, round, and every player’s position.
- 04ServerResolutionThe server checked timing and resolved the round from Pyth prices.
- 05StorageRecoveryRedis and database state preserved rooms and durable game history.
The client makes the boundary clear. The server makes it real.
Reliability and scope
Fast play still needed hard boundaries
Arcade uses a virtual game balance so each round can move instantly. Deposits and withdrawals remain on-chain, where the movement of real money is visible.
Timing rules exist twice. The interface stops late bets, and the server rejects them independently. A client cannot make an invalid action valid.
Colyseus can persist rooms in Redis, while game records also live in the database. A restart should not erase a round or its history.
I do not own the ledger contract or Gridy’s volatility formula. I own the experience around them, from the product decisions through the real-time implementation.
We postponed custom rooms and tournaments until the core games proved themselves. Lynx is still active work, so the story ends with a product that is still moving.