Elevated Hyperliquid Latency in US East Region

Update timeline

1. investigating Jul 28, 2026, 02:06 PM UTC

   Some requests to Hyperliquid Mainnet routed through our US East region may be experiencing elevated latency. We are investigating.

2. resolved Jul 29, 2026, 11:19 AM UTC

   This incident has been resolved.

3. postmortem Jul 29, 2026, 12:24 PM UTC

   Between 13:30 UTC on July 28 and 08:00 UTC on July 29, HYPERLIQUID\_MAINNET requests served from us-east experienced elevated latency, and `eth_sendRawTransaction` returned a high rate of errors. Read methods remained available throughout, with elevated response times. **Impact** Transaction submission was the primary failure mode. During the peak period, the large majority of `eth_sendRawTransaction` requests either timed out or returned an error, and clients retrying submissions saw sustained failures. Read traffic on the network was slower than normal but continued to be served successfully. Latency was elevated for all HYPERLIQUID\_MAINNET request types for the duration of the event. **Root cause** A majority of our Hyperliquid full nodes in us-east lost peering with the network. The nodes were unable to complete state synchronization handshakes with upstream peers -- connection attempts were rate limited, timed out, or rejected because peer connection slots were full. Affected nodes fell behind and were removed from the healthy serving pool. Recovery required the upstream peer pool to free capacity; feeding new peers into the configuration and pruning node state did not restore peering. Two factors extended the impact: * With that capacity gone, all us-east traffic concentrated on the remaining archive node pool, which pushed latency up further and made `eth_sendRawTransaction` the first method to fail. * On Hyperliquid, transactions are not propagated peer-to-peer. They are relayed to a network-level submission endpoint that can rate limit, which means the transaction submission path is sensitive to network conditions independent of which infrastructure serves the request. **Resolution** We began routing `eth_sendRawTransaction` to secondary infra as soon as the issue was identified, but this did not restore transaction submission. Submissions relayed through secondary infra continued to fail at a comparable rate, since that path depends on the same network-level submission endpoint. A subset of nodes began to recover from around 01:30 UTC on July 29, when the first `hlnode` in us-east returned to a healthy state as upstream peer capacity freed up. Server-side errors from our serving layer dropped off around the same time, though submissions continued to fail through a mix of remaining unhealthy nodes and rejections at the network's submission endpoint. Peering re-established across the rest of the pool over the following hours. Latency returned to normal levels by approximately 08:00 UTC, request volumes and error rates returned to baseline, and all us-east nodes were confirmed healthy shortly afterward. **Follow-up** We are exploring running our own validator and sentry nodes for Hyperliquid so that peering no longer depends on availability in the shared public peer pool.