Pending, failed and dropped describe different observations rather than one universal network outcome. A transaction may be known without inclusion, included with execution failure or absent from one source’s current pending set. Match network, ID, account, receipt and sequence before accelerating, cancelling or creating another payment.
Absence from one interface is not a universal cancellation guarantee.
BTKWIN.COM · EDUCATIONAL EXAMPLEState is reported by a source at a time
A wallet or explorer can derive a label from a provider, local history or node knowledge. Different sources need not see every unconfirmed request at the same time. Align network, hash, sender and update time before treating a wording difference as missing funds.
Ethereum’s transaction lifecycle documentation distinguishes creation, broadcast and inclusion. A hash shown locally does not replace evidence of the actual stage.
This guide concerns common Ethereum-compatible interface labels. Other networks, account systems and internal service references can use different definitions. Do not turn a translated status or color into a substitute for the underlying record.
Pending: known without established inclusion
In this context the source knows a transaction but has not established inclusion. The delay can involve price, sequence, propagation or other conditions. Time alone does not make it a completed failure.
Collect sender, network, hash and nonce where applicable. Inspect earlier unresolved positions and same-position alternatives. Geth’s txpool documentation illustrates pending and queued distinctions as node data.
Before using a supported speed-up, recheck that the request remains unconfirmed. Review the replacement’s destination, value, data and fees. An independent new transfer can add another eventual payment rather than resolve the first.
Failed: establish whether inclusion occurred
An included transaction can fail execution while incurring resource cost. A preparation or simulation failure before inclusion is different. The word failed alone does not establish a settled fee, consumed nonce or executed transaction.
Open the receipt and inspect status, block and usage. EIP658 defines the relevant success/failure status. Separate inclusion from the intended contract outcome.
Do not assume the attempted swap amount became gas or that every failure consumed the configured maximum. Inspect actual gas and effective price and independent earlier approvals. A contract condition may remain unmet despite a higher fee.
Dropped: missing from a particular pending view
A source may stop retaining or tracking a previously known unconfirmed transaction. That observation is not an instruction sent to the whole network to cancel all copies. A valid request can be known elsewhere or reappear through rebroadcast under suitable conditions.
Check for replacement and the sender’s current sequence state using the wallet and appropriate evidence. Review copying and network if one source cannot find the hash. Lack of a receipt is not itself proof of an included failed execution.
Do not infer that funds definitively returned from one dropped label. The useful question is what current chain state, related candidates and the actual wallet establish, with the reporting source’s definition understood.
Dropped and replaced requires following the actual replacement
Where an interface links a replacement, inspect its inclusion and what it did. A replacement can accelerate the original payment or attempt another effect. The link alone does not prove the intended recipient received the original amount.
Preserve original and replacement references and their relationship. A display change should not cause evidence to be discarded before the outcome is clear. Our nonce guide explains grouping alternatives and later operations.
If a source cannot explain the relationship, use official wallet support and non-secret evidence instead of creating another payment to make the history look simpler.
Let the observation choose the next question
| Label | Question | Avoid |
|---|---|---|
| Pending | Broadcast, ordering and current inclusion conditions? | Independent duplicate payment |
| Failed | Included failure or earlier rejection? | Charging the full configured limit by assumption |
| Dropped | Source definition, replacement or rebroadcast? | Universal cancellation claim |
| Dropped and replaced | Which replacement was included and what executed? | Assuming unchanged recipient result |
| Successful, balance absent | Correct destination and receiving requirements? | Bumping a transaction already included |
Example: original, replacement and a later request
Suppose A uses nonce nine, B is a competing candidate at nine and C uses ten. If B is included, inspect B’s effect and then C. A disappearing does not establish C was cancelled.
If B fails after inclusion, its sequence position may still be processed under the ordinary model. If no candidate is included, a high-fee request at ten does not itself resolve the earlier slot.
The numbers are hypothetical, not instructions to edit nonce fields manually. Keep account, network, IDs, positions, states and observation times so recipient updates identify which actual record paid them.
Fees follow actual events and relationships
An included failure followed by another included attempt can create two real fees. Competing candidates should not be counted as two settled payments solely because they both appear in history.
Use actual usage, effective price and applicable route components rather than maximum caps or popup count. Record service charges and independent approvals separately. A fiat balance difference can include price movement rather than only fees.
Our cost tool organizes the selected evidence after the records are classified. It does not infer final settlement from a status label.
Prepare a limited useful support record
Include network, sender, hashes, relevant sequence information, observed states and times, error text and intended task. If several devices or interfaces used the account, review all related submissions before clearing local activity.
Deleting local history does not erase network copies. Nor should a public tracker receive recovery words or private keys to inspect one transaction. Open the appropriate official channel independently.
Our help tool locates execution and service-crediting stages. Recheck after material changes, understand the proposed action and verify the actual outcome before another signature. A label is the start of a question; complete evidence supports the next decision.
Successful execution still needs recipient matching
A successful operation can concern the wrong beneficiary, token contract or network. Before shifting the question to platform crediting, compare those fields and the actual quantity with the receiving instructions. A transaction hash supplied by another party is not a customized receipt merely because its status is green. Keep the relevant output or token-transfer evidence and the receiving account’s own history together when explaining what remains unresolved.
Continue reading
English content and examples reviewed: 27 October 2026. Read the Arabic edition.
