A transaction appears in a recent block, then an explorer shows a different status or location. One possible explanation is a chain reorganisation: the network’s accepted recent history has changed as a different branch becomes canonical.
Consensus details differ between blockchains. Ethereum’s proof-of-stake FAQ explains fork-choice concepts and finality in its own system. Do not apply one network’s confirmation or finality assumptions to another simply because both have blocks.
Separate the transaction from its inclusion
A transaction hash identifies the transaction. Its inclusion in a particular block is a separate fact. If that block leaves the canonical chain, the transaction may be included again elsewhere, return to a pending state or fail to appear in the new history, depending on validity and network circumstances.
That is why an application should not treat one observed log or one fresh block as an irreversible business event. It needs a policy appropriate to the network, value at risk and operation being performed.
Keep enough context to reconcile
When recording an event, retain the network, transaction hash, block hash and block number. A block number alone may refer to a different block after a reorganisation. Follow the client’s documented handling of removed logs and resubscription or rescan behaviour.
For a user investigating a transfer, check a reliable explorer and the service’s stated confirmation policy. Do not send the same payment again solely because a status briefly changes. Confirm the current transaction state and contact the receiving service when necessary.
A reorganisation is a technical event, not automatically proof of theft or a reason to trust an unsolicited “recovery” service. Never disclose wallet recovery phrases to resolve an explorer discrepancy. The useful response is to verify the chain and transaction context, then reconcile the application’s record with the network’s accepted history.