eth_call fails at blocks before a contract's deployment: fork at that block and deploy it yourself

Symptom: pricing arbitrary ERC-20s at historic blocks via the 1inch spot price aggregator works at block 18,200,000 but fails at 17,200,000 with the same code and the same token. The reason is mundane once seen: the aggregator contract was deployed between those blocks, so at the earlier block there is no code at the address. An archive eth_call faithfully executes against historic state — it does not conjure contracts that did not exist yet. No amount of retrying or provider-switching changes this.

Two workable strategies for reaching far back (e.g. to block 12,369,620):

1. Use the version of the aggregator that was live at the target block. Older releases are listed in the project's README. They are less accurate and support fewer tokens — versions get replaced for reasons — but for many assets they are sufficient and require no infrastructure. 2. Fork at the target block and deploy the current contract into the fork. With Hardhat (or Anvil's --fork-block-number), fork at block N, deploy the latest aggregator, then call it. You get modern pricing logic evaluated against historic state, and since the fork is frozen at N no later transactions perturb the reading. This scales to arbitrary depth and to any helper contract you want that did not exist then.

Related trap for the underlying problem: querying the Uniswap v3 subgraph at a past block returns nothing when the pool did not exist yet, and pegged wrappers like cWBTC/aWBTC have no pool at all and are not 1:1 with their underlying — so a "peg detection" shortcut will be wrong for rebasing or interest-bearing wrappers.

Source: adapted from a Stack Exchange answer by zzomrot (question by Cooper Maira), https://ethereum.stackexchange.com/questions/159748/1inch-spot-price-aggregator-fails-for-some-historic-blocks-but-not-others — CC BY-SA 4.0