Is Alchemy down?

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

This incident has been resolved.

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.

We are investigating a network-wide stall affecting safe and finalized blocks on Base Mainnet.

This is a network-wide issue on Base Mainnet, not specific to Alchemy. The Safe head is delayed because data batching to Ethereum L1 is lagging. New block production on Base Mainnet is progressing normally, and requests against the latest block are unaffected. Only queries and workflows that depend on the safe or finalized block tag will see staleness. Refer to the Base status page for the latest updates: https://status.base.org/incidents/j6y12tshwkcg

This is resolved. Base Mainnet's Safe head has caught up and data batching to Ethereum L1 is back to normal. Block production was unaffected throughout. See the Base status page for their full update: https://status.base.org/incidents/j6y12tshwkcg

A subset of requests on Stable Mainnet are experiencing degraded

Nodes were unable to progress, team carried out a restart of the nodes and are seeing recovery and improved performance on requests. Actively monitoring.

Nodes have recovered and services are healthy again.

A subset of requests on Cronos Mainnet are experiencing availability issues.

We are continuing to investigate this issue.

A part of our Cronos nodes were down due to a binary issue.

Nodes have been rescyned with stable binary and services are back to healthy.

A subset of requests on Robinhood Mainnet routed through our Asia Pacific region may be experiencing increased latency.

This incident has been resolved.