RPC that behaves the way your tooling expects.

Standard Ethereum JSON-RPC for HyperEVM (reads, logs, receipts, and eth_sendRawTransaction) that behaves the way your tooling expects.

Your problem

The parts you keep working around.

01

Nonstandard RPC behavior breaks viem/ethers in ways you find in production.

02

Log indexing dies on providers with tight eth_getLogs limits.

03

Transaction broadcast needs to work the first time, every time.

The proof

A round-trip you can watch.

Standard JSON-RPC against rpc.hyperliquidrpc.com. The latency stamp is the published p50 from Frankfurt. Replay it as many times as you like.

POSTrpc.hyperliquidrpc.com

request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_blockNumber",
  "params": []
}

response4.2 ms

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x7b2a4f1"
}

eth_blockNumber shown; the full eth_* read set, eth_getLogs, receipts, and eth_sendRawTransaction work the same way: one key header, standard everything else.

Integration sketch

Point viem at it.

Add the key header to your transport and keep everything else. HyperCore /info rides the same key when you need CLOB state next to EVM state.

Read the docs
import { createPublicClient, http } from "viem"; const client = createPublicClient({  transport: http("https://rpc.hyperliquidrpc.com", {    fetchOptions: { headers: { "x-api-key": "YOUR_KEY" } },  }),}); const block = await client.getBlockNumber();const logs = await client.getLogs({ fromBlock: block - 1000n });
Where to start

The plan that fits.

Pro

$49/moRecommended

Every stream, production rate limits.

Pro's 250 req/s carries most production dApps; indexers should size with the pricing calculator and step up to Ultra's 1,000 req/s when needed.

Compare both plans

Build against it today.

Pro carries most production dApps at 250 req/s; Ultra serves indexers at 1,000 req/s.