DocsCost Tuning

Cost Tuning

This page is for operators tuning RPC spend vs freshness.

CU Math (Alchemy)

As of the current Alchemy CU model:

  • eth_blockNumber: 10 CU
  • eth_getBlockByNumber: 20 CU
  • eth_getLogs: 60 CU

Webhook and websocket delivery are bandwidth-priced, so for bursty event streams it is often cheaper to batch range scans with eth_getLogs than to process near-head event firehoses one-by-one.

High-Impact Knobs

  • INDEXER_POLL_INTERVAL_MS
  • INDEXER_SCAN_BATCH_BLOCKS
  • MAX_GETLOGS_TOPIC0_OR
  • REORG_CHECK_MODE
  • REORG_PROBE_INTERVAL_SECS
  • WEBHOOK_MAX_EVENTS_PER_BATCH
  • WEBHOOK_MAX_BATCH_BODY_BYTES

Recommended Presets

3 Chains / Low Latency

Use this when near-head latency matters more than CU cost.

INDEXER_POLL_INTERVAL_MS=1000
INDEXER_SCAN_BATCH_BLOCKS=1
MAX_GETLOGS_TOPIC0_OR=20
REORG_CHECK_MODE=full
REORG_PROBE_INTERVAL_SECS=60
WEBHOOK_MAX_EVENTS_PER_BATCH=50
WEBHOOK_MAX_BATCH_BODY_BYTES=131072

3 Chains / Cheap Finalized-Only

Use this as the default finalized indexing profile.

INDEXER_POLL_INTERVAL_MS=5000
INDEXER_SCAN_BATCH_BLOCKS=12
MAX_GETLOGS_TOPIC0_OR=20
REORG_CHECK_MODE=sampled
REORG_PROBE_INTERVAL_SECS=600
WEBHOOK_MAX_EVENTS_PER_BATCH=100
WEBHOOK_MAX_BATCH_BODY_BYTES=262144

6+ Chains / Cheap

Use this when chain count is high and throughput is more important than latency.

INDEXER_POLL_INTERVAL_MS=15000
INDEXER_SCAN_BATCH_BLOCKS=24
MAX_GETLOGS_TOPIC0_OR=10
REORG_CHECK_MODE=sampled
REORG_PROBE_INTERVAL_SECS=900
WEBHOOK_MAX_EVENTS_PER_BATCH=200
WEBHOOK_MAX_BATCH_BODY_BYTES=262144

Safety Warnings

  • INDEXER_SCAN_BATCH_BLOCKS <= 1 across multiple chains tends to maximize eth_getLogs call rate and cost.
  • Polling below 2s while scan batching is above 1 usually adds spend without improving finalized throughput.
  • Keep MAX_GETLOGS_TOPIC0_OR modest (10-20) when many tracked contracts emit overlapping topics.
ConfigurationPanel: Subscriptions