Hyperliquid RPC Latency: Measuring, HyperEVM vs Native API, and Low-Latency Tuning

Direct Answer: Hyperliquid RPC Latency Depends on Which API You Use

If you're asking about Hyperliquid RPC latency, the first thing to know is that Hyperliquid exposes two very different APIs: the native L1 API (REST and WebSocket) for market data and trading, and the HyperEVM JSON-RPC for the EVM side. The native API is designed for low-latency trading and can achieve sub-10ms round-trip times from a geographically close node, while the HyperEVM RPC is a standard Ethereum-compatible endpoint with higher latency and stricter rate limits. This guide shows you how to measure both, understand the factors that dominate latency, and tune your setup for the lowest possible latency.

For low-latency trading, the native WebSocket feeds (allMids, l2Book) are the primary choice, as they push updates in real-time without the overhead of polling. In contrast, the HyperEVM RPC is best for occasional state reads or contract interactions, where latency is less critical. The public HyperEVM RPC is rate-limited to approximately 100 requests per minute per IP (documented by providers), which can cause dropped or stalled requests if you exceed it, directly impacting perceived latency.

• Native L1 API: low-latency REST and WebSocket for market data and trading.
• HyperEVM RPC: standard JSON-RPC for EVM state and transactions, higher latency.
• Rate limits: HyperEVM public RPC ~100 req/min per IP (provider-documented).
• Geo-proximity is the dominant factor for native API latency.
• The Hyperliquid documentation defines the native info/exchange API and HyperEVM RPC methods that back these latency characteristics; see Hyperliquid docs for the authoritative endpoint and method reference.

Architecture: Why Two Stacks Have Different Latency Profiles

Hyperliquid's core is a custom L1 blockchain optimized for order-book trading. The native API (info and exchange endpoints) is tightly integrated with the consensus and matching engine, allowing for extremely low-latency reads and writes. The WebSocket feeds push updates as soon as they are processed, often within milliseconds. In contrast, the HyperEVM is a separate execution environment that runs alongside the L1, providing Ethereum compatibility. EVM JSON-RPC calls involve additional layers of abstraction and are typically served by nodes that may be less optimized for speed.

The network path also differs. For the native API, the fastest connections come from nodes that are geographically close to the Hyperliquid validator set, which is concentrated in specific regions. For the HyperEVM, the latency is more dependent on the provider's infrastructure and the distance to their nodes. Additionally, the HyperEVM RPC is often used for archive queries, which require reading historical state and can be significantly slower than current-state reads.

Rate behavior also differs. The native API has higher rate limits (documented in the Hyperliquid API rate limits guide), while the HyperEVM public RPC is more restrictive. This means that on the EVM side, you may experience latency spikes due to rate limiting, which is not a network latency issue but a request-throttling issue.

• Native API: optimized for low latency, WebSocket push.
• HyperEVM: standard JSON-RPC, higher overhead, archive reads slower.
• Rate limits: native API higher, HyperEVM ~100 req/min per IP.
• Geo-proximity matters more for native API.

Measuring Latency: A Reproducible Script

To measure latency yourself, you can use the following Node.js script. It measures round-trip time (RTT) for a native REST call (info endpoint), a HyperEVM JSON-RPC call (eth_blockNumber), and a WebSocket subscription latency probe. The script uses the public endpoints, but you can replace them with your own provider endpoints. Note that this is a measurement method, not a vendor benchmark; results will vary based on your location, network, and provider.

The script sends multiple requests and calculates the average, minimum, and maximum latency. For the WebSocket probe, it measures the time between sending a subscription and receiving the first message. Run it from a location close to the Hyperliquid infrastructure for the best results.

• Use the script to measure RTT for REST, JSON-RPC, and WebSocket.
• Replace endpoints with your provider's endpoints.
• Run multiple times to get a stable average.
• Record results in the table below.

const https = require('https');
const WebSocket = require('ws');

const NATIVE_REST_URL = 'https://api.hyperliquid.xyz/info';
const EVM_RPC_URL = 'https://api.hyperliquid.xyz/evm';
const WS_URL = 'wss://api.hyperliquid.xyz/ws';

