Fee Sniping and Replacement Cycling Attacks on Pending Trades

introduction

MEMPOOL ATTACK VECTORS ON PENDING TRADES

Introduction

How Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP) are weaponized against unconfirmed Ordinals and Runes transactions.

Fee sniping and replacement cycling are active attack vectors in the Bitcoin mempool that directly threaten the finality of pending Ordinals and Runes trades. These attacks exploit Bitcoin's transaction replacement and fee-bumping mechanisms—specifically BIP 125 Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP)—to outbid, replace, or invalidate a victim's unconfirmed transaction. The attacker monitors the mempool for profitable pending trades, then broadcasts a conflicting transaction with a higher fee rate, incentivizing miners to confirm the attacker's version and effectively stealing the asset from the original trade.

The operational impact is severe for marketplace operators and trading bots that rely on zero-confirmation or mempool-level trade finality. An attacker can snipe a high-value inscription or Runes token by observing a buy transaction and immediately crafting a replacement that sends the same UTXO to their own address. In a replacement cycling attack, the attacker repeatedly broadcasts conflicting transactions to keep the victim's original trade in a perpetual state of mempool limbo, preventing confirmation until the victim's wallet or marketplace logic times out. These attacks are not theoretical; they have been observed in production against Ordinals marketplaces with insufficient mempool monitoring and fee strategy defenses.

Mitigation requires a multi-layered approach. Marketplace backends must implement real-time mempool monitoring to detect conflicting transactions and alert users or automatically respond with countervailing fee bumps. Wallet and marketplace architectures should avoid treating unconfirmed transactions as final, especially for high-value assets. Teams operating trading infrastructure should review their fee-bumping strategies, RBF signaling policies, and CPFP wallet logic to ensure they can defend against replacement attacks without introducing new vulnerabilities. Chainscore Labs provides protocol impact assessments and integration reviews to help marketplace and wallet teams harden their transaction lifecycle against these mempool-level threats.

MEMPOOL ATTACK VECTORS

Quick Facts

A technical summary of fee sniping and replacement cycling attacks against pending Ordinals and Runes trades, identifying affected actors and required actions.

Area	What changes	Who is affected	Action
Attack Mechanism	Attackers monitor the mempool for profitable pending trades and broadcast a conflicting transaction with a higher fee (RBF) or a high-fee child transaction (CPFP) to outbid the original and capture the asset.	Marketplace operators, traders, and wallet infrastructure.	Review mempool monitoring and transaction finality logic against these specific attack patterns.
Fee Sniping	An attacker sees a pending buy transaction for a high-value asset and replaces it with their own purchase transaction paying a higher fee, effectively stealing the trade.	Buyers on marketplaces with slow or predictable transaction finalization.	Implement countermeasures such as first-seen-safe transaction relay or off-chain order matching with atomic settlement.
Replacement Cycling	An attacker pins a victim's transaction in the mempool by continuously broadcasting higher-fee conflicting transactions, preventing its confirmation to extract a ransom or disrupt an auction.	Sellers and auction platforms relying on mempool visibility for price discovery.	Evaluate the use of transaction pinning detection and mitigation strategies in trading infrastructure.
Affected Protocols	Ordinals and Runes trades are uniquely vulnerable because their value is tied to specific UTXOs, making replacement attacks directly profitable if the attacker can control the winning transaction.	Ordinals marketplaces, Runes trading desks, and OTC brokers.	Conduct a protocol-specific risk assessment of UTXO-based asset transfer flows.
Infrastructure Risk	Standard Bitcoin node mempool policies do not protect against these attacks; they are inherent to the design of RBF and CPFP.	Node operators and infrastructure teams running marketplace backends.	Deploy custom mempool monitoring and transaction rebroadcasting strategies to detect and alert on replacement attempts.
Wallet Vulnerability	Wallets that automatically rebroadcast or bump fees on stuck transactions can inadvertently assist an attacker in a replacement cycling attack.	Wallet developers and users of automated trading bots.	Review wallet fee-bumping logic to ensure it does not blindly participate in fee auctions for high-value UTXOs.
Mitigation Status	No protocol-level fix exists; mitigation relies on application-layer logic, such as using package relay, out-of-band transaction submission, or trusted relay networks.	Protocol architects and marketplace CTOs.	Verify the current status of mitigation techniques against the canonical Bitcoin Core mempool policy.

