Blocks, Finality, Throughput, and Latency on Hyperliquid
Hyperliquid's performance should be understood as a pipeline: consensus orders state transitions, block production advances state, and user-visible latency includes network and client effects.
Hyperliquid is built for workloads where latency and deterministic ordering directly affect market quality. Its documentation reports roughly 200,000 orders per second of mainnet capacity and median end-to-end latency around 0.2 seconds for a geographically co-located client, with a 99th percentile around 0.9 seconds. Those figures are useful, but they are not the same thing as a universal “transaction speed” number for every user or application.
Throughput is not latency
Throughput measures how much work a system can process over time. Latency measures how long a particular action takes to reach the point the user cares about. A chain can have high throughput and still feel slow if networking, queueing, RPC infrastructure, or application logic adds delay.
For a trading system, the relevant path can include signing, sending, validator propagation, consensus ordering, matching, and receiving an acknowledgement or fill update.
Why consensus matters to a market
A central limit order book depends on sequence. If two orders compete for the same price level, the market needs a single authoritative order. HyperBFT supplies consensus over the state transitions that drive both HyperCore and HyperEVM.
This is why “fast blocks” alone are not a complete explanation. The useful property is a consistent ordered state that can support a responsive market engine.
Why your observed latency will differ
A co-located benchmark does not describe every retail connection. Distance to infrastructure, internet routing, WebSocket quality, client implementation, signing overhead, rate limits, and local processing all affect the measured result.
Professional trading systems therefore measure their own full path: submit timestamp, acknowledgement timestamp, fill timestamp, and market-data arrival. They also separate exchange-side latency from their own networking and software.
How builders should think about performance
Use WebSockets for time-sensitive streams rather than repeatedly polling REST endpoints. Reuse connections, handle disconnects, respect rate limits, and measure the latency of the exact API path your product depends on.
For HyperEVM contracts, gas and EVM execution add a different performance model. A contract interaction should not be benchmarked as though it were a native HyperCore order. The two surfaces share consensus but have different execution semantics and workloads.