function measureRest() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const data = JSON.stringify({ type: 'meta' });
    const req = https.request(NATIVE_REST_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      res.on('data', () => {});
      res.on('end', () => {
        const end = process.hrtime.bigint();
        resolve(Number(end - start) / 1e6); // ms
      });
    });
    req.on('error', () => resolve(-1));
    req.write(data);
    req.end();
  });
}

function measureEvm() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const body = JSON.stringify({ jsonrpc: '2.0', method: 'eth_blockNumber', params: [], id: 1 });
    const req = https.request(EVM_RPC_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      res.on('data', () => {});
      res.on('end', () => {
        const end = process.hrtime.bigint();
        resolve(Number(end - start) / 1e6);
      });
    });
    req.on('error', () => resolve(-1));
    req.write(body);
    req.end();
  });
}

function measureWs() {
  return new Promise((resolve) => {
    const start = process.hrtime.bigint();
    const ws = new WebSocket(WS_URL);
    ws.on('open', () => {
      ws.send(JSON.stringify({ method: 'subscribe', subscription: { type: 'allMids' } }));
    });
    ws.on('message', () => {
      const end = process.hrtime.bigint();
      ws.close();
      resolve(Number(end - start) / 1e6);
    });
    ws.on('error', () => resolve(-1));
  });
}

async function main() {
  const restTimes = [];
  const evmTimes = [];
  const wsTimes = [];
  for (let i = 0; i < 5; i++) {
    restTimes.push(await measureRest());
    evmTimes.push(await measureEvm());
    wsTimes.push(await measureWs());
  }
  const avg = (arr) => arr.reduce((a, b) => a + b, 0) / arr.length;
  console.log('Native REST (info) latency (ms):');
  console.log('  avg:', avg(restTimes).toFixed(2), 'min:', Math.min(...restTimes).toFixed(2), 'max:', Math.max(...restTimes).toFixed(2));
  console.log('HyperEVM eth_blockNumber latency (ms):');
  console.log('  avg:', avg(evmTimes).toFixed(2), 'min:', Math.min(...evmTimes).toFixed(2), 'max:', Math.max(...evmTimes).toFixed(2));
  console.log('WebSocket allMids first message latency (ms):');
  console.log('  avg:', avg(wsTimes).toFixed(2), 'min:', Math.min(...wsTimes).toFixed(2), 'max:', Math.max(...wsTimes).toFixed(2));
}

main();

Expected Output and Results Table

The script will output something like the following (values are examples, not benchmarks):

Fill in the table below with your own results. This is a measurement method, not a vendor benchmark. For provider-specific numbers, refer to independent sources like Dwellir's guide or hyperpc's comparison, which have their own methodologies.

• Native REST (info) latency (ms): avg: 12.34, min: 10.11, max: 15.67
• HyperEVM eth_blockNumber latency (ms): avg: 45.67, min: 40.23, max: 52.10
• WebSocket allMids first message latency (ms): avg: 8.90, min: 7.12, max: 11.45

| Endpoint | Avg (ms) | Min (ms) | Max (ms) |
|----------|----------|----------|----------|
| Native REST (info) | | | |
| HyperEVM eth_blockNumber | | | |
| WebSocket allMids | | | |

Common Failures and Fixes

When measuring or using Hyperliquid RPC, you may encounter several common issues. Here are the most frequent ones and how to fix them.

Rate limiting on the HyperEVM RPC: The public endpoint allows about 100 requests per minute per IP. If you exceed this, you'll get HTTP 429 responses or dropped connections. Fix: implement client-side rate limiting, use a dedicated endpoint from a provider, or batch requests. See the Hyperliquid API rate limits guide for details.

WebSocket disconnections: The native WebSocket may disconnect if you don't send a ping within a certain interval. Fix: implement a heartbeat mechanism. The Hyperliquid WebSocket subscriptions guide covers this.

