In this paper, we introduce and implement BRC20 sniping attack. Our attack manipulates the BRC20 token transfers in open markets and disrupts the fairness among bidding participants. The long-standing principle of “highest bidder wins” is rendered ineffective.

Typically, open BRC20 token markets rely on Partially Signed Bitcoin Transactions (PSBT) to broadcast selling intents and wait for buying auctions. Our attack targets the BRC20 buying process (i.e., transfer) by injecting a front-running transaction to complete the full signature of the PSBT. At its core, the attack exploits the mempool’s fee-based transaction selection mechanism to snipe the victim transaction, replicate metadata, and front-run the legitimate transaction. This attack applies to platforms using PSBT for BRC20 token transfers, including popular Bitcoin exchanges and marketplaces (e.g., Magic Eden, Unisat, Gate.io, OKX).

We implemented and tested the attack on a Bitcoin testnet (regtest), validating its effectiveness through multiple experimental rounds. Results show that the attacker consistently replaces legitimate transactions by submitting higher-fee PSBTs. We have also made responsible disclosures to the mentioned exchanges.

1 INTRODUCTION

Since mid-2024, the Bitcoin network has witnessed\textsuperscript{[1]} a sharp rise in so-called mempool sniping, a fee-based form of transaction front-running that threatens to disrupt ordinary users’ ability to participate in Ordinals\textsuperscript{[2]} and BRC20 trading\textsuperscript{[3–8]}. At its core, mempool snipping relies on the attacker’s capacity to monitor unconfirmed transactions and outbid legitimate buyers by submitting higher-fee alternatives. No direct loss of funds is reported for users who experience this phenomenon, while the damage manifests in a degraded marketplace. Participants may be repeatedly outbid and ultimately deterred from engaging in token purchases.

According to data shared by community members, this practice is no longer a rare occurrence. The Wizards of Ord “Snipes” Discord channel\textsuperscript{[9]} recorded 220 daily snipes in one instance, amounting to 3.9 BTC (approximately $247,000), and similar activity levels have been reported consistently over the course of several weeks. High-profile figures have encountered similar setbacks. For instance, on July 10, an individual affiliated with the Bored Ape Yacht Club engaged in what community members termed a “sniping battle,” ultimately forfeiting over $5,800 in fees without succeeding in the attempted purchase of an Ape Hoodie Ordinal\textsuperscript{[10]}. Another indicative incident occurred during the highly anticipated OrdiBots mint\textsuperscript{[11]}, which had garnered substantial attention among Ordinals enthusiasts. The enthusiasm quickly soured when numerous participants experienced mempool sniping throughout the launch.

Despite widespread awareness of mempool sniping, the technical underpinnings of Ordinals and BRC20 transfers have yet to be fully examined in the context of fee-driven front-running. At the heart of these trading workflows lies the partially signed Bitcoin transaction (PSBT) mechanism, which enables sellers to broadcast sale data and buyers to finalize the purchase. This convenience, however, introduces an opening for adversaries to intercept, modify, or outbid legitimate transactions before they reach confirmation, a phenomenon we term the BRC20 snipping attack.

Evidence: A poll\textsuperscript{[12]} conducted by Magisat’s founder on June 12 revealed that, out of 229 respondents, 73% confirmed having been sniped at least once while attempting to secure Ordinal assets.

In this paper, we present a deep dive into how BRC20 token transfers via PSBT are susceptible to sniping.

① We conduct the first formal treatment of the PSBT-based BRC20 transfer process, which is the key process for building open marketplaces within the Bitcoin ecosystem.

BRC20 tokens, unlike Ethereum-based tokens\textsuperscript{[13–15]}, lack native smart contract support. Instead, BRC20s rely on Bitcoin’s UTXO (Unspent Transaction Output) model. This necessitates a structured transfer mechanism to handle token movements while preserving the system integrity. The PSBT standard (BIP-174\textsuperscript{[16]}) provides a means to separate transaction creation and signing across multiple parties, making it a cornerstone for implementing BRC20 token marketplaces. However, this introduces vulnerabilities as incomplete transactions are visible and manipulable before their finalization.

Our analysis formalizes the BRC20 transfer workflow through PSBT by decomposing its phases: seller initialization, buyer signing, and network broadcast. We introduce a mathematical model capturing the dependencies between transaction inputs, outputs, and the metadata inscribed in PSBTs. By detailing how token transfer inscriptions (e.g., JSON-based metadata) are integrated into the Bitcoin blockchain, we identify the system’s reliance on mempool transparency and fee-driven prioritization.

② We propose a new attack we term BRC20 snipping attack, where partial/incompleted PSBTs can be replicated with a higher fee, displacing legitimate transactions within the mempool from malicious buyers.

Our sniping attack exploits the transparent nature of the mempool and the predictable workflow of PSBT-based transactions. In our attack, the adversary monitors the mempool for unconfirmed BRC20 transactions, identifies partially signed PSBTs containing token transfer instructions, and crafts a competing transaction. By replicating the legitimate transaction’s core details and outbidding it with a higher fee, the attacker ensures their transaction is prioritized for block inclusion, effectively invalidating the original.

Our attack not only disrupts the fairness of BRC20 marketplaces but also undermines user confidence in their reliability. More importantly, the damage can amplify significantly as our attack is widely applicable (details in Table 2).

It is important to note that we do NOT claim novelty in the concept of mempool sniping, as extensively discussed in prior works. However, our study is the first to investigate the sniping attack specifically within the context of BRC20 token transfers and the PSBT protocol. The complexities introduced by these additional protocols pose greater analytical challenges compared to simpler mempool injection or traditional front-running attacks. Our attack, despite such complexity, demonstrates a fully operational implementation. For better understanding, we also summarize relevant (mempool) attack vectors in Table 1.

③ We implement and validate our attack in a controlled environment. We conduct a detailed local experiment that simulates real-world conditions of network congestion, fee competition, and opportunistic adversaries.

We developed a controlled environment using Bitcoin’s regtest mode. We emulate real-world scenarios, including mempool congestion, varying transaction fees, and adversarial behaviors. We created a local marketplace for BRC20 tokens and implemented the attack by crafting sniping transactions with varying fee levels.

Our experiments show that attackers with minimal resources can consistently outbid legitimate buyers, achieving block inclusion for their malicious transactions. We measured the success rate of the attack under different network conditions and fee strategies, confirming its reliability. Additionally, we tracked the impact on token balances, demonstrating how the attacker successfully redirected tokens to their control while rendering the legitimate transaction invalid. These findings validate the attack’s practicality.

④ We present our suggestion for mitigation.

We propose three mitigation strategies: (i) adding mempool protection, (ii) enabling dynamic fee escalation, and (iii) implementing a fee-locking mechanism. For instance, the advanced fee-locking mechanism embeds a maximum fee commitment within the PSBT, preventing attackers from arbitrarily escalating fees. This mechanism leverages cryptographic commitments to ensure that only transactions adhering to the agreed-upon fee structure are accepted by the network. We also explore the feasibility of integrating dynamic fee adjustments, where users can pre-authorize higher fees in case their initial transaction is outbid.

