The Incident: What Happened

On July 29, 2025, Hyperliquid's API servers experienced a significant traffic spike that caused order delays between approximately 14:10 and 14:47 UTC. During this 37-minute window, traders submitting orders through the API experienced elevated latency, with some orders taking substantially longer than normal to process.

The incident did not affect the underlying L1 blockchain or consensus mechanism. HyperBFT continued producing blocks normally throughout. The issue was specifically in the API server layer — the infrastructure between traders' requests and the on-chain order matching engine. The core trading engine remained operational; the bottleneck was in request ingestion and routing.

During the disruption, some orders were delayed but eventually executed. Others timed out and needed resubmission. Market makers saw their ability to maintain tight quotes degraded, and automated trading systems expecting consistent latency had strategies disrupted.

The Immediate Response

What distinguishes this incident from similar events at other platforms is the transparency and speed of the response. Rather than minimizing the issue, Hyperliquid communicated with the community in near-real time during investigation and resolution.

The root cause was identified as a traffic spike exceeding the server infrastructure's capacity to process requests within normal latency bounds. This was not a code bug but a capacity issue where legitimate traffic volume overwhelmed available resources — pointing to infrastructure scaling rather than logic fixes. By 14:47 UTC, order processing latency had returned to normal.

Refunds for Affected Users

One of the most notable aspects was the decision to provide refunds to adversely affected users — a practice exceedingly rare in DeFi and not universal even among centralized exchanges.

The refund process involved identifying traders whose delayed orders caused financial harm. The platform reconstructed what would have happened under normal latency conditions and compared it to actual outcomes. The difference formed the basis for calculating each user's refund.

Refunds were processed proactively, without requiring affected users to submit claims or prove losses. The team's analysis identified affected accounts and credited them directly — removing the burden from users and ensuring fair compensation without bureaucratic overhead.

The Postmortem

The postmortem went beyond the immediate trigger to examine systemic contributing factors.

Traffic Patterns and Capacity Planning

API traffic on a trading platform is inherently bursty. Market events, liquidation cascades, and token launches can cause sudden request spikes. The analysis revealed that while existing infrastructure handled typical patterns well, the July 29 spike exceeded provisioned headroom, pointing to the need for more aggressive capacity planning with higher peak-to-average ratios.

Connection Management

Part of the issue was how servers managed incoming connections during the spike. When concurrent connections exceeded capacity, new connections were queued rather than immediately processed. Under normal conditions the queue was effectively empty; during the spike it grew, and processing times increased proportionally.

Load Distribution

The postmortem examined traffic distribution across the API server fleet. Uneven distribution can cause some servers to be overwhelmed while others have spare capacity. Improving load balancing to distribute traffic more evenly was identified as a key improvement area.

Infrastructure Improvements

The improvements that followed addressed both the specific failure mode and broader resilience concerns.

Horizontal scaling. The API server fleet was expanded. More servers means higher total capacity, raising the threshold at which spikes cause degradation.

Enhanced load balancing. The load balancing layer was upgraded to provide more granular, responsive traffic distribution. The new system monitors real-time load on each server and routes requests to the least loaded instances.

Connection pooling and rate limiting. Improved connection pooling reduces overhead during traffic spikes, while more sophisticated rate limiting ensures no single client can consume a disproportionate share of resources. The rate limiting is designed to be fair — throttling excessive traffic without penalizing normal usage.

Auto-scaling mechanisms. Perhaps the most important long-term improvement: the system can now dynamically increase the server fleet in response to rising traffic, detecting increases and spinning up additional servers before existing capacity is exhausted.

Monitoring and alerting. Enhanced detection of capacity issues before they impact users. New metrics tracking queue depth, connection counts, and per-server latency provide earlier warning signals for preemptive action.

Why DeFi Infrastructure Reliability Matters

In the early days of DeFi, users accepted unreliability as the cost of accessing permissionless financial services. That era is ending. As DeFi protocols handle billions in daily volume and serve as critical financial infrastructure, the reliability standard must approach that of traditional systems.

This does not mean DeFi needs to be perfect — even major traditional exchanges experience incidents. But incidents must be handled with professionalism: transparent communication, thorough root cause analysis, fair compensation, and genuine improvements to prevent recurrence.

Hyperliquid's handling of the July 29 incident demonstrates this mature approach. The sequence — rapid identification, transparent communication, proactive refunds, thorough postmortem, and comprehensive infrastructure improvements — sets a template for how DeFi platforms should handle infrastructure incidents.

Reliable Data on HyperX

HyperX's data infrastructure is built for reliability, with WebSocket real-time streams and HTTP fallbacks. Our Agent API provides the same resilient access to Hyperliquid data for your trading bots.

Transparency as a Competitive Advantage

In a space where many platforms minimize or deny infrastructure issues, Hyperliquid's transparency is noteworthy. Publishing an honest postmortem builds trust more effectively than pretending nothing happened.

Traders deciding where to place their capital consider not just normal performance but how a platform handles adversity. A platform that transparently acknowledges problems and demonstrably fixes them is more trustworthy than one claiming perfection while users experience unexplained issues.

For the growing ecosystem of tools built on Hyperliquid's infrastructure — analytics platforms, copy trading services, portfolio management tools — the reliability of underlying API infrastructure is foundational. These improvements benefit the entire ecosystem, making the platform more dependable for builders and end users alike.