> For the complete documentation index, see [llms.txt](https://hyperliquid.gitbook.io/Hyperliquid-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hyperliquid.gitbook.io/Hyperliquid-docs/for-developers/api/optimizing-latency.md). # Optimizing latency The suggestions below are for informational purposes only and a non-comprehensive starting point. They are not trading advice and do not guarantee any latency or trading outcome. ### Optimizing read latency (receiving market data) 1. Run a non-validating node against a reliable peer, such as Hyper Foundation non-validator. 2. Run node with `--disable-output-file-buffering` to get outputs as soon as blocks are executed 3. Run node with sufficient machines specs, at least 32 logical cores, 128 GB RAM, and 500 MB/s disk throughput. Increasing cores can reduce latency because blocks will be faster to execute. 4. Construct book and other exchange state locally using outputs from node, which has faster and more granular data than the API. See for an example on how to build an order book on the same machine that is running a node. This repo is not actively maintained. It is recommended to fork the repo or write an implementation from scratch to incorporate details such as ALO priority fees or other edge cases. 5. `--batch-by-block` on the node will wait until the end of the block to write the data. The example order book server above uses this to simplify logic, but a further optimization could include turning the flag off and inferring block boundaries otherwise. 6. Latency-sensitive users may find `split_client_blocks: true` useful, as it streams transactions to be committed before they are included in client blocks. This can lead to 70-150ms improvement in latency when reading inputs. As documented in the node repository, these are the fastest transaction inputs to execution, broadcast even before they are executed by the L1. The tradeoff with the faster input data is that the results from execution are not yet available. However, with simple actions like orders, the consumer can stream estimated account values for all users to predict execution results with reasonable accuracy. 7. The foundation non-validator is one of the highest uptime and low latency non-validator peers. See [here](/Hyperliquid-docs/for-developers/nodes/foundation-non-validating-node.md) for details on access for latency-sensitive users. 8. Read priority fees are the fastest way to read raw data from the network. See [here](/Hyperliquid-docs/for-developers/api/priority-fees.md) for more details. ### Optimizing write latency (sending orders and cancels) 1. Cancels should be sent with the [fast](/Hyperliquid-docs/for-developers/api/exchange-endpoint.md#cancel-order-s) flag. There is no disadvantage to the fast flag, except that fast cancels cannot be used to cancel trigger orders. 2. Write priority fees are the fastest way to send orders to the network. See [here](/Hyperliquid-docs/for-developers/api/priority-fees.md) for more details. 3. Hyperliquid's execution logic is designed to protect makers against toxic flow, so that end users see tight spreads and deep liquidity even during volatility. The primary driver of this effect is that cancels and ALO orders sent at time `t` will almost always execute before IOC and GTC orders sent at time `t`. This prioritization spans several blocks. The secondary effect is that each L1 block contains only a few consensus bundles. Within each bundle, ALO and cancels are executed before other transactions. 4. End-to-end latency on Hyperliquid is not apples-to-apples with centralized matching engines, because the order book is fully onchain. End-to-end latency includes time to API server, mempool inclusion time, and time to commit (usually 2 blocks in pipelined HyperBFT consensus). The sequencing of transactions has far less noise than the end-to-end latency suggests. While a cancel or ALO order can show \~380ms end-to-end latency, users should be able to run experiments with <10ms variation between send times and see predictable ordering on the L1. 5. Users who care to reduce the end-to-end write latency (for example to predict the sequence of transactions that will be committed) can read them from split client blocks in the non-validating node (see read latency section above). This approach does not include the execution result of the transaction.