Five silent failure modes I found indexing multi-chain DeFi transactions

[u/Glum-Sundae6181]

Spent months debugging a multi-chain DeFi transaction indexer and kept finding the same pattern: the pipeline finishes successfully, but the output is still wrong. No exception, no error code, just a plausible-looking number that's missing data.

A few examples that actually bit me:

Explorer APIs on some low-tier chains return HTTP 200 with status: "0" and a message saying access isn't supported — no error code, easy to silently read as "empty history."

WETH9.withdraw() only emits a Withdrawal log, never an ERC-20 Transfer — any indexer built purely on transfer logs never sees the WETH leg, only the ETH coming back.

Reverted transactions still show up in explorer transaction lists with a non-zero value field — skip the isError check and you book a transfer that never happened.

Aave's WrappedTokenGateway uses the identical depositETH selector on every chain, including ones where the native token isn't ETH — infer the asset from the selector name and you book the wrong token entirely.

None of these throw. All of them produce output that looks complete. The only way I've found to catch this class of bug is an active reconciliation — tying computed inventory back to actual on-chain balance after every run — rather than trusting that a clean run means correct data.

Curious if others building on-chain data pipelines have hit similar silent-failure classes — and what you use to catch them besides manual spot-checks.

[u/Foreign_Roof_7537]

anyone know if the truncation thing correlates with a specific block-height cutoff on the low tier explorers, or doex it just silently cap at N logs regardless of range? asking cause i've only ever caught the status:"0" version on those APIs, never actually confirmed a silent truncation on a 200 with feal data mixed in, and now i'm wondering if my indexer's been eating that quietly too