In short, our contributions are:

• formalisation for the PSBT-based BRC20 transfer process (§3);
• the new BRC20 sniping attack (§4, §6);
• implementation and validation of the attack (§5);
• mitigation strategies (§7).

Responsible disclosure. We have notified our attack findings to four leading BRC20 token platforms and marketplaces, i.e., Magic Eden, Unisat, Gate.io, OKX, which are potentially affected by this vulnerability.

2 TECHNICAL WARMUPS

Bitcoin’s UTXO. Bitcoin’s UTXO (Unspent Transaction Output) [42, 43] is a fundamental concept in its transaction model, representing outputs of transactions that have not yet been spent. Each UTXO is tied to a Bitcoin address and controlled by a private key, allowing the holder to spend it. UTXOs are indivisible, meaning they must be fully consumed in a transaction, with any leftover value returned as a new UTXO to the sender. The Bitcoin network maintains a global UTXO set, which tracks all unspent outputs and forms the basis for validating transactions. A transaction spends UTXOs as inputs and creates new UTXOs as outputs, ensuring a clear lineage for every Bitcoin. We present a formalized version in §3.

The UTXO model enhances security, efficiency, and transparency. UTXOs prevent double-spending since each can only be spent once and ensure traceability through their transactional history. Unlike the account model used in blockchains like Ethereum [44, 45], UTXOs eliminate the need to manage balances directly, instead relying on the creation and consumption of outputs.

Creating an inscription transaction involves two distinct phases [29, 46]:

• Commit transaction. This phase begins with the creation of a taproot output [47, 48] that cryptographically commits to a script referencing the inscription data. Importantly, this commitment is designed to reference the data without directly revealing its content, ensuring confidentiality until the appropriate stage. The commit transaction is then broadcast to the Bitcoin network, where it gets included in a block on the blockchain. This process securely anchors the commitment on-chain, forming the foundation for the subsequent phase.
• Reveal transaction. In this phase, the output from the commit transaction is spent in a new transaction known as the reveal transaction. This transaction includes the actual inscription data embedded within its script, fully disclosing the committed content. Once the reveal transaction is confirmed on the blockchain, the inscription data becomes permanently stored on-chain, ensuring public accessibility, verifiability, and immutability. This phase completes the inscription process, allowing the data to be associated with the Bitcoin network permanently.

BRC20. The BRC20 protocol [4, 5, 46] builds upon inscription technology to embed personalized content into each unique satoshi, the smallest unit of Bitcoin. The inscribed data is assigned a P2TR (Pay-to-Taproot) script type and stored within the SegWit witness section [49] of a transaction, ensuring compatibility with the Bitcoin network. Inscriptions can take diverse formats, including JSON-based text, images, audio, and even highly compressed video files. For text-based BRC20 tokens, such as ORDI [50], the on-chain inscription includes key details: the protocol name (brc20), operation type (e.g., transfer), token name (e.g., ordi), total token supply (max), maximum tokens minted per round (lim), and the quantity to be minted or transferred (amt). This structured approach ensures accurate and permanent recording of token metadata on-chain.

Table 1: Mempool-Related Attacks / Exploits

Aspect	Target	Objective	Key Exploit	Mechanism	Platform
Frontrunning [17–20]	Pending transactions	Displace transaction	Fee bidding	Fee escalation or reduction (backrunning)	EVM-compatible
MEV arbitrage [21–23]	Transaction orderings	Extract unfair value	Miner prioritization	Order manipulation/censorship	EVM-compatible
Sniping bots [24–26]	Token/NFT auctions	Capture mints	Gas auctions	Automated gas bidding in mints	EVM-compatible
Imitation attack [27]	Pending tx/contracts	Extract contract value	Contract cloning	Copy and frontrun (see above) contracts	EVM-compatible
RBF exploits [28–30]	Low-fee transactions	Accelerate confirmation	Fee prioritization	Replace transactions	Bitcoin (UTXO)
Tx malleability [31, 32]	Transaction IDs	Invalidate/hijack Tx	Signature alteration	Alter tx IDs before confirmation	Bitcoin (UTXO)
Pinning attacks [29, 30, 33]	Inscriptions/BRC20s	Drain out liquidity	Locking UTXOs	Fee escalation + full withdraw order	Bitcoin (UTXO)
Timejacking attack [34]	Node timestamps	Disrupt transaction order	False timestamp	Alter node time to influence validation	All blockchains
Double-spend [35–37]	UTXOs	Spend coins twice	Conflicting Tx/branch	Broadcast multiple tx with same inputs	All blockchains
DDoS [38–41]	Mempool capacity	Block valid tx propagation	Spam tx flooding	Overload mempool with low-priority tx	All blockchains
Ours	PSBT/Inscription/BRC20	Hijack token transfers	Metadata in PSBT	Fee escalation + PSBT metadata replication	Bitcoin (UTXO)

The protocol leverages Ordinal Theory [2], which functions as a numbering system to index every indivisible satoshi, enabling them to be uniquely tracked and transferred as individual entities. This indexing mechanism ensures that each satoshi carrying an inscription, such as BRC20 metadata, becomes non-fungible, effectively differentiating it from others. This contrasts with Ethereum, which inherently supports smart contracts for token creation and management, making the BRC20 protocol a distinct and innovative approach to tokenization within the Bitcoin ecosystem.

Transferring BRC20. BRC20 tokens lack built-in smart contracts and instead operate using Bitcoin’s UTXO model and transaction inscriptions. Inscriptions only store plaintext messages about BRC-20 actions, not executable logic. Real-time balance updates depend on off-chain indexers for data retrieval. We explain more below.

• On-chain storage. BRC-20 tokens are fully recorded on-chain, with their movements tied to Bitcoin’s native transactions. The Transfer operation corresponds to the sending and receiving of satoshis on the layer-one Bitcoin network. However, the Bitcoin network only logs transaction data, not the real-time status of BRC-20 tokens or balances. Unlike account-based systems, advanced features like balance tracking are offloaded to external layers, keeping the on-chain ledger lightweight and efficient.
• Off-chain retrievals. Off-chain indexers [46, 51] handle real-time data for BRC-20 tokens. These services track token minting, determine the cessation points, and map token trades to specific wallets. They only observe on-chain transactions without modifying them, ensuring data integrity. If an indexer fails, token data remains secure, as it can be reconstructed by reprocessing blockchain transactions. Many wallets, like Ordinals Wallet [52], UniSat [53], and Binance’s hot wallet [54], integrate indexer functionalities seamlessly for users.

3 FORMALISING BRC20 TRANSFER ON PSBT

3.1 Basics

Transaction model. In the Bitcoin network, transactions are the fundamental units that facilitate the transfer of value, operating under the UTXO model. A Bitcoin transaction ( \mathcal{T} ) can be formally defined as a tuple ( \mathcal{T} = (\text{txid}, \text{In}, \text{Out}, \text{Witness}) ), where:

