RPC

Read balances and contract state, submit signed transactions, and react to new blocks without running your own nodes.

Interface: JSON-RPC · WebSocket
Best for: Wallets, bots, and backends that read chain state or submit transactions.

Create account Read the docs

Your app JSON-RPC JSON-RPC

GraphOps RPC RPC

Ethereum New blocks Blocks

Pool contract state

Request parameters

slot0 · liquidity · USDC and WETH balanceOf

Request excerpt. See the service quickstart for authentication and a complete example.

JSON-RPC parameters

// WebSocket: follow each new Ethereum head.
{"method":"eth_subscribe","params":["newHeads"]}
// HTTPS: one batch per head, every read pinned to its hash.
[{"method":"eth_getBlockTransactionCountByHash",
  "params":["<head hash>"]},
 {"method":"eth_call","params":[
  {"to":"0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640",
   "data":"0x3850c7bd"},
  {"blockHash":"<head hash>","requireCanonical":true}]}]
// The batch adds liquidity() and each token's balanceOf(pool).
// slot0() gives sqrtPriceX96. The collector computes USDC per WETH.

USDC / WETH pool state

Loading response data

What you get

EVM state reads over HTTPS and WebSocket
Transaction submission and receipt tracking
Logs and filters with WebSocket subscriptions
Bitcoin RPC over HTTPS

Choose RPC when

Your application needs native EVM or Bitcoin node methods.
Your application submits signed transactions.
Your team already uses an EVM library such as viem, go-ethereum, alloy, or web3.py and decides how calls combine.

Use another service when

You want indexed entities and relationships through GraphQL rather than composing node calls.
Subgraphs
Your pipeline must process every block or event in order into your own storage.
Substreams

What you can build with RPC

Each pattern uses documented EVM JSON-RPC methods and works with any EVM client library. Your application decides how requests combine and where results are stored.

01 eth_getBlockByNumber · eth_call · eth_getBalance

Consistent reads at one block

Price a pool, value a portfolio, or check a position from several reads that must describe the same chain state. Separate latest reads can land on different blocks, so resolve one block and pass its number or hash to every call.
1. Select a block with eth_blockNumber, safe, or finalized, and store its number or hash.
2. Pass that reference to each eth_call, eth_getBalance, or eth_getStorageAt request.
3. Combine the results knowing they describe one block.
You own
Choosing the block reference and carrying it through the workflow.
Plan for
A recent block can still be reorganized. Use safe or finalized when stability matters more than freshness.
Read contract state at a chosen block(opens in a new tab)
All three reads name block N, so price, liquidity, and balance describe one chain state. The pool example at the top of this page pins its reads to one block hash the same way.
02 eth_getLogs · fromBlock · toBlock

Event history in bounded ranges

Build a transfer history, audit trail, or analytics table from contract events. Request logs one bounded range at a time, filtered by contract address and event topic, and record each completed range so a failed job resumes where it stopped.
1. Filter eth_getLogs by contract address and event topic.
2. Start with a narrow range and widen it only after observing response size and latency.
3. Write logs idempotently by (blockHash, transactionHash, logIndex), then store the last completed block.
You own
Range sizing, progress storage, and deduplication.
Plan for
Older ranges need archive access on the network you choose, and broad ranges can hit response-size or timeout limits.
Backfill historical events(opens in a new tab)
Two ranges are stored, one is in flight, and one waits. After a failure the job resumes from the last completed block.
03 eth_sendRawTransaction · eth_getTransactionReceipt

Transaction submission and receipts

Send payments, swaps, or contract calls signed in your wallet or signer service. GraphOps RPC broadcasts the signed payload and does not custody private keys. Store the transaction hash before reporting success, then poll for the receipt and apply your own confirmation policy.
1. Check eth_chainId and plan fees with eth_estimateGas and eth_feeHistory before signing.
2. Broadcast with eth_sendRawTransaction and store the returned hash.
3. Poll eth_getTransactionReceipt until it returns a receipt, then wait for the finality your workflow needs.
You own
Signing, nonce and fee policy, and confirmation rules.
Plan for
Retrying the same signed transaction is usually safe because its hash is deterministic. Do not change gas, nonce, or value and resend blindly.
Send a raw transaction(opens in a new tab)
The hash comes back at submission. The receipt shows inclusion in block N, and your policy decides when that block is final enough.
04 eth_subscribe · newHeads · logs

