How to Find the Transaction That Replaced an Older Transaction

Key Takeaways

1. A replacement transaction is not a second payment. It is a competing version of the same spend. On Bitcoin it reuses at least one of the original inputs. On Ethereum and other EVM chains it reuses the same sender address and the same nonce.
2. The fastest method is to paste the old transaction ID into an explorer that tracks the mempool. mempool.space shows a replacement timeline for Bitcoin, and Etherscan marks a stale Ethereum hash as "Dropped and Replaced".
3. If the explorer has already forgotten the old transaction, search by the shared identity instead: the spent output on Bitcoin, or the sender address plus nonce on EVM chains.

Why Transactions Get Replaced

An unconfirmed transaction is a proposal, not a settled record. It sits in the mempool, which is the waiting area each node keeps for valid transactions that have not yet been included in a block. While it waits there, the sender can publish a different version of the same spend, and nodes may accept the new version and discard the old one.

There are two common reasons this happens:

• A fee bump. The original fee was too low for current network conditions, so the sender rebroadcast the transaction with a higher fee.
• A cancellation. The sender published a replacement that sends the funds back to their own address, which nullifies the original intent.

The result confuses people. Your wallet or explorer shows a transaction ID that will never confirm, and the funds you expected are attached to a different ID that you were never told about. Finding that new ID is a specific, repeatable lookup.

The Rule That Makes a Replacement Findable

You do not have to guess. Both major chain designs force the replacement to share something with the original, and that shared element is your search key.

On Bitcoin, replacement is governed by Replace-by-Fee (RBF), a mempool policy. The Bitcoin Core policy document states that a replacement transaction must spend at least one of the same inputs as the transaction it conflicts with, and must pay a higher absolute fee. So the original transaction's inputs are the link.

On Ethereum and other EVM chains, every transaction from an account carries a sequential nonce. Only one transaction per nonce can ever be included. A replacement therefore has the same sender and the same nonce, but a different hash.

One important detail for Bitcoin users: BIP 125 originally required a transaction to signal that it was replaceable. That is no longer how most of the network behaves. Bitcoin Core made full replace-by-fee the default policy in version 28.0, meaning any unconfirmed transaction can be replaced whether or not it signalled willingness.

Method 1: Check the Old Transaction ID on a Mempool Explorer

This is the approach that works for most people, and it takes under a minute.

1. Copy the transaction ID that is stuck or missing.
2. Open a Bitcoin explorer that indexes the mempool, such as mempool.space.
3. Paste the ID into the search bar.
4. Look for a replacement notice on the transaction page. When mempool.space knows the transaction was displaced, it shows that the transaction was replaced and links the newer version.
5. Open the linked ID and check its confirmation status.

mempool.space also displays a replacement timeline when a transaction was bumped several times, so you can follow a chain of three or four versions down to the one that actually confirmed.

The limitation is memory. Explorers keep evicted transactions for a retention window, not forever. If the replacement happened weeks ago, this method may return nothing.

Method 2: Query the API Directly

If you are building a tool, running support for users, or the web interface is not showing what you need, the mempool.space REST API exposes the same data in machine readable form.

The response for the first endpoint contains a replacements object. Inside it, tx.txid is the newest known version, and the replaces array lists the versions it displaced, each with its own fee, virtual size and fee rate. Because the structure is recursive, a long bumping sequence appears as nested entries. Both fields come back empty when the service has no replacement history for that ID.

Note that public endpoints enforce rate limits. Repeated automated polling can result in an HTTP 429 response.

Method 3: Ask Your Own Node or Wallet

If the transaction came from a wallet you control on Bitcoin Core, the answer may already be stored locally. The gettransaction RPC call returns several relevant fields:

• replaced_by_txid: the ID of the transaction that replaced this one
• replaces_txid: the ID of the transaction this one replaced
• walletconflicts: other wallet transactions that conflict with this one
• bip125-replaceable: whether the transaction signalled replaceability

There is a caveat that trips up developers. These replacement fields are only populated when your own wallet performed the replacement, typically through the bumpfee or psbtbumpfee commands. If a counterparty bumped a transaction you merely received, the fields will not appear. This behaviour was clarified in the Bitcoin Core help text after a user report in 2023.

Method 4: Finding a Replacement on Ethereum and EVM Chains

The workflow is different because the identifier is the nonce rather than an input.

1. Paste the old hash into Etherscan. If the status reads "Dropped and Replaced", a newer transaction with the same nonce has already confirmed.
2. Expand the additional details on that page and note the nonce value and the sender address.
3. Open the sender address page and look through its transaction list for the entry carrying that nonce.
4. That entry is the replacement. Its hash is different, its gas price is usually higher, and its destination or value may differ if the sender was cancelling rather than speeding up.

