7 Best Ethereum RPC Providers in 2026: Pricing & Features Compared

What should an Ethereum RPC provider support?

Ethereum's execution JSON-RPC API covers reads and transaction submission. Common application calls include eth_getBalance, eth_call, eth_getLogs, and eth_sendRawTransaction. Several state methods accept a block parameter, including latest, safe, finalized, or a specific block number. Consensus-client APIs are a separate interface. Source: Ethereum JSON-RPC documentation.

Use those distinctions to write a short requirements list. For a current-state wallet, begin with the calls made during one screen refresh. For an analytics service, specify the oldest state you must reproduce and the log ranges you need to scan. For a transaction backend, include preparation, submission, and receipt reconciliation as separate steps.

Ask about historical state and trace methods separately. Retrieving an old transaction is a different requirement from executing a contract call against old state. Debug or trace output also depends on the supported method, tracer, client, and access tier. Test a known query rather than accepting an archive checkbox as a complete answer.

Finally, separate authenticated shared access from a dedicated node. An API key gives your application an access and billing identity; it does not establish resource isolation. Choose a dedicated deployment when a measured requirement, such as sustained backfills or custom configuration, justifies the additional operating cost.

Ethereum RPC providers: pricing and features at a glance

Public pricing was checked on October 19, 2026. Prices are USD, using monthly billing where a subscription price is shown; introductory and annual discounts are excluded. RU, CU, and API credits are provider-specific billing units, not interchangeable request counts. Confirm the current plan and method access before purchasing.

Coverage sources: OnFinality Ethereum, Chainstack Ethereum, Alchemy Ethereum, QuickNode Ethereum, and Ankr Ethereum. Infura and GetBlock plan details are linked in their rows.

Treat this as a shortlist, not a performance league table. The numbering reflects editorial order, with OnFinality listed first as the publisher's service. This article does not claim a measured latency winner or a universal reliability ranking. The provider profiles below explain where each option is worth evaluating.

1. OnFinality — managed Ethereum RPC with an upgrade path

Best fit to evaluate: teams needing managed Ethereum access, historical reads, and the option to move to dedicated infrastructure.

OnFinality documents Ethereum mainnet over HTTPS and WebSocket, archive access, and paid Trace / Debug. Its public endpoint is limited to 5 RPS, and the listed regions are Hong Kong and Northern Virginia. Source: Ethereum network details.

Growth lists 200 RU/second and $6 per million RU overage. The free Developer tier allows up to 40 RU/second. RU reflects request complexity and response size, so neither figure should be rewritten as guaranteed raw requests per second. Dedicated-node charges are separate. Source: RPC pricing.

The reason to shortlist OnFinality is the operating path from shared RPC to a separately provisioned node. Start by replaying your application's ordinary reads and the most demanding historical or trace query you expect to use. Inspect usage after each test to understand the resulting bill.

Tradeoff: select the paid tier if Trace / Debug is required, and verify the exact method and historical range. A successful public health check does not validate the capacity of an authenticated plan. If the application needs a special tracer or configuration, establish support before treating it as part of the shared service.

2. Chainstack — shared, archive, and isolated Ethereum deployments

Best fit to evaluate: teams comparing a shared service with dedicated resources or an RPS-tier product.

Chainstack offers Global and Dedicated Ethereum nodes, with archive and Debug / Trace options. Its Ethereum page distinguishes full-node requests at 1 RU from archive requests at 2 RU. Source: Chainstack Ethereum.

Growth lists 250 RPS and $15 per million extra RU. The Unlimited Node add-on starts at $149/month and requires Growth or higher; its selected RPS tier still limits throughput. Dedicated nodes are available from Pro, with infrastructure charges to consider separately. Source: Chainstack pricing.

This makes Chainstack worth evaluating when the purchasing decision includes how traffic is provisioned, rather than only the monthly allowance. Compare the ordinary metered plan with the relevant RPS tier using your steady and burst traffic separately.

Tradeoff: an unmetered-request product does not mean unlimited concurrent work or throughput. Confirm eligible methods and archive configuration for that product. For historical workloads, include the published archive weighting in your model instead of assuming every call consumes one RU. Keep subscription, add-on, and dedicated-resource costs distinct in the comparison.

3. Alchemy — Ethereum RPC alongside application APIs

Best fit to evaluate: applications that may benefit from higher-level data APIs as well as node access.