[ \text{txid} = \mathcal{H}(\text{serialize}(\mathcal{T})) ]

( \mathcal{H} ) is a unique identifier for transactions, derived from the double SHA-256 hash function ( \mathcal{H} ) applied to the serialized transaction data.

( \text{In} = {I_1, I_2, \ldots, I_n} ) is the set of inputs. Each input ( I_i ) is a tuple: ( I_i = (\text{txid}^{(i)}, \text{vout}^{(i)}, \text{scriptSig}^{(i)}, \text{sequence}^{(i)}) ) where ( \text{txid}^{(i)} ) and ( \text{vout}^{(i)} ) reference the originating transaction and the specific output index being consumed, respectively. The ( \text{scriptSig}^{(i)} ) provides the necessary cryptographic proof to authorize the spending of the referenced UTXO. sequence ( \text{sequence}^{(i)} ) enables features such as Replace-By-Fee (RBF, to be explained soon) and facilitating relative lock-time constraints.

( \text{Out} = {O_1, O_2, \ldots, O_m} ) is the set of outputs. Each output ( O_j ) is defined as: ( O_j = (\text{amount}_j, \text{scriptPubKey}_j) ) where ( \text{amount}_j ) specifies the value being transferred, and ( \text{scriptPubKey}_j ) contains the locking script that sets the conditions under which the output can be spent in future transactions. There are several commonly used output types, including P2PKH (Pay-to-PubKey-Hash), P2SH (Pay-to-Script-Hash), P2WPKH (Pay-to-Witness-PubKey-Hash), P2WSH (Pay-to-Witness-Script-Hash), and P2TR (Pay-to-Taproot).

Witness is the data structure introduced by Segregated Witness (SegWit) to hold the unlocking data for witness-based outputs like P2WPKH, P2WSH, and also P2TR. Conceptually, the witness serves as the new location for the data that would otherwise appear in the scriptSig of legacy transactions. Unlike scriptSig, the witness section does not employ Bitcoin script opcodes directly; rather, it is composed solely of data pushes. Each data push corresponds to a piece of unlocking data (e.g., signatures, public keys, or entire witness scripts) required to satisfy the output’s conditions.

UTXO. The UTXO set ( \mathcal{U} ) is a finite collection of all unspent outputs ( (\text{txid}, \text{vout}, \text{amount}, \text{scriptPubKey}) ). The state transition equation below illustrates how ( \mathcal{U} ) evolves with each transaction ( \mathcal{T} ).

[ \mathcal{U}’ = \mathcal{U} \cup \left{ \left( \text{txid}^{(i)}, \text{vout}^{(i)} \right) \mid I_i \in \text{In} \right} \ \cup \left{ \left( \text{txid}, j, \text{amount}_j, \text{scriptPubKey}_j \right) \mid O_j \in \text{Out} \right} ]

When a transaction ( \mathcal{T} ) is processed, it consumes specific UTXOs referenced by its inputs ( \text{In} ). These consumed UTXOs are removed from the current UTXO set ( \mathcal{U} ). Simultaneously, the transaction generates new UTXOs through its outputs ( \text{Out} ). These new UTXOs are added to form the updated UTXO set ( \mathcal{U}’ ).

3.2 Transaction Replacement

Transaction Fee. Transaction fees serve as an incentive for miners to include transactions in the next block and act as a mechanism to prevent network abuse by adding a small cost to each transaction. The transaction fee ( f ) is determined by the difference between the input and output values, which can be calculated as:

[ f = \sum_{i=1}^{n} \text{amount}(I_i) – \sum_{j=1}^{m} \text{amount}(O_j). ]

Miners collect this difference as compensation for processing the transaction and securing the network. The fee is typically measured in satoshis per byte (sat/byte), and the exact fee needed for a transaction depends on network congestion and competition for block space at the time. Fig. 6 depicts the average Bitcoin transaction fee in USD (left y-axis) and the number of Bitcoin transactions per day (right y-axis) over time, spanning from January 2022 to October 2024. The transaction fee remained relatively low and stable, fluctuating around $20 until early 2023. After this point, there was a noticeable increase in volatility, with transaction fees spiking multiple times, reaching above $120 at several points in 2024. The creation of the BRC20 standard and the Bitcoin halving event appear to be associated with a significant spike in both the average transaction fee and the number of transactions.

Transaction replacement. The transaction replacement mechanism allows users to replace an unconfirmed transaction (i.e., ( T )) with a new one (i.e., ( T’ )) that offers a higher fee. It mandates that the input sets remain identical, ( \text{In}’ = \text{In} ), ensuring that both transactions consume the exact same UTXOs from the current UTXO set ( U ). However, the outputs ( \text{Out}’ ) in ( T’ ) are required to differ from those in ( T ). Specifically, ( T’ ) typically lowers the output amounts to assign a higher transaction fee, which can be mathematically expressed as:

[ \sum_{j=1}^{m’} \text{amount}(O’{j}) < \sum{j=1}^{m} \text{amount}(O_{j}), ]

where ( m ) and ( m’ ) denote the number of outputs in ( T ) and ( T’ ), respectively. The increased fee ( f’ = \sum_{i=1}^{n} \text{amount}(I_i) – \sum_{j=1}^{m’} \text{amount}(O’_{j}) ) in ( T’ ) serves as an incentive for miners to prioritize the replacement transaction over the original one.

Example: The Bitcoin history (cf. link) shows that a transaction (i.e., txid.fc7c) was replaced with a new transaction (i.e., txid.e744) with a fee rate of 12.8 sat/vB, higher than the initial 9.04 sat/vB.

3.3 PSBT Protocol

PSBT. PSBT, short for partially signed Bitcoin transactions, is a Bitcoin standard (BIP-174 [16]) for Bitcoin transactions designed to separate the construction and signing processes. Formally, a PSBT can be represented as a tuple ( \mathcal{P} = (T, \text{In}{\text{PSBT}}, \text{Out}{\text{PSBT}}) ), where ( T ) denotes the underlying Bitcoin transaction ( T = (\text{txid}, \text{In}, \text{Out}, \text{Witness}) ), and ( \text{In}{\text{PSBT}} ) and ( \text{Out}{\text{PSBT}} ) encapsulate the additional metadata required for partially signing the transaction.

Each input ( I_i \in \text{In} ) within the transaction ( T ) corresponds to an input in ( \text{In}_{\text{PSBT}} ), augmented with supplementary information such as the full UTXO details ( (\text{txid}^{(i)}, \text{vout}^{(i)}, \text{amount}^{(i)}, \text{scriptPubKey}^{(i)}) ), the non-witness UTXO if applicable, and any partial signatures ( \sigma^{(i)} ).

Mathematically, the PSBT input can be denoted as:

[ I^\text{PSBT}_i = (I_i, \text{UTXO}^{(i)}, \sigma^{(i)}) ]

where UTXO(^{\text{UTXO}}) provides the necessary context for signing, and ( \sigma^{(i)} ) is the partial signature obtained from one or more signers.

