If an Ethereum transaction is marked replaced, locate the transaction from the same sender using the same nonce that was actually included, then inspect what it did. The original hash may never become a payment receipt. A replacement can preserve the intended transfer, cancel it or perform a different action, so the label alone does not establish that the recipient was paid.
Keep the original hash, but stop using it as the only receipt
Open the original transaction on the correct network's explorer and record its sender and nonce. Follow any replacement link offered by the explorer, then compare those fields on the replacement. If there is no direct link, inspect the sender's outgoing history for that nonce. Do not match two records solely by approximate time, amount or a wallet's human-readable activity label.
Etherscan's dropped and replaced explanation describes replacement by another confirmed transaction using the same sender nonce. Its Dropped label is a different observation: a pending transaction can disappear from the nodes the explorer observes and later be rebroadcast. Dropped by itself therefore does not prove that an attempted payment has been permanently cancelled.
A replacement record still needs a payment check
| Confirmed replacement does this | What to verify | How to describe the original payment |
|---|---|---|
| Sends the intended ETH amount to the intended recipient | Sender, destination, value and execution result | Payment may be represented by the replacement hash |
| Calls a token contract | Actual token movement, token identity and recipient | Contract call alone is not proof of the expected token receipt |
| Sends a cancellation-style transaction back to the sender | Actual destination and resulting movement | The intended recipient was not paid by this cancellation |
| Executes a different operation | Its complete effect, not just matching nonce | Investigate the new action separately |
| Is included but execution fails | Receipt result and relevant balance changes | Inclusion does not establish successful payment |
| Has not been included | Current pending state and other competing attempts | No confirmed replacement receipt has been established |
Ethereum's transaction documentation separates sender, destination, nonce, value and input data. Those fields matter because a replacement is another signed instruction, not an edit to the old explorer page. A failed included transaction also differs from a never-included attempt: do not infer successful payment merely because the account has moved on to a higher nonce.
Three ways one checkout can produce different hashes
Consider a fictional 0.05 ETH payment from account A to merchant B. Attempt H1 has nonce 17 and remains pending. The sender uses a wallet's speed-up function and signs H2 with nonce 17, retaining the same destination and value. If H2 is included successfully with the expected transfer, the evidence for B is H2. H1 remains useful for explaining the history but is not a second completed payment.
In a different outcome, the sender signs H3 at nonce 17 as a cancellation-style action, and H3 is the one included. That can consume the same nonce without paying B. In a third outcome, the sender presses Send again with nonce 18 instead of replacing nonce 17. That is a separate instruction, not a competing version of the same nonce. If both applicable transfers execute, B can receive two payments. Do not retry until you know which outcome you are observing.
The fictional labels are deliberately not real hashes and imply no current fee or replacement threshold. They show why 'I sent another one' is an inadequate support description. Specify whether the new attempt reused the original sender nonce or created a new sequential transaction. Our nonce overview explains that account sequence without requiring you to change wallet settings.
Build a short reconciliation trail
- Save the original hash, network, sender, nonce and order identifier, if applicable.
- Find a candidate replacement and verify that its sender and nonce match.
- Check whether that candidate is included and inspect its execution result.
- Locate the actual ETH or token transfer to the expected recipient.
- Compare the received asset and amount with the payment instructions.
- Send support the confirmed payment hash plus the original hash as background, explicitly stating the relationship.
For a token transfer, a contract address in the outer To field is not necessarily the customer or merchant receiving the token. Inspect the relevant token movement. The Etherscan field guide helps separate these records. If the replacement reverted or moved a different asset, describe that directly instead of submitting it as proof that the original invoice was settled.
What a wallet error can tell you, and what it cannot
Some applications report replacement through a software error rather than a clear explorer link. The ethers v5 provider documentation distinguishes repriced, cancelled and replaced outcomes and exposes the replacement transaction and receipt. A developer should inspect those returned records rather than treating every replacement error as either total failure or confirmed payment. End users should ask the app for the replacement hash and network.
If the transaction is still pending and you are trying to replace it, use your wallet's documented procedure. MetaMask's replacement troubleshooting notes that earlier outstanding nonces can block later attempts. That is a separate queue problem; it does not justify inventing a new recipient payment. Avoid manual nonce experiments when you have not reconciled the existing records.
Close the case against the receiving instructions
A successful replacement transfer can still need reconciliation with an exchange or merchant order. Provide the order reference, both hashes, the recipient and the confirmed amount, without exposing wallet keys. Do not assume that an order system automatically associates every replacement hash with the first attempt or that its deadline restarts when you speed up a transaction.
Before making a later no-account swap, keep this distinction in your payment notes: one order can have several attempted hashes, while only the actual executed transfer establishes what was sent. If two different nonces paid, report both. If the replacement cancelled the transfer, report that no payment to the intended recipient was established. A precise record helps support investigate without another speculative send.
FAQ
What does dropped and replaced mean on Ethereum?
The original attempt was superseded by a confirmed transaction using the same sender nonce. Inspect that replacement to determine whether it paid, cancelled or changed the intended action.
What should I check when MetaMask says transaction dropped or replaced?
Start with the original hash, sender and nonce on the correct explorer. Find any confirmed replacement and check its actual result before sending another payment.
Can a dropped transaction reappear instead of being replaced?
Yes, a pending attempt dropped by the observed nodes can be rebroadcast. A Dropped label alone is not the same evidence as a confirmed competing transaction with the same nonce.