Checking a transaction on two block explorers sometimes produces conflicting answers. The discrepancy is rarely a bug; it reflects that each explorer is reporting what its own infrastructure currently sees.
An explorer is a view, not the chain
Explorers run nodes, read the data those nodes hold, and store it in a database optimized for search and display.
Every step introduces delay. A block reaches one node before another, and indexing it into a searchable form takes further time.
So an explorer's display describes what its pipeline has processed, which can lag the network by seconds or, during heavy load, considerably longer.
Unconfirmed transactions live in local memory pools
A transaction that has been broadcast but not yet included sits in each node's memory pool, and those pools are not identical across the network.
Nodes apply their own acceptance policies covering minimum fees, transaction size and replacement rules, so a transaction accepted by one may be dropped by another.
An explorer therefore reports a pending transaction as unknown when its own nodes never accepted it, even though other nodes are relaying it normally.
Reorganizations rewrite recent history
When two valid blocks appear at the same height, nodes temporarily follow different branches until one accumulates more support.
Transactions in the abandoned branch return to pending status. An explorer that indexed the losing branch shows a confirmation that subsequently disappears.
This is why confirmation counts exist. Depth reduces the probability that a block will be reorganized out, and explorers displaying different depths are describing different confidence levels.
Interpretation adds another divergence
Explorers do not just display raw data. They decode contract calls, label addresses, calculate balances and attach names to known entities.
Those enrichments come from each operator's own datasets and heuristics, so token transfer counts and address labels differ between services covering the same chain.
Failed transactions illustrate this clearly: one explorer may show a reverted call prominently while another shows only that fees were consumed.
How to resolve a disagreement
The authoritative check is the transaction receipt as returned by a node, since that is the data the network itself produced rather than a rendering of it.
Waiting also resolves most conflicts, because indexing lag clears and shallow reorganizations settle within a small number of blocks.
Persistent disagreement after several blocks points to something more specific, such as one explorer tracking a fork or having a stale node in its pool.
None of this makes explorers unreliable as tools. It makes them intermediaries, and treating an intermediary's rendering as the ledger itself is the error that produces the confusion.