# How to choose an RPC provider

> Original page: https://docs.blockvectra.com/en/guides/choose-rpc-provider/

Choose an RPC provider by the cost and reliability of completing your actual task: first verify chains, methods and historical coverage, then measure query count, throughput and recovery.

Write down the chains, methods, fixed blocks, daily traffic distribution, peak concurrency and notification or dataset dependencies your application or AI Agent needs. The public BlockVectra values below come from [GET /v1/plans](https://console-api.blockvectra.com/v1/plans) and [GET /v1/chains](https://api.blockvectra.com/v1/chains); fetch them again before making a decision. Data coverage comes from [GET /v1/status](https://api.blockvectra.com/v1/status). A declaration is a starting point for a test, not a latency measurement or an SLA.

## Method prices and billing units

A request count alone does not price a workload. Record each method's billing weight, conversion into USD, included credits, overage and any subscription or add-on fee. Credits, CU and request units need their own conversion before comparing providers.

BlockVectra's current method weights and list prices are read from the public plans endpoint when the page is built:

**Active Conversion Parameters**

1 USD = 10,000 billing units, 1 billing unit = 1,000 CU (1 USD = 10,000,000 CU).

**Formula**: CU weight × 1,000,000 ÷ (10,000 × 1,000) USD.

| Method | CU per call | Price per 1M calls (USD) |
| --- | --- | --- |
| `eth_blockNumber` | 1 | $0.10 |
| `eth_call` | 15 | $1.50 |
| `eth_getLogs` | 30 | $3.00 |
| `debug_traceTransaction` | 100 | $10.00 |
| `data.block` | 5 | $0.50 |

```text
workload_cu = sum(calls_for_method × current_method_cu_weight)
cu_per_usd = pricing.units_per_usd × pricing.cu_per_unit
list_cost_usd = workload_cu / cu_per_usd
paid_compute_usd = max(0, workload_cu − available_free_cu) / cu_per_usd
```

List prices exclude free credits, gas, add-ons and migration work. Distinguish a recurring allowance from an expiring trial, and an extra-credit price from the average cost of included requests. Check the [billing rules](https://docs.blockvectra.com/en/guides/billing-rules/) for which responses consume CU.

**Self-test:** replay a small, representative method mix with fixed blocks and record successful calls, retries and billable errors. Compare the account's usage change with the method-weight calculation. Budget for the number of requests that returned the complete result, including pagination and backfills. See [Reading CU pricing](https://docs.blockvectra.com/en/guides/reading-cu-pricing/) for the conversion.

## Log ranges and historical state

For `eth_getLogs`, check block span, result-size limits and filter support for the specific chain and plan. A wide span is useful only if the response is complete. BlockVectra's authenticated spans come from the chain catalog:

| Chain | Chain slug | max_logs_block_range (blocks) |
| --- | --- | --- |
| Arbitrum One | `arb_mainnet` | 1,000 |
| Base | `base_mainnet` | 1,000 |
| BNB Smart Chain | `bsc_mainnet` | 1,000 |
| Ethereum | `eth_mainnet` | 1,000 |
| Ethereum Sepolia | `eth_sepolia` | 1,000 |
| HyperEVM | `hyperevm_mainnet` | 1,000 |
| Polygon | `polygon_mainnet` | 1,000 |
| Robinhood Chain | `robinhood_mainnet` | 1,000 |
| Robinhood Chain Testnet | `robinhood_testnet` | 1,000 |

Historical logs and historical contract execution are different capabilities. For `eth_call`, read `state_window_blocks`; for keyless reads, also read `public.history_blocks`. A missing or null field is unspecified, not proof of unlimited history. See [historical EVM state](https://docs.blockvectra.com/en/guides/evm-historical-state/).

**Self-test:** choose a fixed interval with a known contract and topics, split it at the declared range, and compare the union of results with smaller overlapping queries. Deduplicate by block hash, transaction hash and log index, and check interval boundaries. Separately read the same contract at a recent fixed block and at the oldest block your application requires; record the actual result or JSON-RPC error. Test dense and sparse intervals and count retries. Follow [log range and recovery](https://docs.blockvectra.com/en/guides/getlogs-block-range/) to checkpoint progress.

## Free credits, rate limits and peak traffic

BlockVectra's current cycle budget and the calls it can cover are calculated from plans:

The Free Plan requires registering an account and using an API key; all keys under an account share an average of 25 calls per second (short bursts allowed). At the end of each 30-day cycle, balances below 30,000,000 CU are refilled to 30,000,000 CU.

| Method | CU Weight | Approx Calls / Cycle | Approx / Day | List Price / 1M Calls |
| --- | --- | --- | --- | --- |
| `eth_blockNumber` | 1 | 30,000,000 | 1,000,000 | $0.10 |
| `eth_getBlockByNumber` | 5 | 6,000,000 | 200,000 | $0.50 |
| `eth_getBalance` | 10 | 3,000,000 | 100,000 | $1.00 |
| `eth_call` | 15 | 2,000,000 | 66,666 | $1.50 |
| `eth_getLogs` | 30 | 1,000,000 | 33,333 | $3.00 |
| `debug_traceTransaction` | 100 | 300,000 | 10,000 | $10.00 |
| `data.block` | 5 | 6,000,000 | 200,000 | $0.50 |
| `data.address_balances` | 25 | 1,200,000 | 40,000 | $2.50 |
| `data.dex_prices` | 15 | 2,000,000 | 66,666 | $1.50 |
| `data.transaction_trace` | 200 | 150,000 | 5,000 | $20.00 |

Free-account call cap: up to 25 calls per second, shared across all keys in the account, all chains, and the Data API. Each key also has `cu_per_sec` and `burst_cu` limits. An eligible cycle refill tops the free balance up to its target; it is not an extra full grant. The first paid top-up stops cycle refills while preserving remaining free CU. See [free plan rules](https://docs.blockvectra.com/en/guides/free-plan/).

Keep daily quotas, cycle balances, requests/s, CU/s, burst capacity and concurrent requests separate. Paying for more usage does not by itself establish more per-key throughput.

**Self-test:** use an authenticated key and a small bounded batch at the pacing and concurrency your task needs, within the account's limits. Record HTTP status, JSON-RPC error, latency percentiles and completed calls. Stop at quota exhaustion; use bounded backoff on throttling and persist progress. Repeat with a mixed-method sample because costly methods consume more of a CU/s budget. Compare a burst with steady traffic, and include other keys' usage when checking the shared account cap.

## Chain, method and protocol coverage

Use the [chain catalog](https://api.blockvectra.com/v1/chains) to check network identity, `jsonrpc`, `methods.allow`, `methods.deny`, `public.methods`, `ws` and `subscriptions`. A chain name does not establish that every method or protocol is available. Keyless methods and authenticated methods can have different limits.

**Self-test:** copy the chosen network's `public.url` and call a method in `public.methods`. For the Ethereum example below, inspect the network ID, then run the application’s required methods with an authenticated key and the same fixed blocks. Check deny rules as well as allow rules; compare block hashes when comparing results across endpoints.

```bash
curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet/public \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: curl BlockVectraQA/1' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
```

This checks a public method, not archive coverage or authenticated capacity. If your application needs sockets, test the required subscription, disconnect and resume path on a network that declares `ws` support. See [WebSocket subscriptions](https://docs.blockvectra.com/en/guides/websocket-subscriptions/).

## Push delivery and indexed data

For address notifications, inspect the chain's `push` declaration and its confirmation settings. BlockVectra can watch the same address set across supported chains in one subscription with one HTTPS receiver; check [self-service and enterprise capacity](https://docs.blockvectra.com/en/guides/webhook-push/#address-capacity) against your address count. For Data API queries, inspect the datasets and indexed range in [GET /v1/status](https://api.blockvectra.com/v1/status). Indexed records do not imply arbitrary historical contract execution. RPC polling, WebSocket messages, delivered Push events and watched address-days use different billing meters; calculate each needed workflow from the applicable weights in [plans](https://console-api.blockvectra.com/v1/plans).

**Self-test:** for Push, use an HTTPS receiver you control, verify signatures and test duplicate handling, retries and replay using an event from an address you control. For Data API, query a known indexed transaction or transfer, compare its block hash with RPC, exhaust pagination, and save the cursor before resuming. Record coverage gaps and the number of billed events or calls. Use [Webhook Push](https://docs.blockvectra.com/en/guides/webhook-push/), [Webhook versus WebSocket](https://docs.blockvectra.com/en/guides/webhook-vs-websocket/) and the [Data API reference](https://docs.blockvectra.com/en/api/data/) for the appropriate recovery path.

## Authentication and Agent access

Check whether your client can securely supply a key, discover machine-readable documentation, create an account and recover from errors. BlockVectra RPC accepts a path key at `POST /v1/{chain}/{api_key}` or an `x-api-key` header at `POST /v1/{chain}`. Data API uses `x-api-key`. Keep keys in server environments and out of browser bundles, logs and chat messages.

Developers and AI Agents use the same pricing and limits. [Programmatic sign-up](https://docs.blockvectra.com/en/guides/programmatic-signup/) documents wallet-based account creation, and the [Agent guide](https://docs.blockvectra.com/en/guides/ai-agents/) provides documentation and MCP entry points. Agents can fund the account usage balance with stablecoins through the [documented top-up flow](https://docs.blockvectra.com/en/guides/agent-topup/), without a monthly RPC subscription. Top-up networks, tokens and minimums come from [GET /v1/topup/status](https://api.blockvectra.com/v1/topup/status).

**Self-test:** have the intended client discover the chain and method, read the documentation, load a key from its environment and execute one bounded authenticated request. Inspect both HTTP status and JSON-RPC `error`. Check a missing-key response without logging credentials. Verify that the client saves progress on insufficient balance, reads the enabled top-up network and token, and follows the documented top-up flow; account creation and payment steps should use accounts you control. Do not treat a documentation MCP connection as proof that the Agent can execute an authenticated RPC call.

## Record the decision

Keep a short result sheet: source and sampling date; chain and method; fixed block hash; result completeness; total calls and retries; available quota; paid task cost; latency and throttling; history and protocol gaps; recovery steps; migration effort. If the workload requires contractual support or an SLA, obtain the applicable terms separately from these API tests.

Once your workload is defined, compare with specific providers:

* [Compare with specific providers: compute pricing and log ranges](https://docs.blockvectra.com/en/guides/alchemy-alternative/).
* [Compare with specific providers: trial and subscription billing](https://docs.blockvectra.com/en/guides/quicknode-alternative/).
* [Compare with specific providers: HTTPS request costs](https://docs.blockvectra.com/en/guides/ankr-alternative/).
* [Compare with specific providers: daily and cycle budgets](https://docs.blockvectra.com/en/guides/infura-alternative/).
* [Compare with specific providers: included requests and overage](https://docs.blockvectra.com/en/guides/chainstack-alternative/).