Pricing

You pay providers directly for the requests they serve. Each provider sets its own price, and your client weighs it when choosing where to send each request.

Set your price limit and preference

Set a maximum request price, then choose whether to favor lower latency, lower price, or a balance of both. The gateway uses that preference to rank providers within your limit. For example, you can allow up to 3 USDC per million requests and prioritize the fastest provider below that ceiling.

For a local gateway, open Marketplace, select the blockchain, and open Provider selection. For a managed gateway, open it on the website and select Provider selection for its network. Settings apply to that gateway and network.

For example, with a ceiling of 3 USDC per million requests and a latency preference, a faster provider at 2.8 USDC per million can be preferred over a slower one at 2 USDC per million. A provider at 4 USDC per million is excluded regardless of its speed.

Maximum request price

Enter the ceiling in USDC per million requests. A limit of 3 USDC per million allows a provider price of up to 0.000003 USDC per request. If no eligible provider meets your limit, the gateway returns NO_PROVIDER_WITHIN_PRICE_LIMIT rather than choosing a more expensive one. A lower ceiling can reduce availability even while more expensive providers remain reachable. The gateway does not raise it automatically. You can wait for availability to change or raise the ceiling; see Provider and price errors for application handling.

The ceiling limits each provider's unit price, not the total cost of a batch or a response checked across several providers. It also excludes managed hosting fees.

Price and latency preference

Preference	Suitable workloads
Lower latency	Interactive applications and tools that need prompt responses
Lower cost	Background jobs and backfills that can tolerate slower responses
A balance of both	Workloads where both request cost and response time matter

Your application keeps sending the same RPC calls whichever preference you choose. To assess the effect, compare response times and provider headers for the methods you actually use: historical queries, traces, and lightweight reads can perform differently.

Changes apply to subsequent provider selections; they do not move existing subscriptions to another provider. Routing requests and handling failures explains how the gateway maintains eligible alternatives.

What counts as a request

Usage	Billable requests
One JSON-RPC call	One
An HTTP batch containing ten calls	Ten
A subscription	The subscribe call and each notification received
A quorum check across three providers	One for each provider asked

Direct RPC uses a flat price per request from a given provider, rather than compute units for different methods. A wide eth_getLogs query and an eth_blockNumber call therefore have the same request price, within Direct's published capabilities and limits.

Batching reduces HTTP round trips, but does not reduce the billable call count. To reduce costs, avoid unnecessary polling and unsubscribe from streams you no longer need.

To add funds, follow Managing payments and spending.

Estimate your costs

The examples below use an illustrative provider price of 0.000002 USDC per request, or 2 USDC per million. Check the selected providers for the prices that apply to your requests.

Workload	Approximate usage	Cost at the example price
Read a balance once a minute	43,000 requests per month	0.09 USDC
Serve 50 requests per second	130 million requests per month	260 USDC
Backfill 1 million blocks, 1,000 blocks per log query	1,000 requests	0.002 USDC
Subscribe to Ethereum block headers	216,000 notifications per month	0.43 USDC, plus the subscribe call

Actual costs depend on the selected providers, retries, verified responses, and your workload. Backfills spanning more than 10,000 blocks require multiple Direct requests. Splitting within a provider to accommodate its upstream node does not add billable requests. Managed access also adds the hosting fee shown when you configure the gateway.

Failed requests and retries

• Node errors are billable. A provider may perform work and return a JSON-RPC error such as execution reverted.
• Unserved requests are not billable. A failure to find a compatible provider does not create a request charge.
• Automatic recovery is billed once. A request retried after a provider failure is paid to the provider that answers. Explicit quorum checks are separate work and incur a charge for each provider asked.

See Errors to distinguish node errors from connection and payment failures.