technical-context

MEMPOOL EXPLOITATION

Attack Mechanics and Technical Context

How attackers use Bitcoin's fee-bumping mechanisms to front-run and steal pending Ordinals and Runes trades.

Fee sniping and replacement cycling are mempool-level attacks that exploit the public nature of unconfirmed Bitcoin transactions to steal valuable Ordinals and Runes. The attack surface exists because trades in these meta-protocols are often conducted off-chain and then broadcast as standard Bitcoin transactions, making them visible and mutable before confirmation. An attacker monitors the mempool for a pending trade—such as a Partially Signed Bitcoin Transaction (PSBT) or a direct transfer of an inscribed satoshi—and then broadcasts a conflicting transaction that spends the same UTXO but pays a higher fee. This leverages the Replace-By-Fee (RBF) policy, where miners are incentivized to include the higher-fee transaction, effectively canceling the original trade and diverting the asset to the attacker's wallet.

The 'replacement cycling' variant is a more sophisticated attack against multi-step trade protocols. An attacker does not just replace a single transaction but systematically disrupts a chain of dependent transactions. For example, in a Runes atomic swap, the attacker might replace the initial funding transaction with a higher-fee version that changes the output script, invalidating the subsequent claim transactions. This can lock assets indefinitely or allow the attacker to claim both sides of the trade. The core vulnerability is the reliance on unconfirmed transaction chains without robust, time-locked fallback mechanisms. Marketplace operators and trading infrastructure teams must assume that any unconfirmed transaction in a trade sequence is a target for replacement.

The operational impact extends beyond direct theft. A successful replacement attack can corrupt the state of off-chain indexers that track Ordinal and Runes ownership, as they may briefly follow the original transaction before the replacement is mined. This creates a window of indexer inconsistency where a marketplace might display an asset as sold to the victim while the blockchain confirms it to the attacker. Mitigation requires a multi-layered approach: implementing mempool monitoring to detect conflicting transactions, using mempoolfullrbf awareness in node configurations, designing trade protocols with absolute time-locks and anti-exfiltration signing, and ensuring indexers have robust reorg and replacement-handling logic. Chainscore Labs can conduct a comprehensive review of your trade protocol's fee-bumping attack surface, from PSBT construction to indexer state reconciliation.

MEMPOOL ATTACK SURFACE

Affected Actors and Systems

Marketplace Operators

Marketplaces are the primary target. Attackers monitor the mempool for profitable pending buy orders and use RBF to replace the buyer's transaction with a higher-fee version that redirects the asset to the attacker. The original buyer sees their transaction dropped; the seller receives payment but loses the asset to a third party.

Action items:

Implement mempool monitoring to detect replacement attempts on pending trades.
Enforce minimum confirmation thresholds before marking a trade as settled.
Use first-seen-safe transaction construction patterns that make RBF replacement economically unattractive.
Review order-matching logic to ensure it does not rely solely on mempool visibility for trade finality.

implementation-impact

MEMPOOL DEFENSE

Mitigation Strategies and Controls

Operational and architectural controls to protect pending Ordinals and Runes transactions from fee sniping and replacement cycling attacks.

Full-RBF Signaling and Transaction Pinning

Signal full Replace-By-Fee (RBF) on all marketplace and user transactions to maintain replacement control. For time-sensitive trades, use transaction pinning techniques—such as broadcasting a small, low-fee child transaction via CPFP—to make replacement economically unattractive. This forces an attacker to pay a significantly higher absolute fee to outbid the pinned package, raising the cost of sniping. Wallet and marketplace infrastructure must ensure their coin selection and fee-bumping logic correctly constructs and broadcasts these pinning transactions without accidentally spending inscribed satoshis or Runes-bearing UTXOs.

Mempool Monitoring and Anomaly Detection

