RPC Pricing Explained: Compute Units, Credits and Real Request Costs

How to compare RPC pricing correctly

RPC infrastructure pricing looks deceptively easy.

A provider shows a monthly fee.

Another shows a free allowance.

A third says that millions or billions of units are included.

The natural reaction is to divide the price by the headline usage number and compare the result.

That calculation can be badly wrong.

Consider one Ethereum application that performs ten million actual JSON-RPC calls per month.

If every call is a lightweight latest-state read, its billing footprint can be very different from another application making ten million historical state calls, traces or large log queries.

The raw call count is identical.

The provider-side work is not.

This is why infrastructure companies use different accounting systems.

NOWNodes currently publishes monthly request allowances directly.

Chainstack uses Request Units, or RU.

QuickNode uses API Credits.

Alchemy uses Compute Units, or CU.

Other providers use credits, weighted requests, response bytes, throughput, data volume or combinations of these.

No one pricing model is automatically superior.

A flat request model is easy to understand.

A weighted model can charge more accurately for computationally expensive methods.

A fixed-capacity endpoint can be attractive when traffic is predictable and enormous.

A dedicated node can be more rational than any request meter once sustained load becomes high enough.

The job is to identify which economics match the application.

If you first need to understand why historical state requires different infrastructure, TokenToolHub's archive nodes guide explains the difference between retaining chain history and serving current state.

For broader vendor selection across several chains, use the multi-chain node hosting comparison after you have converted the workload into something each provider can price consistently.

What requests, credits and compute units actually mean

Raw request pricing

The simplest unit is one request.

Your application sends an RPC call.

The provider counts one request against the monthly quota.

NOWNodes currently uses this model for its shared plan allowances.

The current public ladder includes 100,000 requests on Start, one million on Pro, ten million on Pro Plus, thirty million on Business, fifty million on Business Plus and one hundred million on Enterprise.

This is intuitive because developers can often read API gateway metrics and estimate their plan directly.

The remaining work is checking whether archive, trace, WebSocket or protocol-specific interfaces are available under the same service.

Request Units

Chainstack calls its usage unit an RU.

The current model charges one RU for a Regional Node request and one RU for a Global Node request.

An Archive Node request costs two RUs.

This creates a hybrid model.

Ordinary method complexity does not create a separate multiplier on normal node requests.

Historical archive access does.

Ten million standard calls therefore consume ten million RU.

Ten million archive calls consume twenty million RU.

API Credits

QuickNode uses API Credits.

The current credit schedule depends first on the network and API class.

Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Smart Chain and many other EVM networks currently use a twenty-credit base multiplier for standard methods.

This means one ordinary Ethereum RPC call consumes twenty API Credits.

Ten million ordinary Ethereum requests therefore represent two hundred million API Credits before any advanced-method multiplier is applied.

QuickNode currently assigns Advanced APIs, including Trace and Debug, a multiplier equal to twice the chain multiplier.

On Ethereum, that makes an advanced operation forty API Credits under the published schedule.

Designated large calls can use a four-times chain multiplier.

The exact chain matters because QuickNode currently publishes different base multipliers for different networks.

Compute Units

Alchemy's Compute Units work differently.

The method itself has an assigned compute weight.

Current documentation gives lightweight eth_blockNumber as a 10-CU example.

eth_call is currently listed at 26 CUs.

eth_getLogs currently uses 60 CUs in the Ethereum endpoint documentation.

Alchemy's current debug_traceTransaction pricing is significantly heavier at 170 CUs.

The goal is to approximate the resource burden of the method rather than treating every RPC request equally.

This can favor workloads dominated by cheap requests.

It also means that forecasting requires knowing what the application actually calls.

How the same RPC workload becomes different bills

Translate an actual method mix into billed units

Assume an Ethereum application records ten million intended JSON-RPC calls during one month.

The method distribution is not uniform.

Four million requests are eth_blockNumber or similarly lightweight chain-head reads.

Two million are eth_call.

One million are eth_getTransactionReceipt.

One million are eth_getLogs.

One million are ordinary balance and nonce reads.

Five hundred thousand request historical state.

The remaining five hundred thousand are execution traces used by a security or analytics pipeline.

This workload already contains much more information than "10 million monthly requests."

Under a flat raw-request model, the starting point is approximately ten million calls.

Under Chainstack's current request-unit model, standard Global Node calls use one RU.

Archive and advanced trace workloads should be routed and priced according to the applicable node mode.

Chainstack currently documents standard calls at 1 RU and archive, debug and trace infrastructure at 2 RU in its current cost guidance.

