Reverted, Dropped or Not Found: Reading a Failed Transaction on an Explorer

2026-08-12

An explorer can place several very different events under language that feels similar. The search phrase transaction reverted meaning crypto usually points to an execution result that was recorded in a block, while transaction hash not found describes an absence in the particular chain, endpoint, or index being searched. A dropped label often describes a candidate that a node or service no longer retains in a pending pool. These labels are useful only when their layer is kept clear: a public chain record, a node's temporary view, an RPC response, and an explorer's database are related systems, but they are not the same system.

A transaction status moving from network observation to a block receipt

The transaction lifecycle

A signed transaction can be described at several points in its life. It may be created as data, observed by one service, shared among nodes, retained as pending by some of them, selected for a block, executed under that chain's rules, and represented later by receipts and indexed pages. A transaction hash identifies a particular encoded transaction on the chain where that encoding is meaningful. It does not by itself say how far the transaction travelled through this sequence.

Ethereum's public documentation illustrates the distinction by describing a broadcast transaction entering a pending pool and later being included by a validator in a block. Other systems arrange participation, ordering, and finality differently, but the broad distinction remains useful. A candidate seen before inclusion is not yet a permanent ledger entry. Once a transaction is in a block, the block association, execution outcome, and any available receipt describe a different category of evidence from a pending-pool observation.

What reverted means

On Ethereum-compatible networks, reverted usually refers to a transaction that reached execution after inclusion and whose top-level execution finished with failure. EIP-658 introduced a receipt status code in which 1 represents success and 0 represents failure for the relevant post-Byzantium blocks. Explorers commonly turn that receipt-level result into a readable failure label. The label therefore normally concerns execution, not an assertion that the transaction was never broadcast or never placed in a block.

Failure at this layer can arise when the code being executed reaches a condition that makes its top-level call fail. The observable result is distinct from a successful contract interaction: the intended top-level state transition is not committed in the ordinary successful sense, even though the transaction has a block position and consumed execution resources. Exact execution semantics, error decoding, and interface wording vary by chain and virtual machine, so an explorer's short label is a summary rather than a complete causal explanation.

What dropped means

Dropped is usually not a consensus status written into a block. It is a service or client description for a pending candidate that is no longer being retained or displayed in that service's transaction pool view. Go Ethereum's own monitoring documentation, for example, distinguishes several local pool discard events. Those events demonstrate that pool retention is an implementation concern, not the same kind of durable record as a receipt in an accepted block.

Because transaction pools are temporary and distributed, a dropped label says something limited about the observer that applied it. A node may have stopped keeping a candidate while another observer had a different view earlier or later. If no block includes the candidate, the chain has no receipt for it; if an explorer once showed it and later does not, that display history still does not create a canonical on-chain status called dropped. The label should therefore be read as an observation of pending-state handling.

Different reasons for not found

Not found is also narrower than it sounds. A hash can be searched against the wrong chain, an endpoint can lack a matching transaction record, a pending candidate may never have reached that endpoint, or an explorer may not yet have indexed the relevant data. Some systems also expose different identifiers for transactions, messages, bundles, user operations, or layer-specific objects. A visually similar identifier is not automatically a transaction hash in the namespace that a particular explorer expects.

For Ethereum execution APIs, a transaction or receipt query can return null when the requested record is not found at that endpoint, and a receipt is unavailable while a transaction remains pending. That API behavior describes the reply from a particular node interface; it does not turn null into proof of a global negative. Historical retention, synchronization state, indexer coverage, and the selected network can each change what one interface is able to return at a given moment.

What an explorer can and cannot show

An explorer can organize public data into fields such as block number, transaction hash, sender and recipient addresses, value, input data, receipt status, gas use, and event logs where the chain makes them available. It may also decode inputs, label contracts, group activity, or present traces produced by its own infrastructure. These additions can make a ledger easier to read, but they are interpretations and indexed representations layered over protocol data rather than new consensus facts.

An explorer cannot derive facts that the selected chain did not record. A page does not establish a person's identity, intent, off-chain agreement, account-control arrangement, or the meaning of a real-world claim. Nor can a simplified status label settle every question about an application's internal logic. Public transaction data and an explorer's presentation are valuable evidence about the visible chain record, but their evidentiary scope ends at the boundaries of that record and the service's indexing methods.

Time gaps among chains, RPCs, and indexers

Chain data, RPC nodes, pending pools, and explorer indexes operate on different schedules. A block producer works with a local candidate set, an RPC endpoint answers from its own node state, and an explorer first obtains and then processes data before displaying it. During those transitions, one view can show a transaction object with no receipt, another can show only a pending hint, and a third can show no result. None of those views alone necessarily describes every observer at the same instant.

The Ethereum Execution APIs make the separation concrete: a transaction lookup and a receipt lookup are distinct methods, and the receipt response is null when no receipt is found. Comparable interfaces on other chains have their own data models and delay patterns. Indexing delays, node synchronization, chain selection, and data-retention choices explain why explorer language needs a time and scope qualifier. The more precise statement is about what a named service displayed at a particular point, not about an unqualified universal state.

Neutral terms and security boundaries

Neutral wording makes these distinctions easier to preserve. Included refers to a block relationship; pending refers to an observer's temporary candidate view; reverted refers to an execution outcome where that term is defined; dropped refers to a retention or display event; and not found refers to a failed lookup within a stated scope. Treating the labels as interchangeable can erase the difference between a recorded failed execution and an unrecorded or unindexed candidate.

A transaction status is public ledger information, not proof of identity, authority, ownership, or a future outcome. Its interpretation does not require any secret credential or account-control material, and a status label cannot establish asset recovery, a private agreement, or a right to act for someone else. Keeping the boundary between public identifiers and sensitive authority clear helps preserve the limited, factual role that an explorer is designed to serve.

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of August 2026; refer to the latest official information.