Deploy a dedicated mempool monitoring service that watches for replacement transactions targeting your pending trades. Alert on any transaction that spends the same inputs as an outstanding marketplace order with a higher fee rate. Integrate this monitoring into the order-matching engine to automatically flag or cancel affected listings before the replacement confirms. Operators should monitor multiple mempool perspectives—different nodes may see different transaction sets due to relay policy variations—to avoid blind spots that attackers can exploit. Chainscore Labs can review your mempool monitoring architecture against known sniping patterns.

First-Seen-Safe Relay Policies

Configure Bitcoin node relay policies to reject or deprioritize replacements for transactions that have already been widely propagated. While not a complete defense—miners ultimately control inclusion—a first-seen-safe policy increases the chance that the original transaction reaches a miner before the replacement. Node operators should set mempoolfullrbf=0 and tune incrementalRelayFee to make replacement propagation more expensive. This is a defense-in-depth measure that complements, but does not replace, application-layer controls. Teams should verify their node configurations against current Bitcoin Core release defaults.

Direct Miner Submission and Accelerator Services

For high-value trades, bypass the public mempool entirely by submitting transactions directly to mining pools via their accelerator or private submission APIs. This prevents attackers from observing the transaction in the mempool and constructing a replacement. Evaluate the trust assumptions of each accelerator service—some require KYC or impose minimum fee thresholds. Integrate direct submission as a fallback path in your trading infrastructure for orders above a configurable value threshold. Ensure your PSBT construction is finalized before submission to prevent the service from modifying trade parameters.

Time-Locked PSBTs with Anti-Exfiltration

Construct Partially Signed Bitcoin Transactions with relative timelocks (nSequence) that prevent an attacker from broadcasting a replacement with a higher fee until a specified window has passed. Combine this with anti-exfiltration techniques that prevent a counterparty from extracting a complete signed transaction before the timelock expires. This gives the honest party a guaranteed window to confirm the trade at the agreed fee rate. Marketplace engineering teams should review their PSBT construction logic to ensure timelocks are correctly applied and that signature exfiltration vectors—such as incomplete input signing—are closed.

Fee Strategy and Replacement Cost Modeling

Model the economic cost of replacement for every pending trade and set initial fees high enough to make sniping unprofitable relative to the expected profit. This requires real-time fee market data and an understanding of the attacker's breakeven point—the difference between the trade price and the asset's market value. Implement dynamic fee bumping that automatically increases the fee via CPFP if a replacement is detected, up to a pre-calculated ceiling. Trading infrastructure teams should integrate fee strategy logic into their order placement and monitoring pipeline. Chainscore Labs can conduct a fee strategy review to calibrate your replacement cost model against current mempool conditions.

MEMPOOL ATTACK VECTORS ON PENDING TRADES

Risk Assessment Matrix

Evaluates the operational risks, affected actors, and required actions for fee sniping and replacement cycling attacks targeting unconfirmed Ordinals and Runes transactions.

