Closed beta guide

rpcbox is Ethereum JSON-RPC with a different contract: every block is verified against the proposer's signature, every receipt against the committed receipts root — and when anything degrades you get higher latency, never wrong data. The numbers we advertise are live production metrics, not claims.

Quickstart

1

Redeem your invite code

Go to /account and paste your invite code (RPCBOX-XXXX-XXXX-XXXX) into "Redeem an invite code". Your API key is shown exactly once — store it somewhere safe. Redemption activates the Growth tier and credits your account; no card is required during beta. The same page is your usage dashboard afterwards: per-method request counts, latencies, egress, credit balance. The key travels only in the Authorization header and is never persisted by the page.

2

First request

curl -s https://8-232-23-170.sslip.io/v1/evm/1 \
  -H 'Authorization: Bearer <YOUR_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["latest",false]}'

Receipts — root-verified at the tip, available ~200ms after the block:

curl -s https://8-232-23-170.sslip.io/v1/evm/1 \
  -H 'Authorization: Bearer <YOUR_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionReceipt","params":["0x<TX_HASH>"]}'
3

viem

import { createPublicClient, http } from 'viem'
import { mainnet } from 'viem/chains'

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://8-232-23-170.sslip.io/v1/evm/1', {
    fetchOptions: { headers: { Authorization: 'Bearer <YOUR_KEY>' } },
  }),
})

const block = await client.getBlockNumber() // served hot from memory

Ponder and other standard JSON-RPC indexers work with zero code change — point the RPC URL at the endpoint and set the header.

Coverage, honestly

The full per-method table with live-measured latencies is on the landing page. The short version:

GroupStatus
Tip reads — eth_blockNumber, eth_getBlockBy*, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getLogs (tip ranges), eth_chainId HOT

Served from process memory in µs–low-ms, verified (proposer signature + receipts root). Hot window ≈ the freshest ~2,000 blocks.

Historical reads — eth_getLogs, eth_getBlockBy*, eth_getBlockReceipts, traces PROXIED

Data-lake proxy, ~150–250ms; a prefetching cache tier is rolling out (repeat/range scans already serve warm in tens of ms). Same verified answers, just slower.

State methods — eth_call, eth_estimateGas, eth_getBalance, eth_getCode, eth_getStorageAt, eth_getTransactionCount STUB

Do not use yet. Deterministic synthetic responses (recognizable, never real chain state) while the state backend is built. The real state tier swaps in behind the same interface.

eth_subscribe / filter methods NOT YET

Returns -32601. See failover semantics for why.

eth_sendRawTransaction, eth_gasPrice, eth_maxPriorityFeePerGas, eth_feeHistory NOT YET

Returns -32601.

Methods not listed return -32601. If a method is stubbed or missing we say so here before you find out in production.

Failover semantics

The endpoint is served by multiple identical boxes behind a load balancer with client-IP affinity; unhealthy boxes are ejected automatically. Each box independently verifies every block and every receipt, so a box switch never changes what's true — at worst it looks like a ≤1 block reorg: the new box's latest may briefly trail or lead the old one by one block, exactly the consistency model you already handle for a single well-behaved node at the chain tip. No server-side session state is used for request serving, so nothing is lost on a switch. Stateful APIs (eth_subscribe, filters) remain unsupported until they are sticky-aware. Account mutations (code redemption, credits) are handled by a single ledger authority; if it is briefly unreachable you get an honest 503 with Retry-After — never a double-applied operation.

Known limitations (beta)

Support

Beta support runs through sqd.dev/contact — mention rpcbox beta and your key_id (shown on /account; never send the key itself). Bug reports that include a request body + the id of the JSON-RPC call get the fastest turnaround. We typically respond within one business day; the beta Telegram group is fastest.

Receipts, tip vs historical

eth_getTransactionReceipt serves from the verified hot window (~last 2,000 blocks). For historical receipts use eth_getBlockReceipts(blockNumber) — one call, every receipt in the block, faster for indexing. Per-tx historical lookup returns -32601 today; a tx-hash index is on the roadmap.

Client auth wiring

Auth is the Authorization: Bearer <KEY> header — keys in the URL are not supported. viem/Ponder: http(url, { fetchOptions: { headers: { Authorization: "Bearer KEY" } } }).