Alchemy publishes an Ethereum API quickstart and a platform covering Node API, smart WebSockets, token, NFT, transfers, and other application APIs. Its pricing page lists 300 CU/second on Free and 10,000 CU/second included on PAYG; additional peak capacity is priced separately. Sources: Ethereum quickstart, Alchemy pricing.

The practical question is whether a supported higher-level API can replace data processing you would otherwise maintain. If it can, compare the total application workflow rather than one raw JSON-RPC call. Keep the distinction visible in your architecture so you know which parts would need replacement during a provider migration.

Tradeoff: CU allowances are method-weighted, and peak-capacity requirements can add another cost. Budget the specific methods your application uses. Check plan eligibility for Debug / Trace and the required eth_getLogs range instead of assuming all platform features are included in every tier. Provider-specific APIs are useful only if their data coverage and freshness meet your requirements.

4. QuickNode — Ethereum RPC with optional data-delivery products

Best fit to evaluate: teams assessing RPC together with streams, webhooks, or endpoint add-ons.

QuickNode documents Ethereum mainnet, Sepolia, and Hoodi with HTTP, WSS, and archive data. Its Ethereum reference includes Trace and Debug catalogs and links to separate Streams, Webhooks, and add-on products. Build lists 50 RPS; the trial is one month with ten million credits and 15 RPS. Sources: Ethereum RPC reference, QuickNode pricing.

This is a useful candidate when the same application needs interactive reads and a data pipeline. Evaluate whether your workload is better served by repeated RPC queries, a subscription, or a separate delivery product. Price each proposed design using the service that would actually handle it.

Tradeoff: an 80 million credit allowance is not an 80 million request allowance. Confirm method weights, trace access, and any additional product charge. Test the paid plan you intend to use rather than interpreting a trial's RPS limit as production capacity. A data-delivery feature should also be checked for replay and recovery behavior before it replaces your own polling process.

5. Infura — daily credit plans with an explicit trace tier

Best fit to evaluate: teams comfortable budgeting around daily usage limits and method credits.

Infura lists full archive data on Core and adds Debug / Trace on Developer. Core provides 500 credits/second, while Developer lists 4,000. Its documentation states that WebSocket notifications consume credits and connections are severed when the daily limit is reached. Sources: Infura pricing, credit pricing documentation.

The daily model is a useful reminder to test your busiest day separately from an average month. Estimate both the regular workload and recovery after downtime: catching up missed events can create a second spike after the original incident has ended.

Tradeoff: dividing a daily credit allowance by a month of average traffic can hide the limit you are most likely to hit. Convert the application's actual method mix into credits and check both the daily budget and instantaneous capacity. Include WebSocket notifications in that calculation. If transaction investigations require tracing, confirm the paid tier and method rather than treating archive access as equivalent to tracing access.

6. Ankr — usage-based Ethereum HTTPS pricing

Best fit to evaluate: workloads that benefit from paying for consumed API usage rather than selecting a fixed monthly allowance.

Ankr documents an Ethereum API with standard and trace/debug method references. Its published PAYG EVM HTTPS rate is 200 API credits per request at $0.10 per million credits, equivalent to $20 per million listed calls. WSS subscriptions and notifications have separate billing rules. Sources: Ankr Ethereum, Ankr pricing.

A usage model can be attractive when traffic is intermittent, but evaluate it with a full month of expected activity and a peak-day scenario. Include workers, internal tools, retries, and data recovery, not only user-triggered calls.

Tradeoff: a clear HTTPS rate does not establish a throughput guarantee or complete historical method support. Confirm the premium service's capacity, required network, and method eligibility. Do not apply the Ethereum HTTPS rate to Beacon APIs, advanced APIs, or WebSocket delivery. Keep each traffic category separate so the total estimate reflects the services the application will actually consume.

7. GetBlock — configurable shared access and dedicated nodes

Best fit to evaluate: teams comparing compute-unit shared plans with a dedicated Ethereum deployment.

GetBlock documents Ethereum mainnet and testnet access, WebSockets, shared CU-based plans, and dedicated nodes. Its Ethereum page advertises dedicated infrastructure from $1,000/month. The shared pricing widget varies by allowance and billing period; we do not present its selected annual Pro example as the cheapest monthly plan. Source: GetBlock Ethereum.

For a shared deployment, choose the intended monthly allowance in the configurator and retain the quote alongside your workload assumptions. For a dedicated deployment, request the node type and history configuration you need before comparing that price with shared access.