Risk	Failure Mode	Severity	Affected Actors	Mitigation Action
Fee Sniping	Attacker monitors the mempool for a pending purchase transaction with a low fee and broadcasts a competing transaction with a higher fee, buying the asset instead.	High	Marketplace users, Marketplace operators, Trading bots	Implement RBF-aware transaction monitoring and alerting. Advise users to use sufficient fee rates or avoid RBF-enabled transactions for high-value purchases.
Replacement Cycling	Attacker continuously replaces a transaction with higher fees to keep it pinned in the mempool, preventing the original seller's cancelation or a buyer's purchase from confirming.	High	Sellers, Marketplace operators, Wallet developers	Review transaction construction to disincentivize cycling. Implement time-locked transaction logic where possible. Monitor for transactions stuck in prolonged mempool loops.
CPFP Fee Theft	Attacker uses Child-Pays-For-Parent to attach a high-fee child transaction to a victim's unconfirmed low-fee transaction, effectively stealing the UTXO by outbidding the original fee.	Critical	Buyers, Custodians, Exchange hot wallets	Enforce strict UTXO locking in wallet software. Never broadcast a transaction that spends an unconfirmed UTXO from an untrusted counterparty. Review coin selection algorithms.
Mempool Monitoring Blindness	Trading infrastructure lacks real-time mempool visibility, failing to detect a replacement or sniping attack against a pending trade until after confirmation.	High	Marketplace backends, Indexer operators, Trading infrastructure teams	Integrate a full-node mempool monitor with alerting for conflicting transactions. Do not rely solely on indexer APIs for transaction status during the pending phase.
RBF Opt-In Misconfiguration	A wallet or marketplace constructs a transaction without signaling RBF, leaving a user's stuck low-fee transaction with no way to increase the fee, while an attacker can still exploit CPFP.	Medium	Wallet developers, Marketplace UI teams, End users	Audit transaction construction logic to ensure RBF signaling is intentional and configurable. Educate users on the trade-offs between finality and fee bumping.
PSBT and RBF Interaction	A partially signed Bitcoin transaction (PSBT) is signed by the seller but not broadcast, allowing the buyer to modify the transaction fee and broadcast a version that gets sniped or cycled.	High	Marketplace security teams, OTC desks, Wallet developers	Review PSBT signing flows to ensure fee rates are locked or bounded before counterparty signing. Implement anti-exfiltration protocols for PSBTs.
Automated Bot Exploitation	Attackers deploy automated bots to scan the mempool for profitable Runes or Ordinals trades and programmatically execute sniping or cycling attacks at scale.	High	Marketplace operators, Protocol developers, Risk teams	Model attacker bot economics to set fee thresholds that make sniping unprofitable. Consider off-chain order books with batched settlement to obscure trade intent before broadcast.

MEMPOOL ATTACK RESPONSE

Detection and Remediation Checklist

A practical checklist for marketplace operators and trading infrastructure teams to detect, contain, and remediate fee sniping and replacement cycling attacks against pending Ordinals and Runes transactions.

What to check: Implement real-time mempool monitoring that flags any RBF (Replace-By-Fee) transaction that spends the same inputs as a known pending trade transaction but with a higher fee rate.

Why it matters: Fee sniping attacks work by observing a profitable pending trade in the mempool and broadcasting a replacement transaction that redirects the asset to the attacker's address while outbidding the original fee. Without active monitoring, the attack is only detected after confirmation.

Signal to confirm: A replacement transaction appears within seconds to minutes of the original trade broadcast, targets the same inscription or Runes UTXO, and sends it to an address not present in the original PSBT. The replacement will typically have a fee rate 10-50% higher than the original.

resource-links

CANONICAL SPECIFICATIONS AND OPERATOR REFERENCES

Source Resources

Use these sources to validate replacement policy, fee-bumping behavior, mempool observations, and Ordinals or Runes asset interpretation. Teams should test against the Bitcoin Core versions and indexer implementations they operate rather than treating mempool acceptance as a network-wide guarantee.

BIP 125: Opt-in Full Replace-by-Fee Signaling

BIP 125 documents the original opt-in RBF signaling and replacement rules used by Bitcoin Core policy. Marketplace and wallet teams should map these rules to every pending trade state, including whether the transaction or an unconfirmed ancestor signals replaceability, which transactions a replacement can evict, and how incremental fees affect acceptance. Do not assume that a signed or broadcast trade is immutable. Record input outpoints, sequence values, fee rate, ancestor set, and conflicting transaction IDs so monitoring can identify cancellation or replacement attempts before fulfillment logic releases an Ordinal, credits Runes, or marks an order final.

EXPLORE

Bitcoin Core Policy and Release Behavior

Bitcoin Core is the primary implementation reference for mempool admission, transaction replacement, ancestor and descendant limits, and relay behavior. Operators should review release notes and policy tests before node upgrades because local acceptance can change independently of Bitcoin consensus. Reproduce marketplace transaction graphs in a staging regtest environment, including conflicting spends, RBF replacements, CPFP children, package dependencies, and delayed parent propagation. Compare results across the node versions used by broadcasters, indexers, miners, and infrastructure providers. A transaction accepted by one node may be absent or rejected elsewhere, so pending-trade controls must not rely on a single mempool view.