If nine million calls remain standard and one million are archive or advanced calls billed at the two-unit rate, the workload becomes approximately eleven million RU before retries.

Under QuickNode's current Ethereum API Credit schedule, ordinary Ethereum calls use twenty API Credits.

Advanced Trace and Debug APIs use twice the chain multiplier, making them forty credits per request for Ethereum under the current published schedule.

Nine and a half million ordinary calls would therefore consume approximately 190 million API Credits.

Five hundred thousand advanced calls at forty credits contribute another twenty million.

The result is approximately 210 million API Credits before retries and other services.

Alchemy requires a more granular method calculation because the CU amount changes by method.

Four million eth_blockNumber calls at ten CUs contribute forty million CUs by themselves.

Two million eth_call requests at twenty-six CUs contribute fifty-two million CUs.

One million eth_getLogs requests at the currently documented sixty CUs contribute another sixty million CUs.

Trace operations are materially heavier again.

The purpose of this example is not to produce a universal winner.

It demonstrates why raw requests are an insufficient comparison unit.

Retries quietly increase real RPC cost

Applications rarely execute exactly one provider request for every business action.

Networks fail.

Gateways return 429 responses.

Connections reset.

Load balancers time out.

Nodes can lag.

Clients retry.

If your usage model counts only successful business actions, the resulting cost forecast can be understated.

Assume a service intends to execute one hundred million RPC calls per month.

If two percent require one additional attempt, that creates roughly two million extra requests.

At a five-percent retry rate, five million additional attempts appear.

If the retry policy uses exponential backoff with up to three attempts, individual failures can produce even more traffic.

Not every failed request is billed identically

Providers differ in how failed, rejected or incomplete operations are counted.

Do not assume every HTTP 429 or transport failure consumes the same amount as a successful operation.

Review the provider's current usage telemetry and billing documentation.

The safe forecasting approach is still to track attempted provider calls separately from successful application operations.

That lets you reconcile the invoice against actual traffic later.

Retries can amplify an outage

Uncontrolled retry logic can transform a modest provider incident into a request storm.

If one thousand application workers retry immediately at the same time, the retry traffic can keep an already constrained service under pressure.

Use exponential backoff.

Add jitter.

Cap attempts.

Differentiate idempotent reads from transaction submissions.

For signed transactions, query the known transaction hash before creating a replacement economic action.

Why log queries can distort an RPC budget

eth_getLogs is one of the most important methods to isolate in a pricing model.

A wallet might use it to identify token transfers.

An analytics service can use it to index protocol activity.

A security monitor may scan events continuously.

One request can cover a small recent range or a large historical interval.

Providers can impose response-size and block-range limitations even when the method's nominal billing weight appears simple.

Alchemy currently prices eth_getLogs at sixty CUs on its Ethereum endpoint documentation.

Chainstack currently treats a normal full-node request as one RU regardless of ordinary JSON-RPC method.

QuickNode currently uses its standard twenty-credit Ethereum chain multiplier for standard methods unless the call falls into one of its documented advanced or large-call categories.

The practical cost still depends on how many calls are needed to retrieve the full range.

Block-range restrictions change request count

Suppose your application wants one million blocks of historical logs.

If the provider allows the full range in one reliable request, the raw request count can be small.

If the endpoint requires the range to be divided into ten-thousand-block windows, one logical historical scan becomes one hundred RPC calls.

If retry logic splits failed windows further, it can become more.

This is why method restrictions belong in pricing analysis.

A low unit cost is less attractive if your application must generate far more units to retrieve the same dataset.

Archive requests need their own budget

An archive node stores historical state that ordinary pruned nodes may no longer maintain.

Applications need this when they ask questions such as:

• What was this wallet's balance at block 15,000,000?
• What value occupied this contract storage slot at an old block?
• What would this contract view have returned against historical state?
• Can I reconstruct a protocol position at a previous chain height?
• Can I execute a historical trace requiring state from that period?

These operations impose materially different storage and database requirements from serving the latest state.

That is why archive access can be priced differently.

Chainstack currently assigns Archive Node requests two RUs.

NOWNodes exposes archive mode on supported chains and should be evaluated using the exact network and historical method required.

QuickNode includes archive capability across relevant chain products, with usage translated into the provider's API Credit system.

Alchemy currently includes archival data in its Free, Pay As You Go and Enterprise plan structures for supported networks, with the RPC operation consuming the corresponding method CUs.

If archive data is central to your product, compare the provider as an archive service rather than averaging those calls into a normal RPC total.

