Multi-chain RPC API

BlockRun RPC vs traditional providers

Row-by-row against one vendor: BlockRun vs Alchemy.

How it works

Send a standard JSON-RPC request and choose the chain in the path — POST /v1/rpc/{network}. With no payment header you get an HTTP 402 quoting the exact price ($0.003); add an x402 payment header (a wallet signature) and you get the result, settled on-chain.

curl -X POST https://blockrun.ai/v1/rpc/ethereum \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","id":1}'
# → 402 with price $0.0030 + Base USDC payment instructions

What it returns, measured

One call per chain, three runs each, through the gateway on 2026-09-21. Times are the whole round trip from a laptop, so they include TLS and the trip to us — not a node-side number measured next to the node.

Solana is in the same table on purpose. It is not an eth_* chain and it does not pretend to be — you send its own method names to /v1/solana/rpc and get Solana's own reply shape back. Nothing is normalised into a common envelope, because a normalised envelope is a second thing to learn and a place for a bug to hide.

A 200 does not mean the call worked

This is JSON-RPC, not REST, and the two disagree about what a status code is for. The transport succeeding and the call succeeding are different events, and only the first one shows up in the status:

# HTTP 200 — and the call failed
{"id":1,"jsonrpc":"2.0",
 "error":{"code":-32601,"message":"Method not found: eth_nonsense"}}

Check for an error member in the body, not for a status. A client that branches on res.ok alone will read that as a success and carry an undefined result forward. This is standard JSON-RPC behaviour rather than anything we added, and it is the mistake that costs the most time here.

Where the status code does mean something

A wrong network slug is a real HTTP error, and it says explicitly that nothing was charged:

# HTTP 404
{"error":"Bad Request",
 "message":"notachain RPC rejected the request (check the network
            slug + JSON-RPC body). Payment was NOT charged."}

Batching, and what a batch costs

Send a JSON array and you get an array back. Three calls against Base in one request returned in about a second on 2026-09-21 — roughly what one call costs in time, because the round trip is paid once:

[{"id":1,"jsonrpc":"2.0","result":"0x3131c2b"},
 {"id":2,"jsonrpc":"2.0","result":"0x2105"},
 {"id":3,"jsonrpc":"2.0","result":"0x5b8d80"}]

The time is shared; the price is not. A batch is charged per element, at $0.003 each, so three calls in one request cost the same as three requests. Batch to save round trips, not money.

What “no API key” actually costs you

The comparison table above is one-sided, so here is the other side. Removing the key does not remove the setup — it moves it. You do not open an account, and instead you fund a wallet with USDC on Base and hold a signing key your code can reach. For an agent that already has a wallet that is nothing; for a team that has never touched a chain it is a larger first step than pasting a key from a dashboard.

The honest summary: this is cheaper and simpler once a funded wallet exists, and more work than a dashboard until one does. If you want a key instead of a wallet, a registered key from the RPC service page reaches the same endpoint.

FAQ