EXPLORE

Bitcoin Optech: Replace-by-Fee

Bitcoin Optech maintains a technical RBF topic index covering policy changes, implementation discussions, and wallet considerations. Use it to track how replacement behavior has evolved beyond a static reading of BIP 125. Security and infrastructure teams should review referenced Bitcoin Core changes when defining alert thresholds or upgrade gates. For Ordinals and Runes trades, monitor any replacement that spends a listed asset outpoint, changes outputs, removes expected payments, or alters the transaction graph. Treat replacement detection as an incident signal requiring order invalidation and re-evaluation, not merely as a fee update.

EXPLORE

Bitcoin Optech: Child Pays for Parent

The CPFP topic index explains how a high-fee child can raise the effective mining incentive of an unconfirmed parent transaction. Builders should use this material to distinguish legitimate fee rescue from adversarial transaction-graph manipulation. Evaluate fees at the package level, track which party controls spendable parent outputs, and test whether an attacker can attach descendants that complicate replacement, consume policy limits, or create misleading confirmation expectations. Wallets should expose only explicitly authorized fee-bump paths; marketplaces should avoid assuming that the presence of a high-fee child guarantees timely confirmation or preserves the intended Ordinals or Runes transfer.

EXPLORE

Ord Indexer Reference Implementation

The ord repository is the principal implementation reference for Ordinals and Runes interpretation. Marketplace, custody, and exchange teams should use it to verify which outpoint contains an inscription or Runes balance before accepting, replacing, or fee-bumping a trade. Run regression tests that replay the original transaction, conflicting replacements, CPFP descendants, confirmations, and reorgs through the supported indexer version. Compare indexer state with Bitcoin Core rather than inferring asset ownership from transaction outputs alone. Pin and document the deployed ord release because interpretation changes can affect whether a replacement is classified as a cancellation, transfer, burn, or invalid trade.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

MEMPOOL ATTACK VECTORS

Frequently Asked Questions

Practical answers for marketplace operators, trading infrastructure teams, and wallet developers dealing with fee sniping and replacement cycling attacks against pending Ordinals and Runes transactions.

Fee sniping is a passive attack where an attacker monitors the mempool for profitable pending trades and broadcasts a competing transaction with a higher fee to capture the asset. The attacker does not interact with the victim's transaction directly.

Replacement cycling is an active attack that exploits Replace-By-Fee (RBF) signaling. The attacker broadcasts a transaction that conflicts with the victim's pending trade, then repeatedly replaces it with higher-fee versions to keep the victim's transaction pinned in the mempool. This can delay or prevent the victim's trade from confirming, allowing the attacker to manipulate outcomes.

Both attacks target the time window between transaction broadcast and confirmation. The key difference: sniping races to confirmation, while cycling aims to prevent confirmation.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Fee Sniping and Replacement Cycling Attacks on Pending Trades

Introduction

Quick Facts

Attack Mechanics and Technical Context

Affected Actors and Systems

Marketplace Operators

Mitigation Strategies and Controls

Full-RBF Signaling and Transaction Pinning

Mempool Monitoring and Anomaly Detection

First-Seen-Safe Relay Policies

Direct Miner Submission and Accelerator Services

Time-Locked PSBTs with Anti-Exfiltration

Fee Strategy and Replacement Cost Modeling

Risk Assessment Matrix

Detection and Remediation Checklist

Source Resources

BIP 125: Opt-in Full Replace-by-Fee Signaling

Bitcoin Core Policy and Release Behavior

Bitcoin Optech: Replace-by-Fee

Bitcoin Optech: Child Pays for Parent

Ord Indexer Reference Implementation

Looking to build on a specific blockchain?

Frequently Asked Questions

Delivering blockchain solutions for 5+ years.

How to get started?

Exploration & Strategy

Architecture & Design

Development & Integration

Security & Launch

Discover our blockchain development services.

DeFi Protocol Development

DEX & Exchange Development

Lending & Borrowing Platforms

Need a blockchain engineering team?

Discover our
blockchain development services.