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.