eth_getLogs pricing: 10,000-block calls per plan

Dwellir Growth's $299 monthly allowance covers 150 million successful eth_getLogs calls, each spanning up to 10,000 blocks. Use the full allowance and the subscription costs $1.99 per million calls.

To compare providers, check the permitted block range before dividing their included credits by the cost of each method. This guide calculates included capacity and overages for plans around $300. It also accounts for providers that need several calls to cover one window.

Compare 10,000-block plans around $300

The closest published monthly tiers below cost $199 to $349. Alchemy has no equivalent subscription allowance, so its row uses a $300 spending budget. Prices were checked on September 22, 2026, without annual discounts, taxes, or custom contracts.

The workload is historical Ethereum logs with identical address and topic filters. Each window spans 10,000 blocks, including both endpoints. GetBlock splits each window into seven calls; the other providers use one. Assume successful responses, no retries, and no other account usage.

*Infura permits 294,117 calls per day. Its total and effective cost assume 30 fully used days. Alchemy meters all usage; its row represents purchased capacity.

**GetBlock uses seven archive-endpoint calls per window because its published block cap is 1,500. Its 700 million compute units cover 2.5 million complete windows.

The included-usage prices allocate the whole subscription across its full call capacity. They are not the bill for buying only one million calls. Dwellir Growth still costs $299 if you use only one million of its included calls.

Block range is one limit. Results must also fit each provider's response-size and execution limits. Keep this example below 10,000 returned logs per query. Infura also applies a ten-second execution limit. Dense filters can require smaller windows on every provider. Check the Dwellir, QuickNode, Chainstack, Infura, and Alchemy query limits before sizing a backfill.

Convert included credits into log calls

A successful Dwellir eth_getLogs response consumes one API credit. The block range and number of log entries do not multiply that charge. A production check returned 110 logs across 10,000 blocks. The usage meter counted three responses for three tested requests spanning 1, 100, and 10,000 blocks.

Here is the allowance calculation for each subscription:

The method weights come from QuickNode, Chainstack, and Infura. Chainstack's two-unit rate applies when fromBlock is at least 127 blocks behind the tip. The 10,000-block workload uses that rate.

Infura's allowance resets daily. Its 30-day total assumes you use all 294,117 complete calls every day. Unused daily capacity does not accumulate. These figures measure credit capacity, not a tested throughput guarantee.

Alchemy charges 60 compute units per eth_getLogs call and $0.525 per million compute units. Its $300 budget buys floor(300 / 31.50 × 1,000,000) = 9,523,809 calls. The separate Free plan's allowance does not carry into Pay As You Go. See Alchemy's method weights and pricing.

Account for GetBlock's smaller windows

GetBlock's published guide specifies a 1,500-block cap. A 10,000-block window therefore needs at least seven requests. Its Scale subscription includes 700 million compute units.

On an archive endpoint, ordinary Ethereum calls cost 40 compute units. That allowance covers 700,000,000 / (7 × 40) = 2,500,000 complete windows. The $349 subscription therefore costs $139.60 per million windows at full use. Each window takes seven calls, so this is not single-call capacity.

A full endpoint charges 20 compute units, doubling that calculated capacity if it retains the receipts you need. Verify historical coverage before choosing it. See GetBlock's compute-unit rates.

What do additional calls cost?

Once you use the included allowance, apply the plan's additional-usage rate to the method weight. These costs cover one million further successful 10,000-block calls, with the subscription fee separate.

For example, 151 million successful calls on Dwellir Growth use 150 million included credits and one million additional credits. The monthly bill is $299 + $3 = $302, assuming no other usage.

For sustained Dwellir traffic, also compare an Unlimited add-on. It gives one endpoint unmetered usage up to its own requests-per-second limit. Compare its fixed price against your measured volume and peak demand.

Count rejected attempts and repeated windows

Do not assume every failed request is free or billable. Billing policies can differ by error class, provider, and plan. Verify them against your contract or usage meter.

For example, a scanner might request the same 2,500-block window three times after two transient failures. Only the third attempt succeeds. If all three attempts are billable, retries triple that window's request cost.

Separate sizing errors from transient failures:

• A block-range error requires a smaller range.
• A result-limit error requires fewer matching logs per request.
• A rate-limit error requires slower submission and bounded retries.
• A timeout requires investigation of the range, filter, and provider behavior.

Record the requested range, error class, retry count, and final outcome. That lets you calculate rejected attempts per completed window instead of guessing from total traffic.

Checkpoint after each committed window. Write results and the checkpoint together where possible. Otherwise a crash can replay paid work or advance the cursor past uncommitted rows.

Use stable event keys such as chain ID, block hash, and log index. Deduplicate replays and retain enough block ancestry to undo provisional data after a reorg.

Verify receipt history before buying an archive plan

Historical logs depend on retained receipts and log-serving indexes. Historical account state is a separate storage requirement. An archive label alone does not specify both.

Reth exposes separate pruning controls for receipts, account history, and storage history. Its pruning documentation lists which historical RPC methods remain available under each node mode.

Do not assume a pruned node returns an empty array. Depending on the client and provider, unavailable history can produce errors or other unsupported behavior. An empty result also legitimately means no logs matched.

Before a large backfill:

1. Choose fixed historical windows with known matching events.
2. Query those windows using the exact production filters.
3. Compare returned block hashes, transaction hashes, and log indexes against independently verified samples.
4. Confirm the provider's earliest retained block and failure behavior beyond it.

A recent nonempty result and an old empty result do not prove pruning. The contract may not have existed in the older window. Validate deployment dates and known events before diagnosing retention.

Narrow filters without multiplying requests

A broad filter can hit the result cap after fewer blocks. A narrower filter can reduce response bytes and permit wider windows.

Address arrays and topic alternatives are useful when you need all their matches. Splitting them into many requests can increase cost by scanning the same blocks repeatedly. Compare total requests and returned bytes before choosing either design.

Use a representative sample to estimate window size:

Illustrative result cap: 20,000 logs
Observed average: 100 matching logs per block
Result-limited window estimate: 20,000 / 100 = 200 blocks

Leave capacity for busier blocks and respect the plan's block-range limit. Average density is an estimate, not a bound. Keep adaptive splitting for windows that exceed the result cap.

Record logs per block across several periods, including activity spikes. One quiet sample cannot establish the cost of a multi-year backfill.

Change the retrieval method when it reduces work

Repeatedly scanning the same finalized history is avoidable. Store the first complete result and query your own database for later requests.

Subscriptions still need reorg handling and reconnect recovery. Receipt retrieval also depends on provider support and retention. Compare those requirements before replacing your scanner.

Measure cost per completed range

Run a representative backfill before committing to the full job. Record successful windows, rejected attempts, returned logs, bytes, and elapsed time. Apply the provider's billing rules to those observations.

Use that estimate to choose a plan and a retrieval method. A low per-call price cannot compensate for rescanning the same range or storing incomplete results.

See Dwellir pricing for method availability and allowances. For implementation details, use the eth_getLogs limits guide. If your application needs indexed queries, start with the blockchain indexing overview.