TokenToolHub's archive nodes explainer covers the infrastructure distinction in more detail.

WebSockets create costs that monthly HTTP request totals miss

A persistent WebSocket connection may appear inexpensive because it is not continuously sending HTTP requests.

The real workload includes subscription setup, event delivery, reconnect behavior and historical backfill when the connection is unavailable.

Provider billing models differ here.

Some plans include WebSocket connectivity as a feature.

Some data-streaming products are billed separately.

Some providers meter messages, credits, bandwidth or processed blocks for specialized streaming services.

Do not model WebSockets as zero cost merely because the plan says "WebSockets included."

Backfill is part of WebSocket economics

Imagine a service subscribing to Ethereum logs.

The socket drops for two minutes.

Several blocks are missed.

The correct recovery procedure reconnects and then uses historical RPC calls to backfill those blocks.

Those recovery requests enter the ordinary RPC bill.

If a service experiences many reconnects, its actual usage becomes:

QuickNode's separate Streams product illustrates why streaming can have its own billing model.

Its current Streams documentation calculates API Credits using network, dataset and blocks processed.

That is distinct from ordinary RPC request accounting.

A managed streaming product can still be economical if it replaces substantial custom indexing and recovery engineering.

Monthly allowance and throughput are two different limits

A provider plan can include more than enough monthly usage and still be unable to absorb your peak traffic.

Assume an application sends only five million calls per month.

That sounds small.

If two million of those calls arrive within a short token launch or airdrop window, peak throughput becomes the real constraint.

Chainstack currently publishes request-per-second limits alongside monthly RU allowances.

Its current Developer plan lists 25 RPS, Growth 250 RPS, Pro 400 RPS and Business 600 RPS.

Alchemy separates total compute usage from throughput capacity measured through CUs per second and requests per second.

Its current Pay As You Go plan includes published baseline capacity and prices additional throughput separately above that included amount.

QuickNode also exposes throughput and fixed-rate options depending on the product.

The purchasing decision therefore needs two dimensions:

Do not buy solely for the first number.

Editable RPC workload cost model

The calculator below is intentionally provider-neutral.

Enter your own monthly calls, billing weights and unit price.

For a flat request model, use a weight of 1.

For Chainstack standard requests, a current standard weight is 1 RU and Archive Node requests use 2 RU.

For QuickNode Ethereum standard RPC, the current base weight is 20 API Credits and Advanced APIs use a higher multiplier.

For Alchemy, use the CU amount of each actual method rather than one universal standard weight.

How major RPC billing models compare

NOWNodes: request-count pricing

Chainstack: flat normal RPC with archive weighting

QuickNode: chain-based API Credits

Alchemy: method-weighted Compute Units

A reproducible RPC pricing benchmark

A pricing comparison should not invent performance measurements merely to make a table look complete.

If latency and failure rates are included, record them under controlled conditions.

A useful baseline can use Ethereum Mainnet from a single cloud region.

For example, deploy one benchmark client in Frankfurt.

Keep HTTP keep-alive enabled.

Use eight concurrent requests.

Warm every endpoint with one hundred unrecorded requests.

Then record two thousand calls.

Use the same block identifiers and addresses for every provider.

Do not automatically retry requests during the raw measurement because retries hide first-attempt failure behavior.

The benchmark should also record the billing units consumed during the run.

That connects performance with price.

A fast endpoint that burns five times more paid units may still be the correct choice for a latency-sensitive trading system.

A slightly slower endpoint with predictable flat pricing may be better for a large analytics batch job.

Performance and cost should be reported separately before they are evaluated together.

Failure rate is part of RPC pricing

Provider errors cost engineering time and can generate more billable traffic.

A request that times out may be retried.

A log range that fails may be divided into smaller ranges.

A dropped WebSocket can trigger HTTP backfills.

A stale node can force the application to query a secondary provider.

Therefore, the cheapest theoretical unit rate can become less attractive if the application has to perform more requests to achieve the same successful business result.

If a controlled test has not been run, leave the latency and failure result unavailable.

A documented plan quota is evidence.

A made-up success rate is not.

When dedicated infrastructure changes the pricing discussion

At sufficiently high traffic, comparing credits becomes less useful.

The application may be better served by isolated compute.

A dedicated node shifts the economic model from every individual call toward infrastructure capacity.

You pay for CPU, memory, storage, region and operational service.

The application can then perform large volumes of internal RPC traffic against that node without thinking about every call as a separate metered unit, subject to the provider's commercial terms.

This is particularly relevant for indexers, explorers, security scanners and exchanges with constant high traffic.