Similarly, each output ( O_j \in \text{Out} ) is associated with ( \text{Out}_{\text{PSBT}} ), which may include additional information such as the redeem script or witness script required for spending conditions. This can be expressed as:

[ O^\text{PSBT}_j = (O_j, \text{RedeemScript}_j) ]

ensuring that all participants have access to the necessary scripts to validate and sign the transaction.

The PSBT protocol operates through a series of stages:

• Creation: An initial PSBT is generated, containing the transaction structure ( T ), the input references ( \text{In}{\text{PSBT}} ), and the output definitions ( \text{Out}{\text{PSBT}} ). At this stage, the PSBT includes all the information required to fully construct the transaction, except for the signatures.
• Signature propagation: The PSBT is shared among the involved multiple signers. Each participant reviews the PSBT, adds their partial signatures ( \sigma^{(i)} ), and updates the PSBT accordingly. This process can be iterated until all signatures are collected.
• Finalization: Once all required signatures are present, the PSBT is finalized by embedding the complete signature data into the transaction ( T ), producing the fully signed transaction ( T’ ). ( T’ ) then is serialized and broadcasted to the Bitcoin network for inclusion in a block.

Formally, the transformation from a partially signed PSBT ( \mathcal{P} ) to a fully signed transaction ( T’ ) can be depicted as:

[ T’ = \text{Finalize}(\mathcal{P}) ]

where the ( \text{Finalize} ) function aggregates all partial signatures ( \sigma^{(i)} ) and integrates them into the corresponding inputs of ( T’ ), resulting in a valid and broadcast-ready transaction ( T’ ).

3.4 BRC20 Transfer via PSBT

Building upon the standards of BRC20 and PSBT, we formalize the lifecycle of a PSBT-based BRC20 transfer. Let

[ \Omega = {p, \text{op}, \text{tick}, \text{amt}} ]

denote the core inscription metadata that specifies the protocol name (( p = \text{brc-20} )), the operation type (( \text{op} )), the token name (( \text{tick} )), and the transfer amount (( \text{amt} )). In particular, for a transfer operation, we might have:

[ \Omega = {p : \text{brc-20}, \text{op} : \text{transfer}, \text{tick} : \text{ordi}, \text{amt} : 1000} ]

• Seller’s operation: A seller begins by inscribing a satoshi with metadata ( \Omega ) that encodes the intention to transfer ( \text{amt} = 1000 ) BRC20 ( \mathcal{B} ) (e.g., ( \text{tick} = \text{ordi} )). Formally, we can regard this inscription event as creating a tuple

[ \mathcal{I} = (\text{txid}_s, \text{vout}_s, \Omega) ]

where ( \text{txid}_s ) and ( \text{vout}_s ) identify the unspent output hosting the inscribed satoshi. The existence of ( I ) indicates the seller’s willingness to exchange these tokens for a certain Bitcoin amount (e.g., ( 0.2 \mathcal{B} )).

• Creation of PSBT. Next, the seller assembles a partially signed transaction ( \mathcal{P} ) that integrates ( I ) as one of the inputs. Concretely, the seller designates an output ( O_s = (0.2 \mathcal{B}, \text{scriptPubKey}_s) ) to reflect the requested price. In other words, by offering an output crediting ( 0.2 \mathcal{B} ) to one of the seller’s addresses, the seller stipulates that any buyer must fund this output in exchange for the ( \text{amt} = 1000 \mathcal{B} ) inscribed on the satoshi from ( \text{txid}_s, \text{vout}_s ). The rest of the transaction structure (including any change outputs to the buyer or additional witness fields referencing ( \Omega )) is specified but not fully signed.
• Publishing the PSBT. The seller then publishes ( \mathcal{P} ) to a marketplace or similar off-chain platform, making it visible to prospective buyers. The marketplace now holds a partially signed transaction ( \mathcal{T} = \mathcal{P}(\text{In}{\text{mkt}}, \text{Out}{\text{mkt}}) ), which includes the vital metadata ( \Omega ) describing the token type and amount. At this stage, no complete signature for the spending input ( I ) is present, or only a partial signature belonging to the seller exists (depending on multi-sig policies).
• Buyer’s operation. A buyer who wishes to acquire 1000 ( \mathcal{B} ) must finalize ( \mathcal{P} ) by providing the necessary 0.2 ( \mathcal{B} ) input(s) to the transaction and appending their own signatures. Suppose the buyer’s contribution is a UTXO ( (\text{txid}_b, \text{vout}_b, \text{amount}_b) ) such that ( \text{amount}b \geq 0.2 \mathcal{B} ). The buyer modifies ( \text{In}{\text{PSBT}} \cup { (\text{txid}_b, \text{vout}_b) } ) to incorporate this new input, ensuring the resulting transaction covers the required payment to ( \text{scriptPubKey}_s ). The buyer then attaches any partial signatures ( \sigma_b ) necessary to authorize the spending of ( (\text{txid}_s, \text{vout}_s) ).
• Finalizing the PSBT. When all inputs are properly signed—i.e., the seller’s signature on ( (\text{txid}_s, \text{vout}_s) ) plus the buyer’s signature on ( (\text{txid}_b, \text{vout}_b) )—the PSBT is transformed into a valid raw transaction. One may express this as ( \mathcal{T}’ = \text{Finalize}(\mathcal{P}) ), where ( \mathcal{T}’ ) denotes the fully signed Bitcoin transaction. Once the buyer broadcasts ( \mathcal{T}’ ) to the network, nodes incorporate it into the mempool and, upon successful validation and block inclusion, the transaction becomes irrevocable.
• Off-chain state updates. Subsequent to on-chain confirmation, off-chain ledgers or token-management layers update the final token states ( S ). Let [ \begin{align*} S_{\text{buyer}} &\leftarrow S_{\text{buyer}} + 1000 \mathcal{B}, \ S_{\text{seller}} &\leftarrow S_{\text{seller}} – 1000 \mathcal{B}, \end{align*} ]

denote the change in on-chain balance, assuming an off-chain indexer or marketplace logic tracks the BRC20 token state. At the same time, the seller’s on-chain balance increases by 0.2 ( \mathcal{B} ), while the buyer’s on-chain balance decreases accordingly. In other words, the cryptographic settlement on Bitcoin triggers an atomic exchange of the BRC20 tokens for ( \mathcal{BTC} ), ensuring ( \mathcal{T}’ ) captures the binding transaction logic.

It is worth noting that the protocol necessitates two on-chain transactions to finalize the \texttt{Transfer} operation. The first transaction is to signify the action, while the second is an actual transaction on-chain (detailed mechanism refers to [29]). Our attack focuses on the second transaction.

4 BRC20 SNIPPING ATTACK

We present a vulnerability tied to the way BRC20 transactions are published using PSBT, termed BRC20 snipping attack.

4.1 Attack Description