Etherscan's own documentation explains the cause plainly: a transaction is replaced when a new transaction with the same sender account nonce is accepted and confirmed, taking over that position in the sequence. Common triggers include a low original gas price, a wallet connected to an out of sync node that supplied an incorrect nonce, or a deliberate user cancellation.

Developers can also handle this at the wallet layer. EIP-2831 proposes a standard tx_replacement event that reports the old hash, the new hash, the nonce and the sending address, so that applications can follow the swap automatically instead of polling.

How to Confirm You Found the Right One

Before you tell a customer or a colleague that you have located the replacement, run these checks.

When You Cannot Find It

Sometimes the search genuinely fails, and it helps to know which explanation applies.

• The retention window expired. Explorers discard evicted transactions after a period. Old cases may be unrecoverable through public tools.
• Nothing replaced it. A transaction can be dropped without a replacement, for example when a node's pool fills up and evicts the lowest paying entries. In that case there is no new hash to find, and the funds never left the sender.
• Coverage differs by explorer. Not every explorer stores replacement history. A transaction visible as replaced on one service may simply return "not found" on another, which is a reporting gap rather than a lost transaction.
• The sender knows and you do not. If an exchange or payment processor bumped the fee, their support team can supply the new ID directly, which is faster than any explorer search.

The Practical Lesson

Replacement is a normal, permitted part of how these networks work, not an attack or a bug. But it has one consequence worth internalising: an unconfirmed transaction is never final. Since full replace-by-fee became the Bitcoin Core default, any pending transaction can in principle be replaced by the sender, and the same has always been true of a pending EVM transaction with an unused nonce. For anything of value, wait for confirmations before treating a payment as received.

Frequently Asked Questions

Did the old transaction still cost me a fee? No. A transaction that never confirmed was never included in a block, so no fee was collected and no coins moved. Only the version that confirms is charged.

Can both the original and the replacement confirm? No. On Bitcoin the two versions conflict because they spend the same input, so including one makes the other invalid. On EVM chains only one transaction per nonce can ever be included.

Why does my explorer say the transaction does not exist? Once a transaction is evicted from the mempool and never mined, it exists nowhere on the blockchain. Explorers that only index confirmed data will return nothing. Try a mempool-aware explorer, or search by input or nonce instead.

Is a replacement the same thing as a double spend? Mechanically they are related, since both involve conflicting spends of the same funds. The difference is intent and outcome. A fee bump is the sender rebroadcasting their own payment at a higher price. A fraudulent double spend targets a merchant who accepted an unconfirmed transaction as final.

How can I tell whether a pending transaction can still be replaced? On Bitcoin, assume yes. Full replace-by-fee is now the default policy, so signalling flags are no longer a reliable guide. On EVM chains, any pending transaction can be replaced by its sender until its nonce is used by a confirmed transaction.

Related Terms

1. Replace-by-Fee (RBF)
   • A mempool policy allowing an unconfirmed transaction to be swapped for a higher paying version.
2. Nonce
   • A sequential counter attached to every transaction from an EVM account, used to enforce ordering.
3. Mempool
   • The set of valid but unconfirmed transactions a node holds while waiting for them to be mined.
4. UTXO
   • An unspent transaction output, the unit of value a Bitcoin transaction consumes as an input.
5. Child Pays For Parent (CPFP)
   • An alternative to replacement, where a new transaction spending the stuck one attaches a high fee to pull both into a block.

Sources

• Bitcoin Core, doc/policy/mempool-replacements.md, GitHub: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
• BIP 125, Opt-in Full Replace-by-Fee Signaling: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
• Bitcoin Optech, Replace-by-fee topic page: https://bitcoinops.org/en/topics/replace-by-fee/
• The Mempool Open Source Project, REST API documentation: https://mempool.space/docs/api/rest
• Etherscan Information Center, Transaction Dropped and Replaced: https://info.etherscan.com/transaction-dropped-replaced/
• Etherscan Information Center, What happens when a Dropped Transaction is replaced: https://info.etherscan.com/dropped-and-replaced-meaning/
• EIP-2831, Transaction Replacement Message Type: https://eips.ethereum.org/EIPS/eip-2831
• Bitcoin Core issue 27781 and the clarification merged in pull request 29302, on replaced_by_txid scope

More Reading

1. Bitcoin Optech, Replace-by-fee topic page, for the policy history and the difference between opt-in and full RBF.
2. The Mempool Open Source Project REST API reference, for the exact fields returned by the replacement endpoints.
3. Etherscan Information Center, for the official explanation of dropped, replaced and pending transaction states.

Disclaimer: This article is educational content. It is not financial, investment, tax, or legal advice. Network behaviour, fees, and explorer interfaces change over time, so verify current details against official documentation before relying on them.