High latency due to geo-distance: If you're far from the Hyperliquid infrastructure, latency will be higher. Fix: use a geo-distributed provider or run your own node in a region close to the validators. For low-latency trading, consider a dedicated endpoint like HypeRPC, which is optimized for speed.

Archive node reads on HyperEVM: Reading historical state can be slow. Fix: use a provider that offers archive nodes, or cache frequently accessed data.

• Rate limiting: implement backoff and retry, or use a dedicated endpoint.
• WebSocket timeouts: send pings regularly.
• Geo-distance: choose a provider with nodes near Hyperliquid's validators.
• Archive reads: use a provider with archive nodes or cache.

Low-Latency Tuning: Best Practices

To achieve the lowest possible latency for Hyperliquid trading, follow these best practices:

First, prefer the native WebSocket feeds for real-time market data. The allMids and l2Book subscriptions push updates as soon as they are available, eliminating the need for polling. Polling the REST API adds at least one round-trip time and can miss updates between polls.

Second, on the HyperEVM side, batch JSON-RPC requests to reduce the number of round trips. For example, instead of calling eth_getBalance for multiple addresses, use eth_getProof or a custom batch. Also, cache state reads that don't change frequently, such as token decimals or contract metadata.

Third, set explicit timeouts on all HTTP and WebSocket connections. This prevents requests from hanging and allows you to fail fast and retry. Use a library like axios with a timeout option, or set the timeout in your WebSocket client.

Fourth, use a geo-distributed or dedicated endpoint. For low-latency trading, consider a provider like HypeRPC, which is specifically designed for low-latency access to Hyperliquid. Alternatively, run your own node in a region close to the Hyperliquid validators. The Hyperliquid RPC endpoints (RPC Assistant) page lists available endpoints.

Finally, monitor your latency continuously. Use the measurement script above as a baseline and track changes over time. This helps you detect issues early and adjust your setup.

• Use native WebSocket feeds for real-time data.
• Batch JSON-RPC on the EVM side.
• Cache state reads.
• Set explicit timeouts.
• Use a geo-distributed or dedicated endpoint.
• Monitor latency regularly.

Tradeoffs and Limitations

While the native API offers lower latency, it has limitations. The WebSocket feeds are unauthenticated and may have higher latency during high load. The REST API is rate-limited, though the limits are higher than the EVM RPC. For the HyperEVM, the main limitation is the rate limit and the lack of low-latency guarantees.

Another tradeoff is the complexity of running your own node. While it gives you the lowest latency, it requires significant infrastructure and maintenance. Using a third-party provider like Dwellir or hyperpc is easier but introduces network overhead.

Also, note that the public HyperEVM RPC's rate limit is approximately 100 req/min per IP, which is documented by providers. This can be a bottleneck for applications that need frequent state reads. In such cases, consider using a dedicated endpoint or a provider that offers higher limits.

Finally, latency measurements are highly dependent on your network path and the provider's infrastructure. The numbers you get from the script are specific to your environment and should not be compared directly to vendor benchmarks. Always refer to independent sources for provider comparisons.

• Native API: lower latency but rate limits and potential load issues.
• HyperEVM: higher latency and strict rate limits.
• Running your own node: lowest latency but high maintenance.
• Third-party providers: easier but add network overhead.
• Measurements are environment-specific.

Next Steps

Now that you understand how to measure and tune Hyperliquid RPC latency, you can apply these techniques to your own applications. For more details, explore the following resources:

Check the Hyperliquid network overview for general information. For a deeper dive into rate limits, see the Hyperliquid API rate limits guide. If you're using WebSockets, the Hyperliquid WebSocket subscriptions guide is essential. You can also browse the OnFinality Learn hub for more guides. For pricing on dedicated endpoints, see RPC pricing and the API service. Finally, the Hyperliquid RPC endpoints (RPC Assistant) page lists all available endpoints.

• Hyperliquid network overview
• Hyperliquid API rate limits guide
• Hyperliquid WebSocket subscriptions guide
• OnFinality Learn hub
• RPC pricing
• API service
• Hyperliquid RPC endpoints (RPC Assistant)