A snipping attack in the context of BRC20 tokens on Bitcoin is a focused form of fee-driven front-running that targets a PSBT before it is fully confirmed. Its defining feature involves intercepting the partially signed data and crafting a competing transaction that replicates the essential transfer details. Unlike standard front-running methods, which typically exploit fee escalations, a snipping attack seizes upon the unique conditions of partially signed workflows. By broadcasting a version of the transaction with a higher fee than the legitimate proposal, the attacker ensures that miners will prioritize the malicious transaction, thus rendering the original transaction invalid or unconfirmable.

4.2 Motivation

The snipping attack typically manifests in a marketplace environment where BRC20 tokens are traded using partially signed transactions. In such a setting, sellers initiate token transfers by creating PSBTs that outline the details of the transaction, including the amount of tokens to be transferred and the associated Bitcoin inputs and outputs. These PSBTs are often shared among multiple participants, such as buyers, sellers, and possibly escrow services, to gather the necessary signatures before the transaction is finalized and broadcasted to the network. This collaborative workflow, while facilitating multi-party authorization, inadvertently exposes the PSBT to potential interception by malicious actors.

Within this context, multiple buyers may concurrently compete to finalize a token transfer, each aiming to have their transaction confirmed promptly to secure the desired tokens. The motivations driving an attacker to execute such an attack are multifaceted.

• The attacker seeks financial gain by redirecting valuable BRC20 tokens to their own address, stealing assets intended for legitimate buyers.
• By invalidating the original transaction, the attacker can cause a denial of service, disrupting the intended transfer and potentially causing economic losses for both buyers and sellers.
• The attacker may also aim to manipulate the market by affecting token prices or eroding buyer trust. Repeated successful snipping attacks can lead to a loss of confidence in the marketplace and destabilize the overall BRC20 token economy.

4.3 Attack Methodology

Fig.2 and the steps below illustrate how an attacker with minimal access can exploit PSBT transactions. The workflow assumes that…

the attacker can observe or intercept the PSBT metadata and that they possess UTXOs sufficient to cover the total requested output value plus a higher fee.

A crucial element of this strategy is timing. The attacker must insert the malicious transaction into the mempool while the legitimate one remains unconfirmed. The attacker’s high-fee option prompts miners to drop or invalidate the original partial transaction due to conflicting inputs. Additionally, by retaining the core BRC20 inscription data, the attacker ensures that the on-chain record still recognizes the same token transfer parameters, allowing them to channel the tokens to an address of their choosing.

Step 1: Intercept the legitimate PSBT. By observing unconfirmed BRC20 transactions (often embedding JSON-like data within the witness field) in the mempool, the attacker is able to identify the legitimate buyer’s pending PSBT $P$.

Step 2: Parse BRC20 transfer details. Extract essential fields from $P$:

1. The spending inputs: ${(\text{txid}^{(i)}, \text{vout}^{(i)})}$;
2. The receiving address(es) and amounts for the BRC20 context, e.g., $p : \text{brc20}$, $\text{op} : \text{transfer}$, $\text{tick}$, $\text{amt}$, …;
3. The on-chain fee estimate $f_{\text{legit}}$ if deducible from the input-output difference.

Step 3: Construct the malicious transaction. Using attacker-owned UTXOs $A$, prepare a new PSBT $P_{\text{atk}}$ structure referencing equivalent BRC20 metadata. Let

$$P_{\text{atk}} = (\text{In}{\text{atk}}, \text{Out}{\text{atk}}, \text{Witness}_{\text{atk}}).$$

1. Copy the core inscription data (e.g., $\text{tick}$, $\text{amt}$, $\text{op}$) to maintain validity for the same BRC20 token;
2. Allocate outputs so that at least one matches the seller’s address and amount (if the aim is to mimic the buyer’s payment);
3. Reserve minimal change for the attacker’s address, ensuring a higher fee $f_{\text{atk}} > f_{\text{legit}}$.

Step 4: Sign and finalize. Use the attacker’s private key(s) to sign $P_{\text{atk}}$ fully. Ensure the transaction meets all constraints (e.g., scriptPubKey validations, input availability). Once signed,

$$T_{\text{atk}} \leftarrow \text{finalizePSBT}(P_{\text{atk}}).$$

Step 5: Broadcast malicious transaction. Send $T_{\text{atk}}$ to the mempool before the legitimate PSBT is confirmed. If the fee surpasses the original transaction’s fee, miners will likely prioritize $T_{\text{atk}}$ over the legitimate one.

Step 6: Observe mempool and block inclusion. Monitor the Bitcoin mempool for confirmation. If $T_{\text{atk}}$ is included in the next block, the legitimate transaction becomes invalid due to input conflicts, causing it to be removed from the mempool.

5 LOCAL EXPERIMENT

5.1 Experimental Setup

Hardware setup. The experiment was conducted on a desktop computer equipped with an Intel Core i7-9700K processor running at 3.60 GHz, 32 GB of DDR4 RAM, and a 1 TB NVMe SSD. The operating system used was Ubuntu 20.04 LTS.

Software setup. The core of our experimental setup relied on Bitcoin Core version 26.0, configured to operate in Regtest mode. Regtest provides a private Bitcoin environment that allows for rapid block generation and fine-grained control over network conditions, making it ideal for testing purposes. Specifically, we initiated a Bitcoin Core node, configured with the following parameters: -regtest to enable Regtest mode and -txindex=1 to maintain a complete transaction index.

We utilized Bitcoin Core’s built-in PSBT functionalities (e.g., createpsbt, finalizepsbt, etc.) to manage the creation and signing of BRC20 token transactions. Furthermore, we implemented the BRC20 protocol by building upon the existing open-source Oridinal [52] project. To achieve accurate and real-time tracking of BRC20 token states, we deployed locally running indexing services (writing in Python scripts) that parse and monitor the JSON-based inscriptions embedded within transaction witness fields.

5.2 Threat Model

In our local experiment, we assume the attacker can monitor or obtain transaction data in the following ways:

• Access to PSBT: The attacker is able to observe or intercept PSBTs before they are fully signed and broadcast. Such interception could occur through compromised communication channels (e.g., local file sharing).
• Mempool visibility: For already completed PSBT transactions, the attacker can inspect the local mempool. This visibility allows the attacker to detect any transaction referencing the same UTXOs. In a real-world scenario, similar transparency might arise from a public Bitcoin data explorer (i.e., mempool.space [55]).

Additionally, we also assume that the attacker controls at least one UTXO with enough bitcoin to create a higher-fee transaction than legitimate buyers. If the attacker needs to complete a partial signature, they can also generate the necessary private keys for their own transaction inputs.

Algorithm 1 BRC20 Snipping Attack Methodology

Global Parameters:

• (I_{buyer}, I_{atk}), Attacker’s fee rate (f_{atk}), Buyer’s fee rate (f_{buyer}), Mempool (C_m).

