An empty eth_getLogs result can be valid, but a successful response does not establish that the provider served a complete view. If a receipt contains the event you expected, compare the chain, block and exact filter before changing providers.

The pattern is familiar from BSC #3853 , where a reporter described eth_getLogs returning [] against legacy BSC endpoints despite receipt evidence. That is their observation, not a cause we reproduced. It reminds us to separate what a receipt proves from what a log query returned.

Check the query before the endpoint

Start with the exact chain. A filter that looks right on BSC mainnet (chain ID 56) can be meaningless on a testnet or another EVM chain. Then compare the same block: the receipt's blockHash against the blockHash in returned logs, and whether you are looking at the same canonical block or a stale, reorged view. The sample below is a single fixed-block observation; it does not independently prove canonicality.…