fix(constants): cap Polygon getLogs lookback at 2k blocks

[droplet-rl]

Motivation

zion-across-disputer (dataworker) failed an Alchemy eth_getLogs for FundsDeposited on the Polygon SpokePool over blocks 92,330,000–92,339,999:

Log response size exceeded. You can make eth_getLogs requests with up to a 2,000 block
range and no limit on the response size, or you can request any block range with a cap
of 10K logs in the response.

Polygon has no entry in resolveRpcConfig()'s ranges, so it falls through to defaultRange = 10_000.

This is a log-volume problem, not an Alchemy policy change

Measured from the indexer (evm.v3_funds_deposited, originChainId = 137):

window	FundsDeposited logs
the failing 10,000-block request	17,229 — over Alchemy's 10K cap
Alchemy's suggested 5,000-block sub-range	7,952 — just under the cap
first 2,000 blocks	3,697

Alchemy's suggested range is derived from observed density against the same long-standing 10K-log cap, so there's no evidence of a reduced threshold.

The volume came from a burst on 2026-08-20: 29,322 Polygon deposits vs. a 1,000–1,500/day baseline. 27,862 of them were one pattern — Polygon USDC → Base USDC, integrator 00cf, 180 depositor EOAs, uniform 5.25 USDC — running 03:00–10:00 UTC at a peak of about 5,100/hour. It has since subsided to about 60–100/hour.

Why 2,000 and not 5,000

A stopgap of "137": 4500 is already live in bot-configs. The worst 2,000-block window that day held 4,324 logs, which extrapolates to 9,729 at a 4,500-block range — within 3% of failing again at peak.

At a range of 2,000 or less Alchemy applies no response cap at all, so log density stops mattering entirely. That is the property worth having in the repo default, rather than a number tuned to the last burst.

Trade-off

5x more eth_getLogs calls per Polygon lookback window across relayer / dataworker / finalizer, in exchange for a bound that doesn't depend on traffic. Worth discussing whether adaptive range-splitting on this error class is a better long-term answer than a static per-chain floor.

BUNDLE_END_BLOCK_BUFFERS[POLYGON] is 128 and the largest MIN_DEPOSIT_CONFIRMATIONS[POLYGON] is 128, both well under 2,000, so the scan window doesn't get pinned behind head.

Notes

• Not built or tested locally — one-line constant, no dependency install in this environment. Relying on CI.

Requested by @paul in Slack.

🤖 Generated with Claude Code