1. Step-1: Attacker monitors the mempool.
2. Attacker (A) monitors mempool for unconfirmed BRC20 transactions.
3. Attacker observes PSBT (P) with input (I_{buyer} = (txid, vout)) and output (O_0 = (0.5B, \text{scriptPubKey})).
4. Attacker identifies fee rate (f_{buyer}) associated with the transaction.
5. Step-2: Attacker creates sniping PSBT.
6. Attacker (A) prepares sniping transaction (P_{atk}) targeting (I_{buyer}).
7. Attacker uses their own UTXO (I_{atk} = (txid_{atk}, vout_{atk})) as input to match (I_{buyer}).
8. Attacker sets a higher fee (f_{atk} = 0.28125B > f_{buyer} = 0.27985B).
9. Create sniping output (O_{atk} = (0.5B, \text{scriptPubKey}_1)), ensuring the payment goes to the seller’s address.
10. Add additional change output to attacker’s address (O_{change} = (0.00005B, A_{\text{addr}})).
11. Broadcast (P_{atk}) to mempool.
12. Step-3: Mempool conflict resolution.
13. Mempool processes (P_{atk}) and compares fee rates.
14. if Attacker’s fee (f_{atk} > f_{buyer}) then
15. (T_{atk}) is prioritized for inclusion in the next block.
16. Legitimate transaction (T_{buyer}) is invalidated due to input conflict and removed from mempool.
17. else
18. Transaction not included due to low fee.
19. end if
20. Step-4: Verify Attack Success.
21. Attacker’s wallet ((A_{\text{addr}})) should now hold the BRC20 tokens transferred through the sniping attack.
22. Confirm the amount of ak47 tokens in (A_{\text{addr}}) matches the amount originally inscribed in (I_{buyer}).
23. Confirm that (T_{buyer}) is no longer valid in the mempool.

5.3 Attack Strategy

Attack goal. The attacker’s primary goal in our local experiment is to hijack an in-progress BRC20 token transfer by exploiting vulnerabilities in the PSBT workflow. In other words, the attacker invalidates or preempts the original transaction, “snipping” the intended BRC20 token transfer.

Attack method. Shown in Algorithm 1, to execute the attack, the attacker first observes the PSBT by monitoring mempool. Because the local node logs incomplete PSBT data or temporarily loads it into memory while awaiting additional signatures, the attacker can parse those logs or memory dumps. Next, they modify the transaction metadata (e.g., UTXO information and output address), most critically, increasing the miner fee (i.e., decreasing the change sent back to the sender) beyond what the legitimate sender has offered. The attacker then completes partial signatures to render the malicious transaction valid. Finally, they re-broadcast this high-fee variant to the local mempool, where the node’s incentive mechanism causes mining simulators in the regtest environment to prioritize it over the legitimate transaction.

Success Criteria. We deem the snipping attack successful if the attacker’s malicious transaction both confirms before (and thereby invalidates) the legitimate transaction and delivers the targeted BRC20 tokens to the attacker’s control.

Concretely, two conditions must be met:

• Block inclusion. The manipulated transaction authored by the attacker is accepted in a newly mined block prior to the genuine transaction, causing the genuine transaction to remain unconfirmed or be evicted from the mempool due to input conflicts.
• Token receipt. Upon confirmation of the attacker’s transaction, a query to local indexers indicates that the BRC20 tokens, originally intended for the legitimate buyer, have been credited to an address controlled by the attacker. Verifying an increase in the attacker’s token balance confirms the successful appropriation of the asset.

5.4 Execution of the Attack

Seller address setup. To initiate our experiment, we first created a seller wallet and an address within the bitcoind-regtest network, specifically adr.0dd8. We then used the built-in mining functions in regtest mode to generate blocks, designating the newly created address to receive the corresponding block rewards. After the mining stage, a balance check on the seller’s wallet confirmed that it held exactly 1.5625(B), which would serve as the principal for creating and issuing BRC20 tokens, as well as covering transaction fees.

Token deploy and mint. We used the same seller address to mint a BRC20 token on the regtest network. Following the BRC20 protocol, we prepared a JSON-based inscription containing the necessary parameters: {p : brc20; op : deploy; tick : ak47; max : 2100000; lim : 1000}. This metadata was then serialized into hexadecimal form, yielding hex.307d.

Subsequently, we constructed a raw transaction on our regtest network using the createrawtransaction command, consuming the output from a prior transaction (txid.240c) as input, and specifying the hexadecimal-encoded inscription (hex.307d) as the “data” in the transaction output. After finalizing and signing the transaction with our seller wallet, we broadcast it to the local network and mined a new block to confirm it. The transaction was successfully included in block.a2e2, marking the on-chain deployment of the BRC20 ak47.

In our local regtest environment, BRC20 tokens default to belonging to the deployer’s address once the “deploy” transaction confirms. Consequently, the seller’s wallet automatically acquired a total of 21,000,000 ak47 (B) without requiring a separate mint operation.

Token transfer via PSBT. To initiate a subsequent transfer, the seller prepared a JSON inscription reflecting the transfer operation: {p : brc20; op : transfer; tick : ak47; amt : 1000}. Converting this metadata to a hexadecimal string yielded: hex.227d.

Using the createpsbt function, the seller constructed a new partially signed transaction. The relevant input referenced a previous transaction output (txid: tx.641d, vout: 0) held by the seller, while the output was defined to include the transfer inscription in its “data” field. Executing createpsbt produced the following PSBT string: psbt.r85P.

Next, we used walletprocesspsbt to sign this PSBT. However, as only one signature was provided and the PSBT did not yet meet all necessary signing requirements for a complete transaction, the walletprocesspsbt result indicated “complete”: false. This status signifies that, under our experimental setup, additional signatures would be needed before broadcasting the final transaction.

Buyer & attacker addresses setup. We introduced three additional addresses to represent potential buyers and attackers. The ordinary buyer’s address was set to adr.qa8r, while two attacker addresses, adr.v6r9 and adr.xffg, were designated to simulate different fee-bidding strategies. Specifically, one attacker was intended to surpass the ordinary buyer’s fee, while the other remained lower, helping us observe various outcomes in our snipping experiments.

Buyer signs PSBT. First, we assumed that the ordinary buyer discovered the seller’s partially signed BRC20 transaction. From the buyer’s perspective, the crucial element of interest was the transaction’s data field, which encodes the BRC20 transfer details in hexadecimal format. Using these details, the buyer constructed a new and fully formed PSBT with the following command (simplified for illustration):

