overlay
Erigon RPC overlay Namespace: Stateless Contract Bytecode Injection for Analytics
The overlay namespace is an Erigon-specific extension that allows you to replay historical blocks with a modified contract bytecode, without deploying anything on-chain. It is designed for analytics use cases where you need to inject custom event emissions into an existing contract and retrieve the logs those events would have produced.
The overlay namespace requires an archive node (--prune.mode=archive). All methods replay historical state, which is not available on pruned nodes.
Enable the namespace with --http.api=...,overlay.
Timeouts
Two flags control how long overlay operations can run:
--rpc.overlay.getlogstimeout— overall timeout for anoverlay_getLogscall (default:5m0s)--rpc.overlay.replayblocktimeout— per-block replay timeout within agetLogscall (default:10s)
Methods
overlay_getLogs
overlay_getLogsReplays a range of historical blocks with an optional state override (modified bytecode, balance, nonce, or storage) and returns the logs that would have been emitted.
This is equivalent to running eth_getLogs on a hypothetical version of the contract — useful for retroactively adding event emissions to contracts that were deployed without them.
Parameters
1
filter
FilterCriteria
Same filter object as eth_getLogs: fromBlock, toBlock, address, topics
2
stateOverride
StateOverride (optional)
Map of address → overrides. Each override can set code, balance, nonce, state (full state replacement), or stateDiff (partial state patch). Same format as the state override in eth_call.
Returns
Array of log objects (same structure as eth_getLogs).
Example
Blocks in the requested range are replayed concurrently (up to runtime.NumCPU() workers). Each block is independently replayed from the state at blockNumber - 1.
overlay_callConstructor
overlay_callConstructorReplays the constructor transaction of an existing contract using a different bytecode and returns the effective creation code that would have been stored.
This is useful for understanding what a contract would have initialised to if it had been deployed with different logic, without redeploying anything.
Parameters
1
address
Address
The address of the already-deployed contract
2
code
Bytes
The replacement bytecode to use instead of the original deployment bytecode
Returns
Example
Internally, this method:
Looks up the contract's creation transaction via the Otterscan API
Replays all transactions in that block up to (but not including) the creation tx
Executes the creation tx using the provided bytecode instead of the original
Returns the effective code that would have been stored at the contract address
overlay_callConstructor requires the Otterscan API (--http.api=...,ots,overlay) to resolve the contract creation transaction.
Last updated
Was this helpful?