It can also be justified at lower volume by privacy, regulatory or topology requirements.

Chainstack currently publishes Dedicated Node compute starting from an hourly price, with public-chain dedicated storage priced separately.

NOWNodes offers custom dedicated infrastructure with configuration-specific pricing.

QuickNode also offers dedicated infrastructure for higher-performance deployments.

Do not compare one provider's published starting price with another provider's unknown dedicated configuration.

Request equivalent specifications.

Use the same blockchain client.

Use the same archive requirement.

Use the same region.

Use the same redundancy expectation.

Then compare the quote.

TokenToolHub's dedicated versus shared RPC guide covers the operational break-even questions in detail.

Migration and exit cost belong in the pricing model

The cheapest provider today can become expensive if switching later requires a major rewrite.

Native JSON-RPC is portable.

A standard eth_getBalance request remains recognizable across providers.

The difficulty increases when the application depends on proprietary services.

Managed streams can use provider-specific filters.

Webhooks can use custom payloads.

Enhanced token APIs can expose different schemas.

Transaction simulations can return provider-specific metadata.

Historical data products can have different query interfaces.

Separate native RPC from convenience layers

Your infrastructure code should know which provider is active.

Your business logic should not need to know.

Create internal functions such as "get latest balance," "get historical storage," "get finalized receipt" and "get logs."

Behind that layer, route to the selected provider.

This makes future price changes easier to respond to.

Price migration as engineering work

If moving providers requires two engineers for two weeks, that labor is part of the effective infrastructure cost.

If the application can switch endpoints in an afternoon because it remains on standard RPC, its exit cost is much lower.

Use this as a purchasing factor before adopting a provider-specific API.

How to reduce RPC cost without degrading the product

Cache immutable data

A finalized historical block does not need to be fetched repeatedly from the provider.

Cache immutable chain data where your architecture allows it.

Historical transaction receipts, block headers and finalized contract metadata can often be reused safely.

Stop polling data that changes slowly

A frontend does not need to request every wallet balance several times per second.

Choose refresh intervals based on product need.

Where appropriate, use event-driven updates rather than constant polling.

Batch carefully

JSON-RPC batching can reduce transport overhead, but it does not automatically make underlying provider operations free.

Review how the provider counts batched methods.

A batch containing twenty RPC methods can still represent twenty billable operations depending on the provider.

Persist transaction state

If the application repeatedly calls eth_getTransactionReceipt forever for transactions already finalized, it wastes RPC budget.

Persist final outcomes.

Stop polling when your confirmation requirement has been met.

Use bounded log ranges

Large eth_getLogs requests can be expensive, slow or rejected.

Choose a block-window size that succeeds reliably and cache completed ranges.

Do not rescan months of history whenever the application restarts.

Route archive calls only where necessary

Do not send every request through an archive endpoint merely because archive access exists.

Latest-state traffic should use the appropriate standard endpoint when the provider architecture distinguishes the two.

Measure retries

If retry traffic exceeds a few percent consistently, investigate the source.

The issue may be rate limiting, an overly aggressive timeout, poor geographic routing or a provider mismatch.

Reducing unnecessary retries saves money and improves latency simultaneously.

Where TokenToolHub tools fit

Infrastructure pricing and transaction investigation are separate problems.

TokenToolHub's Transaction Decoder can investigate a sample transaction on supported EVM networks after the transaction has been retrieved.

It can help interpret calldata, token movements, approvals, nested calls and other execution evidence.

It should not be treated as an RPC benchmark.

A transaction decoding result cannot tell you the provider's p95 latency, monthly billing units or archive throughput.

Likewise, TokenToolHub's Token Safety Checker can investigate supported smart-contract risk signals.

That analysis belongs after the infrastructure layer has supplied reliable chain evidence.

Use each tool for the problem it is designed to answer.

Disqualifiers in an RPC pricing comparison

RPC pricing buyer checklist

Conclusion: the cheapest RPC provider is the one that costs less for your workload

A useful RPC pricing comparison does not begin with "which provider gives the most units?"

It begins with "what does my application actually do?"

That question sounds simple.

It forces the analysis onto the correct denominator.

Start with raw traffic.

Count every method.

Separate networks.

Separate standard reads from archive state.

Separate logs from traces.

Separate transaction submission from receipt polling.

Separate intended calls from retries.

Measure how many requests WebSocket recovery creates.

Record peak throughput.

Only then should you look at provider plans.

NOWNodes currently represents the easiest model to explain in raw request terms.

A shared plan contains a published number of monthly requests.