1 bitcoin-cli -regtest createpsbt
2 "{"txid": "6e491e4928d9b6af81b0ebd5040e1a44834f2576e1085ecb79d5fdcd4fb2ea", "vout": 0}"
3 '{
4   "bcrt1qckuparv08nadxadvxgl0m0fmsn0ym6xfq0dd8": 0.5,
5   "bcrt1qackm4gsk5szqymyrl0k5fq2n6v9juzg4473qaz8r": 0.1,
6   "data": "7b22703a226272632d3230222c226f70223a227472616e73666572222c227469636b223a22616b3437222c22616d74223a2231303030227d",
7 }
8 '}
9 ```

Listing 1: Constructing a new PSBT from buyer’s view

In this command:
- tx.b2ea (vout=0) is the UTXO the buyer intends to spend (with the amount of 0.87985 $B$).
- adr.0dd8 (the seller’s address) is allocated 0.5 $B$.
- adr.qa8r (the buyer’s address) is allocated 0.1 $B$.
- The data field includes the hexadecimal-encoded BRC20 transfer instruction, representing the inscription {p : brc20; op : transfer; tick : ak47; amt : 1000}.

The input UTXO provides 0.87985 $B$, in total, while the outputs allocate 0.5 $B$ and 0.1 $B$, respectively. According to Formula 1, the resulting fee $F$ is:

$$ F_B = 0.87985 - (0.5 \times 0.1 - 0.27985) = 0.27985 \times B. $$

After creating this new PSBT, the bitcoin-cli command returned a base64-encoded string (psbt.+Gqbt) indicating the partially constructed transaction. The buyer used the walletprocesspsbt command to sign this PSBT with their private key, returning hexadecimal-encoded transaction data (hex.e140). A response looks like:

1 { 2 “psbt”: “e0491e4928d9b6af81b0ebd5040e1a44834f2576e1085ecb79d5fdcd4fb2ea”, 3 “complete”: true, 4 “hex”: “02000000000101eb2fbc4ddf59db7ec85106e57f23448ade10…8200000000” 5 } 6 “`

Listing 2: Buyer-signed PSBT Example

“complete”: true now indicates the transaction has all required signatures for this scenario, meaning it can be broadcast and confirmed without additional inputs.

Broadcast the completed PSBT. The final step is to broadcast the fully signed transaction to the local regtest network. Having obtained the hex-encoded transaction data (hex.e140) from the completed PSBT, the buyer invokes the sendrawtransaction command, supplying the raw transaction in hexadecimal form and returning a transaction id txid.c936. This submission passes the transaction into the local node’s mempool for validation. Once validated, the node broadcasts the transaction to the rest of the regtest environment, enabling block producers to mine it. Under non-adversarial circumstances, this broadcasted transaction would then be included in a newly mined block, completing the token transfer from the seller to the buyer. However, in our subsequent snipping attack experiments, the attacker will attempt to outbid this transaction, thereby invalidating the transfer.

Adversarial buyers (attackers) snip PSBT. In our experimental setup, the attacker aims to invalidate the buyer’s PSBT by crafting and broadcasting an alternative PSBT with a higher fee. Two attacker addresses were introduced to conduct a comparative experiment: one attempting to outbid the ordinary buyer’s fee, and the other offering a lower fee to illustrate a failed snipping attempt.

(1) Snipping with a higher fee. The attacker’s address (adr.v6r9) had a UTXO valued at 0.7813 $B$. This UTXO provides enough funds to both pay the seller the same amount (0.5 $B$) that the buyer intended to pay, and simultaneously offer a fee slightly exceeding the legitimate transaction fee of 0.27985 $B$. By allocating only 0.00005 $B$ back to the attacker’s own address, the resulting fee is calculated to be 0.28125 $B$, ensuring that this snipping transaction becomes more appealing to local miners or block producers on regtest.

$$ F_B = 0.7813 – (0.5 \times 0.00005) = 0.28125 \times B. $$

The attacker mirrors the buyer’s steps of using createpsbt but replaces the inputs and outputs with their own addresses and amounts. In particular, they preserve the essential details that must remain consistent—namely sending 0.5 $B$ to the seller’s address (adr.0dd8) and embedding the same BRC20 transaction inscription in the data field. An invocation is shown below:

1 bitcoin-cli -regtest createpsbt 2 &quot;{&quot;txid&quot;: &quot;6e491e4928d9b6af81b0ebd5040e1a44834f2576e1085ecb79d5fdcd4fb2ea&quot;, &quot;vout&quot;: 0}&quot; 3 e1085ecb79d5fdcd4fb2ea&quot;, 4 &#39;{ 5 &quot;bcrt1qkckuparv08nadxadvxgl0m0fmsn0ym6xfq0dd8&quot;: 0.5, 6 &quot;bcrt1qtpq478leuks3wcg9zgr7rqhz6enszpsmt7v6r9&quot;: 0.00005, 7 &quot;data&quot;: &quot;7b22703a226272632d3230222c226f70223a227472616e73666572222c227469636b223a22616b3437222c22616d74223a2231303030227d&quot;, 8 } 9 &#39;} 10 “` Listing 3: Constructing the Attacker’s PSBT with a Higher Fee This step yields a base64-encoded PSBT string (psbt.UBqV). The attacker proceeds to sign this PSBT (through walletprocesspsbt). A successful signature produces a valid, fully signed transaction in hexadecimal form (hex.ec85).

Finally, the attacker issues sendrawtransaction to broadcast this signed raw transaction to the local regtest mempool. Upon success, the node returns a txid txid.f0bb.

(2) Snipping with a lower fee. In a parallel experiment, we tested a scenario in which the attacker attempts to front-run the buyer’s transaction but uses a notably lower fee than the buyer. This second attacker address, here referred to as adr.xffg, holds a UTXO worth 0.700001 B. Following the same basic approach, the attacker preserves the essential fields from the original transfer transaction—namely sending 0.5 B to the seller’s address adr.0dd8 and embedding the identical BRC20 transfer inscription in the data field. However, they allocate 0.2 B as change to their own address adr.xffg, leaving a transaction fee of only 0.000001 B. This amount is far below the ordinary buyer’s fee.

[ F_l = 0.700001 \text{ B} – (0.5 \text{ B} + 0.2 \text{ B}) = 0.000001 \text{ B}. ]

The attacker constructs this low-fee transaction by issuing:

1 bitcoin-cli -regtest createpsbt
2 '[[ { "txid": "6ec491e4928d9b6af81b0ebd5040e1a44834f2576e1085ecb79d5fdde4fb2ea", "vout": 0 } ]]
3 [
4  { "btcrt1qkcuparv0dnxadvzxl0m0fmsn0ym6xfq0dd8": 0.5 },
5  { "btcrt1que4tw5xwxw236yuw8zyuw83r36dtnztswxfg": 0.2 },
6  {
7   "data": "7b22703a226272632d3230222c226f70223a227472616e73666572222c227469636b223a22616b3437222c22616d74223a2231303030227d"
8  }
9 ]'
10

Listing 4: Constructing the Attacker’s PSBT with a Lower Fee

Subsequently, the attacker signs the returned PSBT to generate a fully signed transaction in hexadecimal form and broadcasts this signed transaction, returning a transaction ID (txid.2323).

Mempool observation. Following the attacker’s snipping attempts, we inspected the local mempool using the command bitcoin-cli -regtest getrawmempool. As expected, we discovered three unconfirmed transactions residing in the mempool: the legitimate PSBT transaction broadcast by the ordinary buyer, and the two malicious PSBT transactions issued by the attacker.

Specifically, the mempool listing presents the chronological order of transaction submission. The Ordinary buyer’s transaction (txid.c936) is encountered first, immediately followed by the high-fee attacker transaction (txid.f0bb), and culminating with the low-fee attacker transaction (txid.2323).

Validation of the snipping attack. To ascertain whether the attacker’s snipping attempt succeeded, we proceeded to mine a new block in our local regtest environment by issuing:

