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. Confirm the exact address and every topic position, including case normalization and whether you intended a wildcard. Finally, check whether the endpoint supports the method and range you requested. An explicit rejection is different from a successful empty result; policy alone does not explain why a particular query returned no logs.
A reproducible fixed-block sample
BlockVectra operates BSC infrastructure. Our keyed BSC internal QA observed this at UTC 2026-10-25T13:26:21.586695Z. Three serial HTTP/RPC calls ran: eth_chainId, eth_getTransactionReceipt, then eth_getLogs. chainId returned chain 56. The receipt was for a transaction in fixed block 129476271 (0x7b7a6af). The getLogs filter used only the contract address and that fixed block range, with no topics. It returned four logs. One selected ERC-721 Transfer for token 1811 matches the receipt event across address, topics, data, blockHash, blockNumber, transactionHash, transactionIndex, and logIndex. The other three are not individually receipt-validated here.
The saved check runs offline, with no key or network after download. Get all eight files from the Gist into one directory, use Node.js 22+, and run:
node verify-sample.mjs observed-sample.json
Expected output:
PASS 1 receipt event matched among 4 returned logs
Live requests are separate: they need your endpoint, permissions, and method policy. Never paste API keys or other secrets into issue comments.
What the saved response can and cannot tell you
This is a consistency check within one saved observation. It does not prove independent canonicality, cover full history, explain the original incident, or measure speed. Use it to verify that a known receipt event and a fixed-block log response can be reconciled, then apply the same checks—chain, block hash, exact filter, method policy—to your own case.
If this is useful, start with the artifact and the public BSC #3853 thread. Both are public.
Top comments (0)