That simplicity is useful for applications whose method mix is broad but whose ordinary calls can be treated similarly from a quota perspective.

The diligence then shifts to interface availability.

Does the chain support the archive mode you need?

Does the paid tier provide WebSockets?

Are Trace and Debug methods available?

At what point should the workload move to dedicated infrastructure?

Chainstack takes a slightly different approach.

Ordinary Global and Regional Node calls currently cost one request unit each.

Archive Node calls currently cost two.

This keeps standard method accounting simple while making historical data more expensive in a visible way.

The platform's additional Dedicated, Unlimited and Self-Hosted models matter once request-based RPC is no longer the best economic shape.

QuickNode's API Credits illustrate a credit-based model.

One raw Ethereum call currently maps to twenty credits for ordinary methods.

Advanced APIs use larger multipliers.

The same number of requests on another chain can consume a different number of credits.

The application's network mix therefore becomes part of the pricing calculation.

Alchemy represents a more granular compute model.

A cheap method such as eth_blockNumber uses fewer CUs than eth_call.

eth_getLogs is heavier.

Debug traces are heavier still.

This can be efficient when the application's traffic is dominated by low-compute methods.

It requires more precise forecasting when the method distribution is complex.

None of these approaches should be judged from the unit name alone.

One million RU, one million API Credits and one million CUs are not comparable quantities.

The conversion must flow through the workload.

Retries belong in that conversion.

If an application intends to make fifty million calls but provider throttling, network errors and short client deadlines create another three million retries, fifty-three million attempts are closer to the real infrastructure workload.

WebSockets belong in the calculation.

A persistent stream can reduce polling traffic.

It can also create reconnects and historical backfills.

A managed stream may have an entirely separate billing model.

Logs belong in the calculation.

A single logical query can become dozens or hundreds of RPC calls when block ranges need to be divided.

Archive state belongs in the calculation.

An application that performs historical state reads should not be costed as if every call were a cheap latest-state lookup.

Peak throughput belongs in the calculation.

A plan can contain enough monthly units while still being too small for a launch-day burst.

Once these variables are measured, use the editable workload model above.

Replace the default call counts with your own.

Replace the billing weights with the current provider values.

Add retry overhead.

Add the cost per million units or compare the resulting units directly against the provider's included plan allocation.

That gives you a reproducible model rather than an intuition.

Then benchmark reliability under controlled conditions.

Use the same cloud region.

Use the same method mix.

Use the same block references.

Use the same concurrency.

Do not silently retry during the first benchmark.

Record p50, p95 and p99 latency.

Record timeouts.

Record 429s.

Record HTTP 5xx responses.

Record method restrictions and archive failures separately.

If you do not have those results, mark them unavailable rather than inventing them.

Finally, include the cost of leaving.

Applications built primarily on native RPC methods are easier to migrate.

Applications built around proprietary streams, indexing APIs and custom webhook formats can be cheaper to operate today while becoming more expensive to move later.

That may still be the correct trade-off.

The dependency should be deliberate.

For applications still deciding whether to remain on pooled RPC or move to isolated infrastructure, TokenToolHub's dedicated versus shared RPC guide provides the next decision layer.

For archive-heavy workloads, use the archive node research to define exactly which historical state your application needs.

For multichain provider selection, compare the resulting cost model against TokenToolHub's multi-chain hosting guide.

If you are investigating a transaction retrieved during your RPC testing, use the Transaction Decoder for supported EVM transaction analysis.

That is a research step.

It should remain separate from the infrastructure benchmark.

Once you can calculate that equation with your own traffic, provider pricing stops being confusing.

It becomes an infrastructure model you can test.

FAQs

References and primary documentation

• NOWNodes documentation
• NOWNodes current shared and custom pricing
• Chainstack pricing, Request Units and throughput limits
• Chainstack platform documentation
• Chainstack Archive Data
• Chainstack Dedicated Nodes
• QuickNode API Credit schedule
• QuickNode Ethereum endpoint and pricing documentation
• QuickNode Streams billing documentation
• Alchemy current pricing
• Alchemy Compute Unit documentation
• Alchemy eth_getLogs documentation
• Ethereum JSON-RPC method reference

RPC pricing, included quotas, billing-unit multipliers, method costs, archive availability, streaming charges, throughput limits and dedicated-node rates can change. Verify current provider documentation before procurement. Calculator results are estimates based on the inputs entered and should be reconciled against provider usage telemetry before production budgeting. Performance results should be compared only when region, method mix, concurrency, block range and sample size are controlled. This guide is technical infrastructure research and does not constitute financial or investment advice.