Introduction
BoltRPC is a production-grade RPC node service giving developers instant access to 36 blockchain networks through a single, unified API. Whether you're building DeFi protocols, NFT platforms, wallets, or indexers - BoltRPC handles the infrastructure so you don't have to.
Quick Start
Get your first response in under 60 seconds.
Get your API key
Sign up at dashboard.boltrpc.io. Free 14-day trial with 5M request units at 100 req/s, instant key delivery, no credit card. Add a card any time to keep going with on-demand usage, no plan needed.
Get free API keyMake your first request
Replace YOUR_API_KEY in the endpoint URL and send a JSON-RPC request to any supported network.
Step 2: Make your first request
curl -s -X POST \
"https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'Response
{
"jsonrpc": "2.0",
"id": 1,
"result": "0x14a5f3b"
}ethereum in the URL with any network slug from the Supported Networks table to switch chains instantly.Authentication
Your API key is embedded directly in the endpoint URL. No extra headers required.
https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/{network}
wss://endpoints.boltrpc.io/ws/YOUR_API_KEY/{network}BOLTRPC_URL=https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereumSupported Networks
All networks below are available via both HTTPS and WebSocket unless noted. Each network name links to its page with the RPC URL, chain ID and connection examples, for example the Ethereum RPC endpoint, Base RPC and BNB Chain (BSC) RPC.
| Network | Slug | Chain ID | HTTPS | WebSocket | gRPC |
|---|---|---|---|---|---|
| ApeChain | ape | 33139 | ✓ | ✓ | n/a |
| Aptos | aptos | n/a | ✓ | ✓ | n/a |
| Arbitrum One | arbitrum | 42161 | ✓ | ✓ | n/a |
| Avalanche | avax | 43114 | ✓ | ✓ | n/a |
| Base | base | 8453 | ✓ | ✓ | n/a |
| Bitcoin | bitcoin | n/a | ✓ | ✓ | n/a |
| BNB Smart Chain | bsc | 56 | ✓ | ✓ | n/a |
| BOB | bob | 60808 | ✓ | ✓ | n/a |
| Celo | celo | 42220 | ✓ | ✓ | n/a |
| Enjin | n/a | n/a | public | public | n/a |
| Ethereum | ethereum | 1 | ✓ | ✓ | n/a |
| Ethereum Beacon | ethereum-beacon | n/a | ✓ | ✓ | n/a |
| Ink | ink | 57073 | ✓ | ✓ | n/a |
| Katana | katana | 747474 | ✓ | ✓ | n/a |
| Linea | linea | 59144 | ✓ | ✓ | n/a |
| Mantle | mantle | 5000 | ✓ | ✓ | n/a |
| MegaETH | megaeth | 4326 | ✓ | ✓ | n/a |
| Monad | monad | 143 | ✓ | ✓ | n/a |
| Optimism | optimism | 10 | ✓ | ✓ | n/a |
| Plasma | plasma | 9745 | ✓ | ✓ | n/a |
| Polygon | polygon | 137 | ✓ | ✓ | n/a |
| Robinhood Chain | robinhood | 4663 | ✓ | ✓ | n/a |
| Scroll | scroll | 534352 | ✓ | ✓ | n/a |
| Solana | solana | 101 | ✓ | ✓ | n/a |
| Sonic | sonic | 146 | ✓ | ✓ | n/a |
| Starknet | starknet | SN_MAIN | ✓ | ✓ | n/a |
| Sui | sui | 897796746 | ✓ | ✓ | native |
| Tron | tron | 728126428 | ✓ | ✓ | native |
| Unichain | unichain | 130 | ✓ | ✓ | n/a |
| X Layer | xlayer | 196 | ✓ | ✓ | n/a |
| zkSync Era | zksync | 324 | ✓ | ✓ | n/a |
| Ethereum Hoodi | ethereum-hoodi | 560048 | ✓ | ✓ | n/a |
| Ethereum Hoodi Beacon | ethereum-hoodi-beacon | n/a | ✓ | ✓ | n/a |
| Ethereum Sepolia | ethereum-sepolia | 11155111 | ✓ | ✓ | n/a |
| Ethereum Sepolia Beacon | ethereum-sepolia-beacon | n/a | ✓ | ✓ | n/a |
| Polygon Amoy | polygon-amoy | 80002 | ✓ | ✓ | n/a |
| Enjin Relay Chain | n/a | n/a | public | public | n/a |
gRPC: native HTTP/2 on endpoints.boltrpc.io:443 plus gRPC-Web at /grpc/<slug>, see Native gRPC.
Hyperliquid support coming soon.
Connecting
EVM Networks
All EVM chains share the same URL pattern. Only the network slug changes.
HTTPS endpoint
https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/{network}WebSocket endpoint
wss://endpoints.boltrpc.io/ws/YOUR_API_KEY/{network}One request that works across every EVM chain
# Set your target network
BOLTRPC_URL="https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/base"
curl -s -X POST "$BOLTRPC_URL" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'Ethereum testnets
# Sepolia: dApp development & smart contract testing
https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum-sepolia
# Hoodi: validator infrastructure & staking
https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum-hoodiBeacon Chain REST API
The Ethereum Beacon Chain API is a REST API, not a JSON-RPC interface. It exposes consensus layer data: validators, slots, epochs, finality checkpoints, and withdrawal information. It does not support eth_* methods.
Authentication: Beacon endpoints authenticate the same way as EVM endpoints: the API key is embedded in the URL path, with the REST path appended after the network slug.
| Network | Base URL |
|---|---|
| Mainnet Beacon | ...boltrpc.io/rpc/YOUR_API_KEY/ethereum-beacon |
| Sepolia Beacon | ...boltrpc.io/rpc/YOUR_API_KEY/ethereum-sepolia-beacon |
| Hoodi Beacon | ...boltrpc.io/rpc/YOUR_API_KEY/ethereum-hoodi-beacon |
WebSocket: the Beacon API itself is REST, but wss://endpoints.boltrpc.io/ws/YOUR_API_KEY/ethereum-beacon streams one newHeads notification per slot (subscribe with eth_subscribe), gap-free across failover.
Event stream (GET /eth/v1/events)
/eth/v1/events?topics=head (or any other topic list) streams beacon events as server-sent events. Each delivered event bills once, like a WebSocket message; a stream that opens is free to open, and the keep-alive comments sent during quiet spells are free.
The gateway checks an open stream's key again about once a minute. When the key is disabled or expires, the account is blocked, the network is paused, switched off or no longer covered by the key, the request units or the on-demand spending limit run out, a team member reaches the usage limit the owner set, or no plan pays for the key, the stream ends within about a minute. It normally ends with a comment that names the reason and a retry field, for example:
: stream closed: Key revoked
retry: 60000A comment is never dispatched as an event, so an EventSource only sees the stream end; the refusal body of a reconnect says why. For the four request-unit cases the comment carries the matching WebSocket close code 4029 sentence; every other reason reads Key revoked. A reconnect is refused like any new request: 401 for a disabled or expired key, 403 for a blocked account, a paused, switched off or uncovered network, or no active plan, and 429 when the request units, the on-demand spending limit or a team member's usage limit are used up. The retry: 60000 asks clients that retry on their own to wait a minute. A browser EventSource, and libraries that follow the SSE spec, stop for good on a 401, 403 or 429 and do not reconnect by themselves: open a new stream once the cause is fixed.
Every stream also ends after about 22 to 24 hours (the exact moment varies per stream so that streams do not all reconnect at once), with the comment : stream closed: maximum stream lifetime reached, reconnect and retry: 3000. Reconnect at once.
A stream also ends, without a closing comment, when the node behind it stops or fails over, after 15 minutes without any data from the node, and when the gateway restarts. Reconnect at once; the new stream picks a healthy node. A key may hold up to 20 open event streams per network on each gateway server; a further open is refused with 429 and the body {"error":"too many concurrent event streams; close one and retry"}.
The Beacon API event stream has no replay: events carry no id and a reconnect starts at the live head, so fetch anything you missed from the REST paths (for example /eth/v1/beacon/headers/head or /eth/v2/beacon/blocks/head).
Check sync status
curl "https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum-beacon/eth/v1/node/syncing"Get finality checkpoints
curl "https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum-beacon/eth/v1/beacon/states/finalized/finality_checkpoints"Common Beacon API paths
| Path | Description |
|---|---|
GET /eth/v1/node/syncing | Node sync status and head slot |
GET /eth/v1/beacon/headers/head | Latest beacon block header |
GET /eth/v2/beacon/blocks/{block_id} | Full beacon block including execution payload |
GET /eth/v1/beacon/states/{state_id}/finality_checkpoints | Justified and finalized epochs |
GET /eth/v1/beacon/states/head/validators/{index} | Single validator status and balance |
GET /eth/v1/beacon/states/head/validators?status=active_ongoing | Filtered validator set |
Starknet
| Environment | HTTPS | WebSocket |
|---|---|---|
| Mainnet | ...boltrpc.io/rpc/YOUR_API_KEY/starknet | ...boltrpc.io/ws/YOUR_API_KEY/starknet |
Example: get block number
curl -X POST "https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/starknet" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"starknet_blockNumber","params":[],"id":1}'WebSocket subscription
{"jsonrpc":"2.0","id":1,"method":"starknet_subscribe","params":["newHeads"]}Enjin public · no key
Both Enjin endpoints are public. No API key required.
| Chain | HTTPS | WebSocket |
|---|---|---|
| Matrix Chain | https://enjin-matrix-chain.matrixed.link | wss://enjin-matrix-chain.matrixed.link |
| Relay Chain | https://enjin-relay-chain.matrixed.link | wss://enjin-relay-chain.matrixed.link |
# Matrix Chain: HTTPS (node health)
curl -s -X POST "https://enjin-matrix-chain.matrixed.link" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"system_health","params":[],"id":1}'
# Relay Chain: HTTPS (finalized head)
curl -s -X POST "https://enjin-relay-chain.matrixed.link" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"chain_getFinalizedHead","params":[],"id":1}'
# Matrix Chain: WebSocket (subscribe to new heads)
wscat -c wss://enjin-matrix-chain.matrixed.linkCode Examples
const BOLTRPC_URL = "https://endpoints.boltrpc.io/rpc/YOUR_API_KEY/ethereum";
async function getBlockNumber() {
const res = await fetch(BOLTRPC_URL, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ jsonrpc: "2.0", method: "eth_blockNumber", params: [], id: 1 }),
});
const data = await res.json();
console.log("Latest block:", parseInt(data.result, 16));
}
getBlockNumber();API Reference
Ethereum / EVM Methods
General: Web3, Net, Txpool
| Method | Description | RU |
|---|---|---|
web3_clientVersion | Returns the current client version | 3 |
web3_sha3 | Returns Keccak-256 hash of the given data | 3 |
net_version | Returns the network/chain ID | 3 |
net_listening | Whether the client is listening for peers | 3 |
net_peerCount | Number of connected peers | 3 |
txpool_status | Pending/queued tx counts (Geth only) | 6 |
txpool_inspect | Text summary of txpool (Geth only) | 6 |
txpool_content | Whole-mempool dump: blocked on every key | n/a |
txpool_contentFrom | Mempool dump for an address: blocked on every key | n/a |
Ethereum Core
| Method | Description | RU | Notes |
|---|---|---|---|
eth_syncing | Node sync status | 3 | |
eth_chainId | Current chain ID | 3 | Preferred over net_version for EIP-155 |
eth_gasPrice | Current gas price in wei | 3 | Consider EIP-1559 fields instead |
eth_maxPriorityFeePerGas | Suggested tip (wei) | 3 | EIP-1559 |
eth_blockNumber | Latest block number | 3 | |
eth_getBalance | Balance of an address | 3 | |
eth_getCode | Contract bytecode at address | 3 | |
eth_getStorageAt | Value at a storage slot | 3 | Archive required for historical blocks |
eth_getTransactionCount | Nonce / tx count for address | 3 | |
eth_call | Read-only call (no state change) | 3 | |
eth_estimateGas | Gas estimate for a call/tx | 3 | |
eth_sendRawTransaction | Broadcast a signed transaction | 5 | Recommended for production |
eth_getTransactionByHash | Transaction by hash | 3 | |
eth_getTransactionReceipt | Transaction receipt | 3 | |
eth_getBlockByNumber | Block by number | 3 | |
eth_getBlockByHash | Block by hash | 3 | |
eth_getLogs | Logs matching filter criteria | 4 | No block-range cap; up to 250,000 logs per request, see Request limits |
eth_newFilter | Create a log filter | 3 | Filter ids are pinned to the node that created them |
eth_newBlockFilter | Filter for new blocks | 3 | |
eth_newPendingTransactionFilter | Filter for pending txs | 3 | |
eth_getFilterChanges | Poll filter deltas | 3 | Always reaches the owning node |
eth_getFilterLogs | All logs for a filter | 3 | |
eth_uninstallFilter | Remove a filter | 3 | |
eth_subscribe | Subscribe to event stream | 3 | WebSocket only; every pushed message bills once |
eth_unsubscribe | Cancel a subscription | 3 | WebSocket only |
eth_getProof | Account/storage Merkle proof | 3 |
Debug & Trace (per chain)
Whether a chain answers debug_* and trace_* depends on its node clients, not on your plan: the Networks page shows the trace and debug support of every chain, and every plan gets what the chain offers at the weights below. The three unbounded state-iteration methods (debug_accountRange, debug_storageRangeAt, debug_dumpBlock) walk a whole trie from one call; they are off by default and enabled per account on request from Business upward. Contact us to enable them.
| Method | Description | RU | Notes |
|---|---|---|---|
debug_traceTransaction | Opcode-level trace for a tx | 6 | |
debug_traceBlockByHash | Trace all txs in a block (by hash) | 6 | |
debug_traceBlockByNumber | Trace all txs in a block (by number) | 6 | |
debug_traceCall | Trace a simulated call | 6 | |
debug_accountRange | Iterate the account trie | 6 | On request (unbounded) |
debug_storageRangeAt | Iterate a contract's storage | 6 | On request (unbounded) |
debug_dumpBlock | Full state dump at a block | 3 | On request (unbounded) |
trace_call | Trace a call at a given block | 6 | |
trace_transaction | Full trace of a transaction | 6 | |
trace_block | Trace all txs in a block | 6 | |
trace_replayTransaction | Replay and trace a transaction | 12 | |
trace_replayBlockTransactions | Replay block with traces | 12 | |
trace_filter | Trace logs by filter criteria | 6 | |
trace_callMany | Batch call traces | 6 |
Method Weighting
BoltRPC uses a request unit (RU) weighting system to fairly account for the varying cost of different RPC methods. RU weights are fixed and published, so you know the exact cost of every call before you build.
| RU Weight | Methods |
|---|---|
| 3 | Standard reads: eth_blockNumber, eth_getBalance, eth_call, eth_chainId and most standard methods; every WebSocket push message |
| 4 | Range and bulk queries: eth_getLogs, multi-item reads (getMultipleAccounts, sui_multiGet*), lists, simulations; a JSON-RPC batch bills each request inside it at its own weight |
| 5 | Transaction broadcast: eth_sendRawTransaction, sendTransaction, sui_executeTransactionBlock, sendrawtransaction |
| 6 | Traces and debug: debug_trace*, trace_*, txpool_status, txpool_inspect |
| 12 | trace_replayTransaction, trace_replayBlockTransactions |
| 20 | parity_listStorageKeys |
| Blocked | Not relayed on any key, on any plan: admin_*, personal_*, miner_*, engine_*, les_*, reth_*, node-control debug_* (setHead, profiling, database access), txpool_content, txpool_contentFrom, Sui unsafe_*. Bitcoin relays a read-only allowlist; the Beacon and Aptos REST doors relay documented API paths only. |
Request limits & behaviours
The bounds the gateway enforces, and what it does for you underneath. Everything here is per request and independent of your plan.
| Topic | Behaviour |
|---|---|
| Rate limit | No rate limit on monthly plans. The free trial and on-demand usage without a plan are limited to 100 requests per second (burst 200). Per-key limits and daily caps are yours to set in the dashboard. |
eth_getLogs block range | No hard block-range cap. A wide range is split into chunks and fanned out across the chain's nodes server-side, then merged into one answer and billed as one request (4 RU). A single request returns at most 250,000 logs; past that it is refused with an error that names a narrower range that fits. Each request has a 60-second deadline. |
| History below a node's floor | Every node's real history depth is verified, not taken from its earliest claim. A block-addressed request starts on a node that has the block. A log range that begins below what any node stores is refused with -32000 and data.earliestBlock naming the first stored block, never silently clamped: a partial answer is never served as complete. |
Filters (eth_newFilter family) | Filter ids are node-local by nature. The gateway tags every id with the node that created it, so eth_getFilterChanges, eth_getFilterLogs and eth_uninstallFilter always reach the owning node, on HTTP and WebSocket, on every EVM chain and on Tron's /jsonrpc door. |
| JSON-RPC batches | A batch envelope is relayed as one HTTP request and billed per request inside it, each at its own weight. A batch is routed by its heaviest member, so [eth_chainId, eth_getLogs] gets the log-query budget. |
| WebSocket ping | A JSON-RPC "ping" message sent over WebSocket is free. |
| Solana transaction v1 | Since mainnet epoch 1035 (2026-09-15) blocks carry v1 transactions. Pass maxSupportedTransactionVersion: 1 to getBlock and getTransaction or the node answers -32015; logsSubscribe needs no change. |
| Failover | A node that errors, falls behind or stops advancing is taken out of rotation automatically; requests prefer the fastest healthy nodes of each chain. WebSocket subscriptions survive a switch: the socket stays open, subscription ids stay stable, missed blocks are replayed in order and missed logs are replayed. A gap too long to replay is not sent; see failover, duplicates and gaps. |
Errors you can fix in the dashboard
When the gateway refuses a key for a reason you can fix yourself, the plain-text body says what happened and where to fix it. The status codes never change, so branch on the status, not on the text.
| Status | Situation | Body |
|---|---|---|
| 401 | A free trial's key reached its end date | Unauthorized: this key's free trial has ended. Add a card or choose a plan to re-enable the same key: https://dashboard.boltrpc.io/dashboard/billing |
| 429 | A free trial's request units are used up | Too Many Requests: your free trial's request units are used up. Add a card for pay-as-you-go usage or choose a plan to continue on the same key: https://dashboard.boltrpc.io/dashboard/billing |
| 429 | On-demand usage is on and its spending limit is reached | Too Many Requests: your on-demand spending limit is reached. Raise it in the dashboard to continue on the same key: https://dashboard.boltrpc.io/dashboard/billing |
| 429 | A plan's request units are used up and on-demand usage is off | Too Many Requests: your plan's request units are used up. Upgrade, or turn on on-demand usage, at https://dashboard.boltrpc.io/dashboard/billing |
| 429 | On-demand usage without a plan is over its rate limit | Too Many Requests: rate limit of 100 requests/second exceeded (account limit). On-demand usage without a plan is limited; choose a plan for no rate limit: https://dashboard.boltrpc.io/dashboard/billing |
| 403 | No plan pays for the key | Forbidden: no active plan pays for this key. Start a free trial, add a card, or choose a plan at https://dashboard.boltrpc.io |
Every other refusal (a wrong or disabled key, IP or origin allowlists, chain scope, per-key rate limits, daily caps, team member caps) keeps its existing body. The 429 rate-limit headers (Retry-After, X-RateLimit-*) are the same in every case.
WebSocket Subscriptions
WebSocket connections enable real-time event streaming without polling. Available on all paid plans.
Connect
wscat -c "wss://endpoints.boltrpc.io/ws/YOUR_API_KEY/ethereum"Subscribe to new block headers
{"jsonrpc":"2.0","id":1,"method":"eth_subscribe","params":["newHeads"]}Subscribe to logs (e.g. ERC-20 Transfer events)
{
"jsonrpc": "2.0",
"id": 2,
"method": "eth_subscribe",
"params": [
"logs",
{
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
}
]
}Subscribe to pending transactions
{"jsonrpc":"2.0","id":3,"method":"eth_subscribe","params":["newPendingTransactions"]}Unsubscribe
{"jsonrpc":"2.0","id":4,"method":"eth_unsubscribe","params":["YOUR_SUBSCRIPTION_ID"]}Each subscription is tied to the active connection and closes automatically when the socket disconnects.
Failover, duplicates and gaps
When a node fails, the gateway moves your socket to another node of the same chain. The socket stays open and your subscription ids stay the same. Blocks you missed during the switch are replayed in order. Missed logs are replayed too, in block order, but a replayed log can arrive after a newer live log, so do not assume log block numbers only go up. On EVM chains the replay covers up to 128 blocks for newHeads and up to 5,000 blocks for logs. Solana logsSubscribe replays up to 1,500 slots and Starknet subscribeEvents up to 100 blocks. A Solana replay also delivers at most 200 transactions. When a gap on a very busy address holds more than that, the gateway either keeps the newest 200 and does not send the older ones (the default), or, on chains where close code 4013 is enabled, sends none of them and closes the socket with the whole gap in the reason. Fetch the missing transactions with getSignaturesForAddress and getTransaction if you need every one.
Deduplicate logs and events. A new logs subscription, or a Starknet subscribeEvents subscription, may deliver events from the block in which it was created or from a few blocks before it. Deduplicate by block hash and log index, as you already do for reorgs (removed: true). Starknet events carry no index: use the transaction hash together with the event's address, keys and data.
A gap too long to replay. If a gap is longer than the replay limit, or its replay keeps failing, the missed range may not be sent and the stream continues with new blocks. On newHeads this shows as a jump in block numbers, or the stream stalls briefly first. Fetch the missing range yourself with eth_getBlockByNumber or eth_getLogs.
4013 and a reason that names the range, for example stream gap newHeads 101 to 228 not delivered, reconnect and resubscribe. The kind is newHeads, logs (also Solana logsSubscribe) or events (Starknet), and the numbers are decimal block numbers, or slots on Solana. Reconnect with a short backoff, subscribe again, and fetch the named range with a historical query (eth_getLogs or eth_getBlockByNumber on EVM chains; on Solana, getSignaturesForAddress then getTransaction for the named slots). Your other sockets stay open. A reconnected subscription starts fresh and is not closed again for the old gap.4029 within about a minute on each network. The reason says which limit was reached and is one of:Your plan's request units are used up. Upgrade or turn on on-demand usage in the dashboardOn-demand spending limit reached. Raise it in the dashboardYour team owner's usage limit for this member is reachedNo active plan for this key. Choose a plan in the dashboard
A new connection is refused the same way as a new HTTP request (429, or 403 when no plan pays for the key) until request units are available again, so do not reconnect in a tight loop.
Native gRPC (Sui Beta, Tron)
Two networks expose their native gRPC APIs on the same endpoint as everything else: Sui's sui.rpc.v2 and Tron's protocol.Wallet / protocol.WalletSolidity. Use the official generated clients unchanged.
| Door | Address | Notes |
|---|---|---|
| Native gRPC | endpoints.boltrpc.io:443 | HTTP/2; standard method paths (/sui.rpc.v2.LedgerService/GetCheckpoint, /protocol.Wallet/GetNowBlock); API key in the x-api-key metadata header |
| gRPC-Web (Sui) | https://endpoints.boltrpc.io/grpc/sui | Browser dapps, no proxy library |
| gRPC-Web (Tron) | https://endpoints.boltrpc.io/grpc/tron | Same allowlist as the HTTP wallet API |
Billing: a unary gRPC call costs the same request units as the matching JSON-RPC or HTTP method. A Sui BatchGetTransactions / BatchGetObjects call bills once, whatever the item count. Sui server streams (Subscribe*, List*) bill by delivered data: 1 RU per 24 KB, rounded up once when the stream closes; opening a stream is free; five concurrent streams per key. Tron's gRPC is unary-only. Every weight is in the calculator under the Sui and Tron gRPC groups.
Chain IDs
Use these when configuring wallets (MetaMask, Rabby) or EVM SDKs (ethers.js, viem, web3.py).
| Network | Chain ID (decimal) | Chain ID (hex) |
|---|---|---|
| ApeChain | 33139 | 0x8173 |
| Arbitrum One | 42161 | 0xa4b1 |
| Avalanche | 43114 | 0xa86a |
| Base | 8453 | 0x2105 |
| BNB Smart Chain | 56 | 0x38 |
| BOB | 60808 | 0xed88 |
| Celo | 42220 | 0xa4ec |
| Ethereum | 1 | 0x1 |
| Ink | 57073 | 0xdef1 |
| Katana | 747474 | 0xb67d2 |
| Linea | 59144 | 0xe708 |
| Mantle | 5000 | 0x1388 |
| MegaETH | 4326 | 0x10e6 |
| Monad | 143 | 0x8f |
| Optimism | 10 | 0xa |
| Plasma | 9745 | 0x2611 |
| Polygon | 137 | 0x89 |
| Robinhood Chain | 4663 | 0x1237 |
| Scroll | 534352 | 0x82750 |
| Solana | 101 | 0x65 |
| Sonic | 146 | 0x92 |
| Sui | 897796746 | 0x35834a8a |
| Tron | 728126428 | 0x2b6653dc |
| Unichain | 130 | 0x82 |
| X Layer | 196 | 0xc4 |
| zkSync Era | 324 | 0x144 |
| Ethereum Hoodi | 560048 | 0x88bb0 |
| Ethereum Sepolia | 11155111 | 0xaa36a7 |
| Polygon Amoy | 80002 | 0x13882 |
Key Restrictions
Every API key can be scoped to exactly one job, self-serve on every plan. Changes are enforced at the edge within about 30 seconds.
| Restriction | What it does |
|---|---|
| Chain scope | Limit a key to specific chains, or allow all of them. |
| IP allowlist | One IP or CIDR range per line. Requests from anywhere else are refused. |
| Origin allowlist | Lock a key to browser origins, wildcards included (https://*.example.com). Requests without a matching Origin or Referer are refused. |
| Method policy | Allow or deny individual methods or whole families like debug_*. Applies to HTTP and WebSocket. |
| Rate limit & daily cap | A per-key requests-per-second limit with burst budget, plus a hard daily request cap that resets at 00:00 UTC. |
| Expiry | An optional expiry date, or never. |
Key rotation. Rolling a key issues a new secret immediately while the old one keeps working for a grace period you pick: revoke now, 1 hour, 24 hours or 7 days. Deploys never break mid-rotation.
Usage, Alerts & Export
The dashboard's Usage & Logs view breaks traffic down by method, network, key and status, with human-readable labels for every JSON-RPC error code. History is retained for 18 months.
Export. Request logs export as CSV or NDJSON (up to 92 days and 1M rows per file); usage summaries export as CSV or JSON.
Alerts. Email alerts fire at 80%, 90% and 100% of your included request units, plus one custom threshold you pick. If you enable on-demand usage, separate alerts fire at 80, 90 and 100% of what your spending limit covers.
Teams
Invite teammates by email or link. Per member you decide:
| Policy | Effect |
|---|---|
| Billing mode | The member rides on your plan, or pays for their own subscription. |
| Chain allowance | Pin which chains the member's keys may use. |
| Usage cap | A request-unit budget per billing period; requests past it return 429. |
| Key management | Whether the member creates their own keys, or only you do. |
An organization-wide default policy applies to invites without their own. When a member leaves, their keys are disabled automatically.
Management API
Everything the dashboard does with keys is also available programmatically over a documented REST API: create, scope, restrict, rotate and revoke keys from your own tooling. The OpenAPI specification ships with your account; contact us for access details and examples.
Plans & Request Units
| Plan | Price | RUs / Month | Rate limit | Unbounded debug methods | Support |
|---|---|---|---|---|---|
| Trial | Free | 5M RUs over 14 days | 100 req/s | n/a | Community |
| On-demand | $25 per 15M RUs | Pay per use | 100 req/s | n/a | Email support |
| Builder | $49/mo | 30M RUs | None | n/a | Email support |
| ProPopular | $199/mo | 150M RUs | None | n/a | Priority support |
| Business | $699/mo | 500M RUs | None | On request | Dedicated support |
| Enterprise | $1,499/mo | 1B RUs | None | On request | SLA & dedicated support |
| Custom | Contact sales | Custom | None | On request | SLA & dedicated support |
Monthly plans are flat and fixed; on-demand usage (with or without a plan) is $25 per 15M request units, capped by a spending limit you set. Plans accept card or crypto; on-demand usage without a plan is card only and has the same methods as Builder (how it works). Archive depth and trace/debug support are per chain (see Supported Networks), not per plan; "unbounded debug methods" are debug_accountRange, debug_storageRangeAt and debug_dumpBlock. See full pricing →
On-demand usage: how it works
Pay only for what you use, with no plan and no monthly fee. Add a card in the dashboard (Billing) and your key keeps working, whether you are on the free trial, your trial has ended, or you never had a plan.
- Price. $25 per 15M request units, charged per started block. Request units are the same as on every plan (see Method Weighting). Unused units from your free trial are used first.
- Spending limit. You set a monthly limit in steps of $25, and it pays for whole blocks: $50 covers 2 blocks (30M request units). On-demand usage is served until those are used, then stops. New accounts start at $50. Change it any time under Billing.
- Alerts. We email you at 80, 90 and 100% of what your limit covers, once per threshold each billing period.
- Your first invoice. Until your first invoice with a charge is paid, the limit can be at most $100 (60M request units). This lifts automatically once that invoice is paid. Need more sooner? Contact support and we can raise it.
- Rate limit. On-demand usage on its own is limited to 100 requests per second (burst 200). Monthly plans have no rate limit.
- Methods. The same methods as the Builder plan.
- When the limit is reached. Requests get HTTP 429 with the body "Too Many Requests: your on-demand spending limit is reached. Raise it in the dashboard to continue on the same key". Raise the limit and the same key works again within seconds; nothing in your integration changes.
- Billing. Usage is invoiced to your card once a month. Invoices and payment methods are in the dashboard under Billing, Manage billing.
- Moving to a plan. Choose a plan any time: you get a monthly allowance and no rate limit, on the same key and the same card.
- Stopping. Turn on-demand usage off under Billing to stop new charges right away (your key stops serving), or cancel the subscription: it stays on until the end of the period, and usage up to then is invoiced as usual.
Support
© 2026 BoltRPC, operated by Matrixed.Link. ISO/IEC 27001:2022 certified.