EuclidSwap

The problem

Liquidity on-chain is fragmented across dozens of chains, which means a swap interface has to reason about pools, routes, and settlement that span multiple networks. Presenting that to a user as a single input box — pick a token, pick another, see a real number — is a frontend problem with a genuinely hard state layer behind it.

How it was built

Built the frontend for a unified cross-chain liquidity protocol, where the interface has to stay correct against state arriving from several sources at once: quotes, routes, balances, and transaction status across chains that confirm at different speeds.

GraphQL and REST both feed the interface, so a meaningful part of the work is normalizing two differently-shaped data sources into one client-side model rather than letting the shape of each API leak into components.

Zustand handles the shared state. For a swap interface this is the load-bearing choice — quote, route, slippage, and transaction status are all interdependent, and prop-drilling them through a component tree is how swap UIs become unmaintainable.

Next server-side rendering for the parts that benefit from it, with performance optimization as an explicit goal — a swap interface that feels slow reads as a swap interface that might be broken, and users do not distinguish the two.

Why this stack

• Zustand — narrow-selector subscriptions matter when quote updates would otherwise re-render an entire interface.
• GraphQL plus REST — normalized behind one client model rather than exposed to components.
• Next.js server rendering — first paint for a page users arrive at cold.

Outcome

• Live at swap.euclidprotocol.io as a company project at Euclid Protocol.