Tradeoff: the shared plan lists archive access on selected networks, so verify Ethereum-specific coverage for the chosen plan and methods. Confirm CU weights for large log queries, supported trace methods, and resource limits. A dedicated-node price is a separate infrastructure purchase; it should not be compared with a shared subscription without accounting for the workload each will serve.

How to compare Ethereum RPC costs without mixing billing units

Build a small request inventory from application logs or a representative staging run. For a wallet, capture a full account refresh. For a DeFi backend, capture the reads and simulations needed for one decision cycle. For an indexer, capture a fixed backfill range and the incremental work for new blocks. Label the result as your workload sample rather than a universal Ethereum traffic mix.

Then use each provider's published method weights or usage dashboard to price that same sample. Keep current-state queries, historical-state queries, traces, subscriptions, and proprietary APIs in separate rows. Add overage charges and products that are billed outside the base plan. A large credit allowance becomes meaningful only after this conversion.

For example, a two-million-call historical job is not necessarily two million units. Under Chainstack's documented two-RU archive weighting, that hypothetical job would consume four million RU if every call uses that archive category. This is an illustration of billing arithmetic, not a measurement of the job's performance or a claim about another provider's weights.

Include peak load and recovery as well as monthly volume. A low average bill is of little use if the application cannot finish its busiest minute. Conversely, buying a high-throughput plan for one occasional backfill may be less appropriate than scheduling the work differently. Evaluate that tradeoff against the application's deadlines and available operating effort.

Choose an Ethereum provider for your workload

For wallets and user-facing dApps, begin with successful account refreshes and transaction status updates under realistic concurrency. Measure the complete interaction, including calls made after the first response. Set retry budgets so a brief error does not multiply traffic across every open session.

For DeFi backends, test the exact contract calls, block references, and response sizes used in your workflow. Keep submission acceptance, receipt availability, and finality handling separate in the test report. An RPC response time alone does not establish transaction inclusion time or execution outcome.

For indexers and analytics, test bounded log ranges and a known older state query. Save expected results for a small set of blocks so the test checks completeness and decoding as well as HTTP success. Use checkpoints in your own pipeline, and verify how a provider switch affects replay and duplicate handling.

For debugging and transaction analysis, bring a real sample transaction and your required trace method or tracer. Check output shape, timeout behavior, historical coverage, and price on the intended tier. Keep a separate acceptance check for any custom tracer; a platform-level Debug API label is insufficient evidence for every configuration.

For large or sensitive deployments, compare isolated resources with shared plans after measuring the bottleneck. Request the applicable service terms, supported regions, escalation path, and configuration limits. Base a dedicated-node decision on those requirements rather than assuming that isolation automatically improves every query.

A practical Ethereum RPC evaluation checklist

Choose two or three candidates and run the same read-only workload from your backend's deployment region. Keep connection reuse, concurrency, request parameters, and time windows consistent. Record median and p95 latency, errors, data freshness, and usage charged. Pin historical comparisons to the same block to avoid comparing different chain states.

Test several traffic shapes: a quiet period, the expected peak, and recovery after an interrupted worker. Stay within each plan's documented limits. Separate rejected calls from slow successful calls, and count retries in both the reliability and billing reports. A successful lightweight block-number query should not stand in for a full application benchmark.

Evaluate fallback compatibility before you need it. Verify that the second provider supports the same methods, history, response shapes, and subscription behavior. Test how the application resumes from its last checkpoint and how it reconciles a transaction whose submission timed out. Switching providers should not silently reset the application's view of completed work.

This guide's recommendations are based on documented fit, not results from those tests. Record your own acceptance thresholds, run the evaluation, and choose the plan that passes them at a total cost you understand. Review the results when your method mix or traffic changes, rather than assuming the original shortlist remains optimal forever.

Which Ethereum RPC provider should you shortlist?

Start with OnFinality when managed Ethereum RPC, archive access, and a dedicated-node upgrade path match your requirements. Put Chainstack alongside it when comparing shared, archive, and isolated deployment choices. Consider Alchemy and QuickNode when their additional application APIs or data-delivery products could simplify your architecture. Evaluate Infura for daily credit plans, Ankr for usage-based HTTPS access, and GetBlock for configurable shared or dedicated services.

Choose the provider that passes your method, history, peak-load, and recovery tests. To evaluate OnFinality, review Ethereum network details and RPC pricing. If you already have a candidate, explore OnFinality vs Chainstack, Alchemy, QuickNode, or Infura. For other networks, return to the RPC comparison hub.

Frequently asked questions