Live events over WebSocket subscriptions

Update balances, send notifications, or start jobs as new heads and matching logs arrive through WebSocket subscriptions. Connections can drop, so record the last block you processed and backfill any gap with eth_getLogs after you resubscribe. Treat logs marked removed: true as reversals.
1. Subscribe to newHeads or filtered logs with eth_subscribe.
2. Store the last processed block and log identity.
3. After a disconnect, reconnect with backoff, resubscribe, and backfill missed blocks with eth_getLogs.
You own
Reconnects, gap backfills, and deduplication.
Plan for
A new subscription delivers new events only. Blocks missed while disconnected need your backfill.
Handle live events and reconnects(opens in a new tab)
Blocks N+2 and N+3 arrived while the socket was down. One bounded eth_getLogs request fills the gap.

What GraphOps runs and what you own

GraphOps operates the nodes and endpoints. Your application keeps control of every request and of anything it stores.

Your application owns

Request composition, batching, and retries
Block references for related reads
Signing keys, nonces, and confirmation policy
Any indexing or storage built from responses

GraphOps runs

EVM and Bitcoin nodes behind authenticated endpoints
HTTPS for EVM and Bitcoin, WebSocket for EVM
Organization API keys, usage metering, and credits

Networks

Choose an EVM chain or Bitcoin network from the live catalog below. Archive access varies by network.

See supported networks

Limits to plan for

Request rate, concurrency, batch size, response size, and WebSocket limits are shared across your organization.
Archive reads and broad log scans can cost more credits than current-state reads. Split them into ranges.
Rate-limit headers are informational. Handle 429 responses with backoff and jitter.

Usage and limits

Supported networks

Choose an EVM chain or Bitcoin network from the live catalog below. Archive access varies by network.

Loading the live network catalog

Plan your integration

Go from a new organization to a first response, then prepare for production traffic.

01

Create an organization and add credits

Choose your monthly credits or buy a top-up. RPC calls and subscription events consume credits at the current rates.
02

Create an API key for RPC

Send it in an Authorization header, or in the endpoint path for WebSocket and HTTPS clients that cannot set headers.
03

Choose a network endpoint

The EVM path ends in the chain ID, and Bitcoin endpoints use a network name. Copy the exact endpoint from the network catalog.
04

Read the latest block

Run eth_blockNumber with curl or your EVM library to confirm the key and endpoint.
05

Prepare for production

Bound request concurrency, back off after 429 responses, pin related reads to one block, and split broad log scans into ranges.

Endpoints

EVM over HTTPSReads, batches, and transaction submission: https://rpc.graphops.xyz/v1/evm/<chainId>
EVM over WebSocketSubscriptions to new heads and logs: wss://rpc.graphops.xyz/v1/evm/<chainId>
Bitcoin over HTTPSBitcoin Core-compatible RPC: https://rpc.graphops.xyz/v1/bitcoin/<network>

EVM supports HTTPS and WebSocket. Bitcoin supports HTTPS. Check the network documentation for endpoints and archive access.

Prerequisites

Set GRAPHOPS_API_KEY to your GraphOps API key.

CLI · curl

Example project

curl --fail-with-body --silent --show-error "https://rpc.graphops.xyz/v1/evm/1" \
  -H "Authorization: Bearer ${GRAPHOPS_API_KEY}" \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_blockNumber",
    "params": []
  }'

Make your first RPC request

Read your first block.

Create an organization, add credits, and follow the RPC quickstart with your API key.

Create account Read RPC docs

RPC

USDC / WETH pool state

What you get

Choose RPC when

Use another service when

Consistent reads at one block

Event history in bounded ranges

Transaction submission and receipts

Live events over WebSocket subscriptions

Your application owns

GraphOps runs

Networks

Limits to plan for

Create an organization and add credits

Create an API key for RPC

Choose a network endpoint

Read the latest block

Prepare for production

Endpoints

Read your first block.