1 bitcoin-cli -regtest generatetoaddress bcrt1qt30mvqww2cq9nvq4zlefj0l330y4k2ulqtdyks

This command instructs the regtest node to generate one block and direct its mining reward to the specified address (adr.tdks). Upon successful block creation, the node returned a newly mined block hash block.d848. Next, we inspected the block’s contents with the returned block hash:

(a) Details of Buyer-signed PSBT: The Base64-encoded string of the buyer’s signed PSBT (psbt.+Gqb) contains the necessary data to complete the transaction. The highlighted transaction fee shows the calculated fee of 0.27985000 B.

(b) Scenario 1: Attacker-signed PSBT with higher TxFee: It displays the Base64-encoded string of the attacker-signed PSBT (psbt.UBQv) with a higher transaction fee. In this scenario, the transaction fee is marked as 0.28125000 B, which is higher compared to 3(a), indicating a malicious modification by the attacker.

(c) Scenario 2: Attacker-signed PSBT with lower TxFee: It shows the Base64-encoded string of the attacker-signed PSBT (psbt.b+Gq) with a lower transaction fee. In this scenario, the transaction fee is significantly reduced to 0.0000010 B, which indicates a malicious attempt as a comparison with 3(b).

(d) Block details after our attack: There is only one confirmation transaction in the packed block. The transaction is highlighted in the tx field, which is the one (txid.f0bb) with the higher transaction fee. This confirms that the attacker’s attack was effective.

Figure 3: Screenshots during our attack

(1) First condition – block inclusion. In the resulting JSON output (Fig. 3(d)), the tx field revealed a single relevant transaction ID: tx.f0bb which matched the higher-fee PSBT created by the attacker.

To confirm this observation, we rechecked the mempool status via getrawmempool command. At this stage, the previously visible transactions, namely the ordinary buyer’s PSBT and the low-fee attacker transaction, had disappeared from the mempool. This disappearance occurred because those transactions became invalid once the attacker’s higher-fee PSBT transaction was included in the newly mined block. In other words, by consuming the same input PSBT at a higher fee, the attacker’s higher-fee PSBT transaction superseded the other two, causing them to be dropped from the mempool due to a conflict.

(2) Second condition – token receipt. In addition to the confirmation of the attacker’s transaction in the block, we also validate the success of the attack by examining the distribution of BRC20 tokens. Specifically, we check whether the attacker’s wallet has received the expected ak47, confirming that the attack was successful in redirecting the tokens from the legitimate buyer to the attacker.

To accomplish this, we queried the BRC20 token balances of the attacker’s wallet address (tx.f0bb) using a custom script that we developed for tracking token balances across different addresses. The script extracts transaction data from the regtest network and calculates the balance of each address by aggregating the token transfers. Upon performing this check, we observed, as anticipated, that the attacker’s address had received an additional 1000 AK47. Furthermore, we verified the token balance of the seller’s address (tx.0dd8), which showed a corresponding decrease of 1000 AK47.

Reproducibility of attack results. To ensure the reliability and reproducibility of our findings, we conducted two additional rounds of experiments beyond the initial trial (shown in Fig. 4). The objective was to further validate whether the observed results were consistent and not due to chance.

In the second round of experiments, we reversed the order of the low-fee and high-fee attacker transactions. This was done to examine whether the sequence in which the transactions were submitted had any impact on the attack’s success. Despite the change in order, the results were consistent with the initial experiment: the transaction with the highest fee was always confirmed in the block, while the lower-fee transaction and the legitimate transaction were discarded. The outcome of the attack was solely dependent on the fee rate but not the order of transaction submission.

In the third round, we increased the complexity of the experiment by introducing multiple sniping attempts. In this case, we set up four different attack transactions with varying fee rates (e.g., 9 sats/vB, 20 sats/vB, 35 sats/vB, and 50 sats/vB). We ran the experiment again under these conditions, and as expected, the transaction with the highest fee (50 sats/vB) was always the one included in the block, while the others were removed from the mempool due to conflicts. This third round demonstrated that the snipping attack could consistently be replicated, even when multiple transactions with different fees were used.

6. ATTACKING ADAPTABILITY

We discuss the adaptability of our attack and examine its applicability to various platforms.

6.1 Platform Requirements

For a BRC20 snipping attack to be possible, the following platform conditions must be met:

PSBT support. The platform must utilize or support the creation, signing, and broadcasting of PSBTs. In our attack model, these transactions are broadcasted with incomplete signatures, leaving room for a buyer to sign and complete the transaction.

Unconfirmed transactions in mempool. The platform must allow transactions to stay in an unconfirmed state long enough for an attacker to access them. This is essential because the snipping attack exploits the fee-based transaction replacement mechanism, where transactions in the mempool can be replaced by those with higher fees before being included in a block. If a platform processes transactions too quickly or confirms them instantly, it would limit the opportunity for an attacker to execute this attack.

Fee transparency. In many marketplaces, BRC20 tokens are traded with a transparent fee structure, where both the buyer and the seller are aware of the transaction’s proposed fee. If the platform does not provide sufficient visibility into transaction fees or hides this information from participants, it could reduce the effectiveness of the snipping attack, as the attacker would not be able to adjust their fee to outbid the legitimate buyer.

Third-party API support. Attackers often rely on the ability to query or subscribe to the mempool using third-party APIs or other tools that allow them to observe pending transactions. Platforms that enable API access will make it easier for attackers to spot legitimate BRC20 transactions.

6.2 Token Requirements

BRC20 tokens are a specific implementation of token standards built on the Bitcoin, typically through the use of inscriptions that embed JSON-like data directly into satoshis. The success of the snipping attack depends on several features of the BRC20 token standard and how it integrates with Bitcoin’s transaction system.

---

Useful information for enthusiasts:

• [1]YouTube Channel CryptoDeepTech
• [2]Telegram Channel CryptoDeepTech
• [3]GitHub Repositories CryptoDeepTools
• [4]Telegram: ExploitDarlenePRO
• [5]YouTube Channel ExploitDarlenePRO
• [6]GitHub Repositories Keyhunters
• [7]Telegram: Bitcoin ChatGPT
• [8]YouTube Channel BitcoinChatGPT
• [9] Bitcoin Core Wallet Vulnerability
• [10] BTC PAYS DOCKEYHUNT
• [11] DOCKEYHUNT
• [12]Telegram: DocKeyHunt
• [13]ExploitDarlenePRO.com
• [14]DUST ATTACK
• [15]Vulnerable Bitcoin Wallets
• [16] ATTACKSAFE SOFTWARE
• [17] LATTICE ATTACK
• [18] RangeNonce
• [19] BitcoinWhosWho
• [20] Bitcoin Wallet by Coinbin
• [21] POLYNONCE ATTACK
• [22] Cold Wallet Vulnerability
• [23] Trezor Hardware Wallet Vulnerability
• [24] Exodus Wallet Vulnerability
• [25] BITCOIN DOCKEYHUNT

Contact me via Telegram: @ExploitDarlenePRO