Shipping a sub-50ms trading UI on an L2

When a trader presses buy, three things happen in sequence: the order has to be signed, transmitted, and reflected on screen. Each one is a budget. Spend too long on any of them and the UI feels rubbery — and rubbery UIs lose volume.

We started Zentus with a 50ms median budget for the round trip from click to visual confirmation. That number sounds aggressive until you realize that perceived latency isn't actual latency. It's the time until the user sees something change. So most of our budget went into figuring out what to render before the chain replied.

The trade flow renders the order as filled the moment we have a valid signature. The order book updates locally. The portfolio reflects the new position. Then we wait for the on-chain confirmation in the background.

If the chain rejects the trade — gas spike, frontrunning, anything — we roll the UI back with a single coordinated animation. The position fades, the book reverts, and a small toast explains what happened. We've measured this rollback at under 4% of trades and most users never see one.

A 200-deep order book with 50 updates per second will obliterate React's reconciler. We virtualized the book, broke it into a flat list of WebGL-rendered rows, and pushed updates through a single ref. The rest of the page stays in the React tree; only the book is special-cased.

The result: the book stays smooth at 120fps even during volatility events. The cost: a few hundred lines of bespoke code. Worth it.

We'd start with the WebSocket transport sooner. We initially polled because it was simple, then ate three weeks migrating. The migration paid for itself, but we'd skip step one next time.

We'd also build the rollback animation earlier. It feels like a polish task, but it's actually a confidence task. Traders relax when they know what failure looks like.