RPC routing for indexers and historical backfills
Indexers and backfills spread heavy historical reads across providers withload-balanced, so one provider’s quota stops being your ceiling. Historical
state, receipts and logs have different coverage across providers, so qualify
your exact queries through your exact Lasso URL before you move.
Qualify the queries you depend on
Build a small set of known-good answers from your own contracts and history: an expected state value, a block hash, a nonempty log set or a receipt. Run each through the direct provider and through Lasso.
An empty result doesn’t prove a provider covered the history you asked for.
Choose the pool
Lasso’s historical workload evidence shows dated
results across chains, depths and methods. Use it as a model for your own
test, not as a coverage promise.
Handle range limits
When no eligible provider serves aneth_getLogs range after a range refusal, Lasso returns
-32602 with data.code: "log_range_limit"; follow its next_action: split
the range and retry. Lasso doesn’t
split it for you. Lasso learns each provider’s span limit from these refusals
and tries providers that accept a wider range first. On a Custom profile, the
learned limit shows in the profile’s knowledge.
A successful response can still be missing logs, so read
log completeness if your application
needs every log.
Limits
- Batches route per item. A batch isn’t pinned to one provider or one block. For related reads at one block, use read at one block.
- Keep a durable checkpoint and a reorg overlap, and deduplicate logs by identity.
- A final JSON-RPC error, including a refused range, is free.
- Test from your deployment regions under representative volume; the rollout steps cover moving traffic.
Next
- RPC method behavior: history, logs and trace methods.
- Custom profiles: declare a log-span cap you know.
- How Lasso learns your providers: learned range limits and how they clear.
- Historical workload evidence: what Lasso has measured.