BRC20 tokens are a type of non-fungible asset on the Bitcoin network. They allow users to embed customized content within Bitcoin’s satoshis. The related token frenzy has reached a market size of US$2,650b over the past year (2023Q3-2024Q3). However, this intuitive design has not undergone serious security scrutiny.

We present the first in-depth analysis of the BRC20 transfer mechanism and identify a critical attack vector. A typical BRC20 transfer involves two “bundled” on-chain transactions with different fee levels: the first (i.e., \texttt{Tx1}) with a lower fee inscribes the transfer request, while the second (i.e., \texttt{Tx2}) with a higher fee finalizes the actual transfer. We find that an adversary can exploit this by sending a manipulated fee transaction (falling between the two fee levels), which allows \texttt{Tx1} to be processed while \texttt{Tx2} remains pinned in the mempool. This locks the BRC20 liquidity and disrupts normal transfers for users. We term this BRC20 pinning attack.

Our attack exposes an inherent design flaw that can be applied to \textbf{90+%} inscription-based tokens within the Bitcoin ecosystem.

We also conducted the attack on Binance’s ORDI hot wallet (the most prevalent BRC20 token and the most active wallet), resulting in a temporary suspension of ORDI withdrawals on Binance for \textbf{3.5 hours}, which were shortly resumed after our communication.

KEYWORDS

Bitcoin, Non-fungibility, BRC20, ORDI, Attacks

1 INTRODUCTION

First glance at BRC20. BRC20, short for Bitcoin Request for Comment 20 [1, 2], is a framework that enables the creation of non-fungible assets (or NFTs) [3] on the Bitcoin network.

The core aspect of non-fungibility is to implement uniqueness. Ethereum NFTs [3, 4] introduce the tokenID (defined in ERC721 [5]) as a unique identifier for each token. These unique tokens can be exclusively associated with external digital assets. Ownership of these NFTs is account-based, meaning they are linked to specific addresses and transferred via smart contracts. In contrast, BRC20 [6] takes a fundamentally different approach due to Bitcoin’s UTXO (i.e., unspent transaction output) model.

BRC20 tokens inscribe additional context directly into each satoshi (Sat, the smallest unit of Bitcoin) [7] and assign them sequential identifiers using Ordinal Theory [8, 9]. These inscriptions are inherently unique without the need to be tied to external resources. Their ownership is determined by each individual transaction. Although these inscriptions are in the form of plaintext strings, they can be irreversibly converted into versatile formats, including text, images, videos, or opcodes serving as operational guidance [10].

We present more technical details in Sec.2.

\textbf{BRC20 is really hot.} BRC20 has garnered significant attention, evident from various Bitcoin’s market indicators [1] including block size (surging from an average of 1.11MB to 1.85MB+), mempool transactions (reaching a peak of 315,257 transactions), and transaction fees (averaging a 10%+ increase 2). To date, the total number of BRC20 tokens has reached 795, with a trading volume of US$83,186,051,519 and a market capitalization of US$2,650,864,039,923. Statistical resources (e.g., Ordinal Wallet [11], UniSat [12], Dune Analytics [13, 14]) corroborate the upward trend in minted Ordinals.

The development of BRC20 has also been documented in recent studies (also see Sec.8), including a series of reports [1, 10, 15–17], market investigations [7, 18], and analytical works [19–22]. Many projects with similar design principles are deployed on their corresponding platforms, such as Ethscription [23], BSC20 [24], ASC20 [25], PRC20 [26], and SOLs [27].

\textbf{But BRC20 is not secure!} Our work differs from existing ones [7, 18–22, 28], which primarily focus on describing the BRC20 protocol and the role of off-chain indexers in managing the transaction process. Instead, we dive into its operational on-chain transferring mechanisms and present the first security assessment.

We find that BRC20 is surprisingly vulnerable. It is susceptible to a straightforward attack by freezing one of the transactions (typically needs two) during its transfer operation. We introduce this attack as the \textbf{BRC20 pinning attack}. Our attack has the potential to cause prolonged functional blockages and can be applied to all relevant hot wallets. Unlike mere programming flaws, the issue stems from an inherent design dilemma within BRC20, making it extremely challenging to fully eliminate.

We present our discoveries (i.e., \textbf{contributions}) step by step.

\begin{itemize} \item [①] \textbf{Deep dive to dynamically transferring BRC20s} (Sec.3, Fig.1). \end{itemize}

We provide the first in-depth analysis of the mechanisms involved in transferring BRC20 tokens over the Bitcoin network. Existing studies [1][2][7] primarily focus on the static aspects of BRC20 (i.e., how to inscribe tokens). A few studies [21][22] acknowledge that BRC20 tokens can be transferred, but they overlook the detailed dynamic transfer mechanisms (i.e., how to transfer these inscriptions over networks) by instead focusing mainly on the role of off-chain indexers handling the process.

We find that, contrary to what might be recognized, the inscribed transfer is not an actual operation executed on the Bitcoin network. Instead, it is merely a form of script, written after \texttt{OP_False} (meaning that it will never be executed on-chain) and stored on-chain.

The execution of such a transfer operation relies on the movement of real Bitcoin transactions (UTXOs). To complete a BRC20…

transfer operation, two UTXO-based transactions (i.e., $Tx1$, $Tx2$ in sequence) are required. $Tx1$ inscribes the operation (typically by sending it to oneself) and includes essential information such as the amount and recipient. $Tx2$ transfers the inscription to the recipient. These two transactions are typically initiated from an off-chain wallet and “bundled” together for execution.

New attack: BRC20 pinning attack (Sec.4, Fig.2).

We introduce BRC20 pinning attack, a new attack (to our knowledge, also the first) specifically targeted BRC20 tokens. Our attack is rooted in leveraging the BRC20 transfer operation (Sec.3.3) and transaction pinning techniques (Sec.4.1).

We discovered that the seemingly “bundled” transactions sent from users’ wallets are not actually bundled. The two transactions are created and sent independently, with a short time period that makes them appear as a single bundled transaction. Our attack exploits this gap by pinning $Tx2$ in the mempool, delaying the final token transfer to the recipient.

To achieve this, we strategically set a low-fee transaction (i.e., the malicious $Tx2$). The fee is carefully chosen to fall between two thresholds: sufficient for $Tx1$ to be processed but insufficient for $Tx2$. Since accurate transaction fees are theoretically unknown(^1), we begin with a very low fee (insufficient for either $Tx1$ or $Tx2$) and gradually increase the fee by resending the request. Once the fee is adequate for $Tx1$ but still below the threshold for $Tx2$, our attack succeeds. At this point, $Tx2$ will not be picked up by miners immediately and will remain in the mempool for an extended period (becoming pinned). These processes occur on-chain.

For off-chain processes, BRC20 movement relies on the usable state of transferable balance (Fig.1(c)). When a transfer request is initiated, tokens in $Tx1$ move from the available balance (which shows the current balance but cannot be spent directly) to the transferable balance (ready for spending). In $Tx2$, these transferable tokens are sent to the recipient, leaving the transferable balance at zero. In this sense, our attack immobilizes liquidity by prolonging the time tokens are locked within the transferable balance.

Our attack disrupts the normal BRC20 token transfer flow and creates a window for potential DoS-style attacks that can further impact the availability for the entire wallet and protocols.

Launching attacks against real project (Sec.5&Sec.6).

We first implement and evaluate our attack locally. We conduct experiments to assess the impact of parameters such as the transfer amount, transaction fee, mempool congestion level, and the number of attack attempts on the effectiveness of the pinning attack.

Our evaluation reveals that the frequency of attack attempts, combined with low transaction fees, can substantially extend the delay time for transaction confirmations, especially under high mempool congestion. Moreover, our results indicate that both larger individual transfers and a greater number of small transfers can effectively lock liquidity in the target’s transferable balance.

We then extended our attack to Binance’s ORDI hot wallet, the most popular/active BRC20 wallet (handling 26.24% [29] of the total transaction volume). Through four attack attempts, we locked the entire transferable balance of the wallet.

---

(^1)but what is known: based on empirical investigation, we observed that the fee required for $Tx1$ is greatly lower — around 3 to 5 times less — than the fee required for $Tx2$.

By monitoring relevant transaction activities and tracking the wallet’s available liquidity, our attack induced a temporary suspension of ORDI withdrawals for approximately 3.5 hours. We reported our attack to Binance and shortly restored its withdrawal function by sending counterpart recovery transactions.

Responsible disclosure. We have notified the Binance team and shared operational details to assist in expediting the resumption of withdrawals. Binance successfully resumed ORDI withdrawals. In addition, we have publicly disclosed our findings in early times through various media channels, including (but not limited to) Binance Square, PANews, Mirror, ForesightNews, TechFlow.

Extended discussion (Sec.7&Sec.8).

We propose defenses including dynamic fee adjustments, real-time transaction monitoring, and hierarchical authorization. We find that dynamically adjusting transaction fees based on mempool congestion levels can make it costly for attackers to execute prolonged pinning attempts. Real-time monitoring systems are also valuable, as they can detect unusual patterns, such as abnormally low fees or large transaction amounts, allowing exchanges to act swiftly by temporarily suspending these flagged transactions. Hierarchical authorization further strengthens defense mechanisms by implementing multi-layered transaction approvals, particularly for high-value transfers, which require multi-factor authentication (MFA) or multi-signature authorization.

However, the effectiveness of these defense strategies is limited by inherent design aspects of the BRC20 protocol. Because the protocol treats all transfer requests as valid without distinguishing intent, it remains challenging to prevent attacks aimed at locking liquidity, underscoring the need for further protocol-level enhancements.

We also discuss the adaptability of our attack to other BRC20 tokens and various inscription protocols on other blockchains. Our findings show that the attack is broadly applicable to 93.3% of BRC20 tokens on Bitcoin, which follow the same standardized inscription-based transfer mechanism as ORDI. However, the attack proves ineffective (in around 80% of cases) against inscription protocols on other blockchains, such as ETH20 on Ethereum and TON20 on Arbitrum. This is primarily because these protocols utilize a single-transaction process rather than a two-step transfer method, eliminating the possibility of delaying a second transaction.

Acknowledgement. This work was partially collaborated with TrustlessLab. We acknowledge their early contributions to attack implementations. In line with their preference for anonymity, we express credit to the team for their support in this project.

2 DISSECTING BRC20

2.1 Technical Foundation

Bitcoin “standards”. Bitcoin standards commonly refer to Bitcoin Improvement Proposals (BIPs) [30], which are established specifications or protocols defining various aspects of the Bitcoin network and its ecosystem, similar to ERC standards in the Ethereum ecosystem. These standards include a broad spectrum of topics, including protocols, transactions, address systems, wallets, and security. Here, we introduce BIPs that are relevant to the creation of BRC20.

Schnorr signature. Schnorr signature [31] (cf. BIP-340) is adopted to replace ECDSA for an improved efficiency (reducing signature length from 71–72 bytes to 64) while still remaining ECDSA’s security promises. An outstanding benefit is key aggregation (a.k.a., multisig), which allows multiple signatures from collaborative parties to be combined into a single signature. This aggregation involves combining a public key and a public key formed from the Merkle root of many scripts that can be used to spend the output.

Taproot/Tapscript. Taproot (BIP-341/342/343) outlines the integration of Schnorr signatures and introduces the concept of locking outputs to multiple scripts using Merkle branches (MAST, BIP-114/117). This enables a new method of spending Bitcoin known as Pay-to-Taproot (P2TR) where users can pay to either a Schnorr public key or the Merkle root of various other scripts (e.g., Tapscript).

Segregated witness. SegWit (BIP-141/144) enables larger scripting space. It introduces the witness structure, which can host extra data. A SegWit transaction consists of two parts: the original transaction structure (which contains sender&receiver data, excluding signatures) and a separate witness section appended at the end (which holds signatures and scripts). This reduces the storage size required for transactions and increases block capacity from 1 MB to 4 MB.

2.2 BRC20 Formation

Creating uniqueness. Unlike ERC721, which assigns a tokenID (an additional customizable field capable of accommodating any number) for NFTs [3], uniqueness in the Bitcoin network is established based on its smallest unit, satoshi, via the Ordinal Theory [8]. As satoshis are indivisible, the protocol essentially serves as a numbering scheme for satoshis, enabling each satoshi to be tracked/transfered as an individual entity (cf. Fig.1(a)). It is preserved as transactions transfer from inputs to outputs, following the first-in-first-out principle, which is a fundamental feature of UTXO-based transactions. We defer the details in Sec.3.3.

Inscribing context. Inscription involves embedding personalized content into each unique satoshi. Such data is assigned the P2TR script type, and the generated inscriptions are stored within the SegWit section of a transaction (witness), presented in various formats such as text (JSON formats), images, audio, and even highly compressed video files (peep at [32][33]).

In particular, we take a text-based BRC20 (e.g., ORDI [34]) as the instance. The on-chain inscription contains several crucial details (see Listing 1), including the protocol name (brc20), operation (e.g., transfer), token name (e.g., ordi), total amount of tokens to be issued (max), maximum amount of tokens to be minted in each round (lim), and amount of tokens to be minted/transferred (amt).

Table 1: BRC20-related BIPs

BIP	Title	Usage for BRC20
114	Merkelized Abstract Syntax Tree (MAST)	Batch Validation/Processing
117	Tail Call Execution Semantics	Batch Validation/Processing
125	Opt-in Full Replace-by-Fee Signaling	Transaction Pinning
141	Segregated Witness (Consensus layer)	Space Extension
144	Segregated Witness (Peer Services)	Space Extension
340	Schnorr Signatures for Secp256k1	Batch Validation
341	Taproot. SegWit version 1 spending rules	Inscription
342	Validation of Taproot Scripts	Inscription
343	Mandatory activation of Taproot deployment	Inscription

Listing 1: Inscriptions and the Transfer operation

# On-chain Inscription
"p": "brc20" # protocol name
"op": "deploy" # operation
"tick": "ordi" # token name
"max": "2100000" # total amount of issued token
"lim": "1000" # maximum minted tokens per round
"amt": "100" # the amount of token being actioned

# Inscription with the Transfer operation
"p": "ordi", # protocol
"op": "transfer", # inscribed transfer operation
"tick": "ordi", # token to be transferred
"amt": "100" # the amount of transferred tokens

# UTXO Transactions over the Bitcoin network

# Off-chain update
if state["tick"] NOT exists OR
  "amt" > "lim" OR sum("amt") > "max":
    raise errors
else
  account["tick"]["balance"][minter] += amt

On-chain storage. BRC20 tokens are fully settled on-chain, and their movement (i.e., implementing the Transfer operation) depends on the transfer of Bitcoin native transactions (i.e., the sending and receiving of satoshis) via the underlying layer-one network (cf. Fig.1(b)). The Bitcoin network only records native transaction activities related to these inscriptions, whereas it does not provide real-time insights into the status of existing BRC20 tokens or account balances (unlike account-based models [4]). These functionalities are delegated to off-chain layers.

Off-chain retrieves. Users interact with those on-chain tokens via off-chain validation services (a.k.a., indexers [7]), which facilitate real-time data retrieval. Indexers are responsible for tracking which wallets minted the original token supply up to the maximum limit, determining where minting ceased and tracing whether tokens traded in secondary markets can be linked back to wallets (Fig.1(c)). Indexers only track transactions without modifying or appending on-chain data. Even if an indexer fails, there is no risk of fund loss, as it can be deterministically reconstructed by reapplying the transaction rules. Many users may be unaware of these indexers, as their services are often integrated into user-friendly wallets such as Ordinals Wallet [11], UniSat [12], Binance’s hot wallet [35], etc.

3 TRANSFERRING BRC20 TOKENS

3.1 Inscribed Transfer Operation

BRC20 protocols support three operations. (i) Deploy: This operation involves the creation of a new type of BRC20 token by its creators, configuring initial settings such as upper limits. (ii) Mint: This operation primarily involves increasing the token amount, typically conducted by users with the help of external tools (i.e., indexers). (iii) Transfer: This operation facilitates the exchange of tokens via actual transactions in the Bitcoin network.

We present a sample code segment illustrating the inscribed Transfer operation (see the second part of Listing 1).

Not actions but signals! The inscribed operations are not executable actions. Instead, they leverage the OP_RETURN opcode in Bitcoin transactions, creating “False Return” scripts that generate

provably unspendable outputs [36]. These outputs can accommodate arbitrarily formatted data written after OP_FALSE [37], ensuring that none of the inscribed information is executed on-chain.

These inscriptions, however, serve as a signal to initiate the actual transfer operation via on-chain transactions.

Transfer and transactions. While the deploy and mint operations require only a single transaction (i.e., sent to oneself), the transfer operation for BRC20 tokens involves two transactions (cf. Fig. 1(a)): one for token inscription ((Tx1), sent to oneself) and another for the actual token exchange ((Tx2), sent to the recipient). These two transactions are executed sequentially within a very short timeframe, giving the appearance of being bundled together. Upon completion of both transactions, an off-chain indexer recalculates the final UTXO-based balance and updates the account, which corresponds to the end-user’s wallet interface.

3.2 Transfer Foundations over Bitcoin Networks

Token balance structure.

The BRC20 token balance structure is divided into three categories: available balance, transferable balance, and overall balance, each serving a distinct purpose in managing the state of a user’s tokens [6].

• Available balance (B_{avail}). The available balance represents the portion of a user’s tokens that can be freely used (i.e., the amount of funds they possess). It reflects the liquid amount of tokens in the user’s account address that are readily available for spending or transfer at any given time.
• Transferable balance (B_{trans}). The transferable balance consists of tokens that have been inscribed with a transfer operation but have NOT yet been transferred to the recipient. These tokens are temporarily locked and cannot be accessed or spent by the user until the inscription is finalized.
• Overall balance (B_{total}). The overall balance is the sum of both the available balance and the transferable balance. It represents the total number of tokens held by the user, including tokens that are currently locked in pending transfers. The relationship between these balances can be expressed as: (B_{total} = B_{avail} + B_{trans}).

UTXOs. Bitcoin’s UTXO model serves as the backbone for tracking unspent funds in BRC20 transactions. Each UTXO is defined as a tuple, typically represented as: (utxo := (v, P, s)), where (v) denotes the value, (P) represents the locking conditions (encumbrance), often a public key or script, and (s) is the serial number ensuring uniqueness. UTXOs can be created and consumed through mint and transfer transactions. For BRC20 transactions, when a token is transferred, a set of input UTXOs is fully consumed, and a new set of output UTXOs is created (cf. Fig. 1(b)), encoded as follows: (tx_{\text{transfer}} = (utxo_{\text{inp}}, v_{\text{inp}}, P_{\text{out}})), where (utxo_{\text{inp}}) is the list of input UTXOs, (v_{\text{out}}) are the output values, and (P_{\text{out}}) are the new encumbrances. The UTXO model used in BRC20 ensures that tokens remain transferable while being securely tracked.

Transaction fee. A transaction fee is determined by subtracting the total output value from the total input value. Any leftover satoshis in a transaction become the fee rewarded to miners. The higher the fee rate, the sooner the transaction will be confirmed. Transaction fees are typically measured in satoshis per byte (sats/vbyte), where the fee is divided by the size of the transaction in virtual bytes. Fee bumping mechanisms like Replace-by-Fee (RBF [38]) and Child

---

Figure 1: How to transfer BRC20 tokens

Pays for Parent (CPFP [39]) allow users to increase fees on pending transactions to speed up confirmation in case of delays.

In the two-step transfer process for BRC20 tokens, the fees for each step are distinct yet interrelated. Users typically only set up one transaction fee when initiating the token transfer, which can mask the fact that there are actually two transactions involved. (Tx1) requires a lower fee, as it mainly inscribes the intent to transfer. Conversely, (Tx2), which completes the actual transfer, generally incurs a higher fee — often 3 to 5 times more than that of (Tx1). This discrepancy in fees ensures that (Tx2) is confirmed swiftly after (Tx1) under normal conditions.

To be unfortunately noted, while we can empirically determine that the fee for \textit{Tx1} is lower than that for \textit{Tx2}, the exact fees for each transaction remain unknown until they are actually executed.

Mempool transaction exit. In Bitcoin, unconfirmed transactions remain in the mempool but are removed under specific conditions. (i) The most common scenario is when a transaction is confirmed by being included in a block mined by a miner. Once confirmed, the transaction is removed from the mempool, as it no longer needs to be broadcasted. (ii) Additionally, if the mempool reaches its maximum capacity, lower-fee transactions may be evicted to make space for higher-fee ones. (iii) Moreover, transactions can also exit the mempool through the RBF mechanism [38], where a user broadcasts a new transaction with a higher fee, replacing the original lower-fee transaction. (iv) Another reason for transaction removal is expiration. If a transaction remains unconfirmed in the mempool for an extended period — usually 14 days [40] — it may be dropped by nodes due to timeout. (v) Finally, conflicting transactions, such as those involved in double-spend attempts, will be removed if a competing transaction is prioritized.

3.3 Transfer In Action (Bitcoin Networks)

The transfer of BRC20 over the Bitcoin network is a two-step process comprised by two transactions (cf. Algorithm 1).

• Step-①: Inscribing the transfer operation. The first step involves the sender inscribing a transfer request (i.e., \textit{Tx1}) with a transaction fee ( f_{tx} ), aiming to move a specified amount of tokens ( m ) to the recipient with address ( A_r ). During this step, the sender’s available balance ( B^{A_s}{\text{avail}} ) is reduced by ( m ), and an equivalent amount is added to the sender’s transferable balance ( B^{A_s}{\text{trans}} ). At this stage, the tokens are placed in a pending state and are not yet executable to ( A_r ). \textit{Tx1} alone does not affect the recipient’s balances; it only logs the intention of transferring tokens. The overall balance ( B^{A_r}{\text{total}} ) remains \textit{unchanged} as tokens are still under the sender’s control, albeit temporarily locked in the ( B^{A_s}{\text{trans}} ).
• Step-②: Executing the transfer operation. In this step, the actual transfer (i.e. \textit{Tx2}) is executed over the network, finalizing the transfer initiated by \textit{Tx1}. \textit{Tx2} moves the specified amount ( m ) from the sender’s transferable balance ( B^{A_s}{\text{trans}} ) to the recipient’s available balance ( B^{A_r}{\text{avail}} ). Once the \textit{Tx2} is confirmed, the ( B^{A_s}{\text{trans}} ) is reset to zero, and the overall balance ( B^{A_r}{\text{total}} ) is reduced by ( m ). This marks the completion of the transfer. Simultaneously, the recipient’s ( B^{A_r}{\text{avail}} ) and overall balance ( B^{A_r}{\text{total}} ) are increased by ( m ). If the transfer retry limit is reached (( r \geq R_{\text{max}} )) without success, the transfer is aborted to prevent unnecessary retries.

4 BRC20 PINNING ATTACK

4.1 Transaction Pinning

Transaction pinning [41] is a technique in blockchain where a transaction is deliberately crafted to delay its confirmation time.

Implementing transaction pinning. The core principle is to intentionally keep a transaction unconfirmed in the mempool for an extended period (thereby \textit{pinning} it in place). This is achieved by manipulating transaction attributes — such as transaction fees, sequence numbers, and inputs/outputs — to control and delay the confirmation of specific transactions.

We introduce three ways of conducting transaction pinning.

• Setting low transaction fees: In blockchain systems like Bitcoin and Ethereum, miners prioritize transactions based on the fees attached to them, processing higher-fee transactions first to maximize their rewards. By assigning a transaction fee lower than the average or recommended level, the transaction becomes less attractive to miners. As a result, the low-fee transaction remains unconfirmed for a longer duration.
• Creating non-replaceable transactions: Transactions can be constructed to opt out of replacement protocols such as RBF [38] by setting the sequence number from ( 0xFFFFFFFFD ) to the maximum value (( 0xFFFFFFFFF )). By marking a transaction as non-replaceable, the sender prevents it from being superseded by another transaction with a higher fee, maintaining its mempool position.
• Establishing dependencies: The confirmation time can be extended by creating a chain of transactions where the inputs spend outputs from other unconfirmed transactions. If the initial transactions have low fees or are otherwise delayed, subsequent transactions cannot be confirmed until the earlier ones are processed.

Pros and cons. Transaction pinning can serve several purposes within blockchain networks: (i) Users may intentionally set lower fees for non-urgent transactions to reduce costs; (ii) Users can use transaction pinning to prevent others from fee bumping a transaction [41], controlling over a reasonably average confirmation time; (iii) In certain multiparty protocols, it can be employed to ensure that transactions adhere to predefined rules or sequences, preventing unauthorized fee modifications.

Transaction pinning can also be exploited to execute malicious strategies: (i) It can be used to carry out DoS attacks by flooding the mempool with pinned transactions, causing network congestion; (ii) Delayed confirmations increase the risk of front-running [42][43], where attackers observe pending transactions and submit their own with higher fees to ensure they are processed first.

4.2 BRC20 Pinning Attack

We present the BRC20 pinning attack, an attack based on the transaction pinning and inscription transfer mechanism (cf. Sec.3).

Our BRC20 pinning attack strategically targets a critical vulnerability: \textit{transferable balance}. When a token transfer is initiated via inscription, the tokens move from the ( B^{A_s}{\text{avail}} ) to the ( B^{A_r}{\text{trans}} ), where they remain pending until the transaction is confirmed. By applying transaction pinning techniques, the attacker can prolong the time tokens remain in ( B^{A_r}_{\text{trans}} ). This creates a window of opportunity for the attacker to initiate numerous transfers and overwhelm the target’s liquidity. This denial of liquidity can halt withdrawals, disrupt operations, and create significant financial damage for the target.

Our attack consists of two steps (cf. Algorithm 2).

• Step-①: Inscribing falsified transfers. Let ( A_t ) represent the target’s address and ( A_r ) the attacker’s address. The attacker initiates a BRC20 token transfer request (( \text{Tx}_1 ) to ( \text{A}t ) (Line 1). Each transfer inscribes a fraction ( f ) of the target’s available balance ( B^{A_t}{\text{avail}}(t) ) (Line 2). The amount inscribed in each request ( i ) is:

[ m_i = f \cdot B^{A_t}_{\text{avail}}(t), \text{ for } i \in {1, 2, \ldots, N}, f \in [0, 1] ]

Algorithm 1 BRC20 Inscribed Transfer Process

Global Parameters: Available balance $B_{avail}$, Transferable balance $B_{trans}$, Total balance $B_{total}$, Transaction fee $f_{tx}$.

Local Parameters: Token amount $m$, Sender’s address $A_s$, Recipient’s address $A_r$, Max retries $R_{max}$, Single retry $r_T$, Delay time $T_{delay}$.

1. Step-①: Upon initiating an InscribeTransfer request (Tx1)
2. Sender $A_s$ inscribes $m$ tokens for transfer to recipient $A_r$ with $f_{tx}$
3. Update balances for the sender’s $A_s$
   4. $B_{A_s avail} ≔ B_{A_s avail} − m$
   5. $B_{A_s trans} ≔ B_{A_s trans} + m$
   6. $B_{A_s total} ≔ ∅$ ⊲ balance unchanged
4. Update balance for the recipient’s $A_r$
   8. $B_{A_r avail} ≔ ∅$
   9. $B_{A_r trans} ≔ ∅$
   10. $B_{A_r total} ≔ ∅$ ⊲ all unchanged
5. Step-②: Execute transfer (Tx2)
6. $r_t ≔ 0$ ⊲ initialize retry counter
7. while $r_t < R_{max}$ do
8. $A_s$ sends a transaction to $A_r$ to transfer the inscribed amount $m$
9. if transaction fee $f_{tx}$ is too low then
10. retry: increase $f_{tx}$ and resend transaction
11. $r_t = r_t + 1$
12. else
13. Update balances for $A_s$ after transfer:
14. $B_{A_s avail} ≔ B_{A_s avail} + m$
15. $B_{A_s trans} ≔ B_{A_s trans} − m$
16. $B_{A_s total} ≔ B_{A_s total} − m$
17. Update balances for $A_r$ after transfer:
18. $B_{A_r avail} ≔ B_{A_r avail} − m$
19. $B_{A_r trans} ≔ B_{A_r trans} + m$
20. $B_{A_r total} ≔ B_{A_r total} + m$
21. break
22. end if
23. end while
24. if $r_t = R_{max}$ then
25. Abort ⊲ failed due to over-threshold for retries
26. end if

At this stage, the target total’s balance $B_{A_t total}^{t}$ remains unchanged, with only internal balances shifting $B_{A_t avail}^{t}$ decreases and $B_{A_t trans}^{t}$ increases (Line 5), since the inscribed operation has been confirmed. The attacker can send multiple inscription transfer requests (Line 19&20) to flood the network, aiming to lock up a substantial portion of the target’s liquidity.

Step-② Delaying transfer execution. The attacker delays the actual transfer process (Line 3) of the Tx by minimizing the transaction fees $f_{tx}$. Let $f_{tx}^{t}$ represent the transaction fee for the $i$-th inscribed transfer. The attacker chooses the transaction fee that is high enough to prioritize Tx1 but remains low enough to prevent Tx2 from being immediately confirmed: $f_{tx}^{t} ∈ [f_{min}, f_{max}]$, where $f_{min}$ is the threshold for low-priority transactions in the mempool, and $f_{max}$ is the upper limit at which Tx2 avoids quick execution (Line 4&21).

The attacker further leverages mempool congestion $C_m$ to maximize the delay in confirmation (Line 7&22). $C_m$ is the ratio of the current number of unconfirmed transactions to a network-defined threshold that represents normal congestion levels [44]. The attacker calculates the total delay $T_{delay}$ and compares it to the threshold time $T_{bar}$ to assess whether the attack has succeeded or failed (Line 9&28). If successful, the target’s liquidity is diminished by $m$. When $m$ equals the maximum available amount

Algorithm 2 BRC20 Pinning Attack

Global Parameters: $B_{avail}$, $B_{trans}$, $B_{total}$, Transaction fee $f_{tx}$, Mempool congestion $C_m$, Critical delay $T_{bar}$

Local Parameters: Token amount $m$, Attacker’s address $A_t$, Target’s address $A_r$, Multiple retries $R_{max}$, Single retry $r_T$, Delay time $T_{delay}$

1. Step-③: Attacker $A_t$ initiates BRC20 token transfer request (Tx).
2. Attacker $A_t$ requests to inscribe $m$ tokens to target $A_r$
3. Attacker $A_t$ deliberately sets low transaction fee $f_{tx}$
4. $f_{tx} ≔ f_{min}$ ⊲ Minimum fee to avoid rejection but ensure delay
5. Update balances for the target $A_r$ normally ⊲ Total balance unchanged, only internal balances shift
6. Check mempool congestion $C_m$.
7. if $C_m$ is high and $f_{tx}$ is too low then
8. Transaction is stuck in mempool, delaying confirmation
9. Attacker $A_t$ calculates $T_{delay}$
10. if $T_{delay} > T_{bar}$ then
11. Attack succeeds: Tokens remain in $B_{A_t trans}^{t}$, locked and unusable
12. else
13. Go to Step-②
14. end if
15. else
16. Transaction confirmed; tokens move out of $B_{A_t trans}^{t}$
17. Balances updated normally for both $A_t$ and $A_r$
18. end if
19. Step-④: $A_t$ repeats ($R_{max}$) low-fee transactions to lock more tokens.
20. Attacker continues sending multiple low-fee inscription requests to $A_r$
21. for $r_T = 2$ to $R_{max}$ do
22. $A_t$ inscribes $X$ tokens with $f_{tx}$, where $X$ is the maximum number of $m$
23. if transaction is stuck due to high $C_m$ and low $f_{tx}$ then
24. Target $A_t$’s tokens are locked due to unconfirmed transactions
25. Update balance for $A_r$ after attack:
26. $B_{A_r avail}^{t} ≔ B_{A_r avail}^{t} − X$
27. $B_{A_r trans}^{t} ≔ B_{A_r trans}^{t} + X$
28. Calculate $T_{delay}$
29. if $T_{delay} > T_{bar}$ then
30. Exit loop ⊲ Attack succeeds, exit retry
31. end if
32. else
33. Next loop; transaction confirmed
34. Balances updated normally ⊲ Attack failed, next retry
35. end if
36. end for
37. if $f_{tx}$ max retries $r_T = R_{max}$ reached without $T_{delay} > T_{bar}$ then
38. Exit ⊲ Attack failed
39. end if

$X$ of $B_{A_t avail}^{t}$ (i.e., $f = 1$), $B_{A_t avail}^{t}$ is completely depleted, indicating a full drain of $B_{A_t avail}^{t}$’s liquidity (Line 24). If the attack fails, the attacker can relaunch additional attempts (Line 20). The attack is considered a failure only if the maximum number of retries $N$ is reached without meeting the success criterion (Line 38).

4.3 (Attack) Success Criteria

Operational Tolerance. We introduce the concept of operational tolerance to evaluate the success of our attack.

The attack is successful if the transaction with the inscribed transfer inscription is pinned at the first stage (i.e., inscribeTransfer) and fails to advance to the second stage (executeTransfer).

The key to this success is ensuring that the delay time exceeds a certain threshold, triggering the pinned stage. Specifically, the target’s tokens must remain locked in $B_{A_t trans}^{t}$ for a sufficient duration (measured as the total delay $T_{delay}$) to effectively disrupt the target’s

operations. The attack achieves its objective if the added $T_{\text{delay}}$ surpasses the threshold time $T_{\text{bar}}$, i.e., $T_{\text{delay}} > T_{\text{bar}}$.

We refer to this threshold time as operational tolerance, which represents the minimum delay required to cause liquidity disruptions and failed withdrawals.

Operational tolerance calculation. To estimate the operational tolerance $T_{\text{bar}}$ for mainstream centralized exchanges (CEXs, e.g., Binance, Coinbase, Kraken), we consider several key factors that determine how long an exchange can endure liquidity being locked without experiencing disruptions in its operations.

• Average transaction volume ($V$). The average volume of transactions that the exchange processes over a specific period.
• Required liquidity ($L_{\text{req}}$). The minimum amount of liquid tokens the exchange needs to meet its immediate transaction obligations.
• Available liquidity reserves ($L_{\text{avail}}$). The total amount of liquid tokens the exchange has on hand.
• Liquidity consumption rate ($C$). The rate at which the exchange’s liquidity reserves are consumed due to transactions.

We construct a formula to estimate $T_{\text{bar}}$, where $C = \frac{V}{T_{\text{period}}}$ and $T_{\text{period}}$ is the time period over which $V$ is measured.

$$T_{\text{bar}} = \frac{L_{\text{avail}} – L_{\text{req}}}{C}.$$

By applying typical values to our formula, we demonstrate the calculation of the operational tolerance range $T_{\text{bar}}$. For this analysis, we consider Binance as our target CEX.

Due to the lack of direct data from Binance, we approximate its values by analyzing ORDI transaction data from 2024 on OKX [45], a comparable CEX with a slightly smaller user base than Binance. We derive the following parameters:

• $L_{\text{avail}}^{\text{high}}$, $L_{\text{avail}}^{\text{low}}$, is approximately 5,000,000 and 2,500,000 tokens, respectively;
• $L_{\text{req}}$ is estimated at 2,000,000 tokens; and
• $V$ is around 1,000,000 tokens per hour. Based on these values, we calculate $T_{\text{bar}}^{\text{high}}$ to be approximately 3 hours as the upper bound. Conversely, the lower bound $T_{\text{bar}}^{\text{low}}$ is calculated to be approximately 0.5 hours for Binance.

Operational tolerance range. By calculation, our attack targets CEXs, where a reasonable operational tolerance range is estimated to be between 0.5 and 3 hours, depending on their available liquidity reserves and transaction volumes. For DeFi protocols that provide liquidity pools or offer staking services, $T_{\text{bar}}$ tends to be slightly higher, usually spanning from a few hours to up to 24 hours, due to their decentralized nature and generally lower immediate liquidity demands compared to centralized exchanges. On the other hand, wallet services or newly launched DeFi projects may exhibit a shorter $T_{\text{bar}}$, often less than 30 minutes, as they have lower liquidity reserves and handle fewer transactions.

5 IMPLEMENTING ATTACKS LOCALLY

In this section, we simulate and evaluate our BRC20 pinning attack in a controlled local (or private) environment.

Parameter	Levels	Range	Results
Transfer amount ($m$)	Small, Medium, Large	10% of $B_{\text{tx}}^{M}$, 50% of $B_{\text{tx}}^{A}$, 100% of $B_{\text{tx}}^{A}$	Fig.4(b)
Transaction fee ($f_{\text{tx}}$)	Minimum fee, Medium fee, Higher fee	100 sat/vb, 200 sat/vb, 500 sat/vb	Fig.4(a)
Mempool congestion ($C_{\text{mempool}}$)	Low, Medium, High	25% network capacity, 50% network capacity, 75% network capacity	Fig.4(c)
Number of attack attempts ($N$)	Few attempts, Moderate attempts, Many attempts	2 times, 5 times, 10 times	Fig.3(a) & Fig.3(b)

5.1 Experiment Objectives ($O$)

We examine how the transfer amount $m$, transaction fee $f_{\text{tx}}$, mempool congestion level $C_{\text{mempool}}$, and number of attack attempts $N$ impact the effectiveness of the attack. Specifically, we aim to

• $O$-1: evaluate how an attacker can optimize the choice of $N$ in conjunction with variables $m$, $f_{\text{tx}}$, and $C_{\text{mempool}}$ to maximize the impact of the attack while minimizing associated costs;
• $O$-2: investigate the impact of increased fees $f_{\text{tx}}$ on the cumulative delay and liquidity disruption experienced by the target;
• $O$-3: examine whether a greater number of smaller transfer attempts can be as effective as fewer, larger transfers in attacks.

The specific values are illustrative estimates based on typical CEXs and publicly available information up to September 2024. Actual values may vary depending on the exchange’s size, the BRC20 tokens involved, and market conditions.

5.2 Experiment

Configurations. We conducted experiments on a high-performance workstation equipped with 16 multi-core processors for parallel transaction processing, 32GB RAM for running the Bitcoin node, and a 1TB SSD for storing blockchain data. The workstation was connected to a 100 Mbps high-speed internet connection to maintain real-time synchronization with the Bitcoin testnet.

For the software setup, we used Bitcoin Core (v27.0 [46]) to operate the Bitcoin testnet nodes and the Ordinals Wallet [11] for transferring BRC20 tokens. Python (v3.9) scripts were developed to automate transaction generation, utilizing key libraries such as requests (for node communication) and time (for handling transaction delays). Finally, we employed the REST API of Mempool.space [47] to monitor mempool congestion.

Procedure. Our experiments consist of three major steps.

• Initialization. Set the target address $A_T$’s $B_{A_{\text{avail}}}$ to a constant value for consistency throughout the experiment.
• Parameter setting. To evaluate the attack under various conditions, we generated all possible combinations of the parameters specified in Table 2. We consider the transfer amount $m$, transaction fee $f_{\text{tx}}$, mempool congestion level $C_m$, and the number of attack attempts $N$, each with three levels. The transfer amounts were set at 10%, 50%, and 100% of the target’s available balance $B_{A_{\text{avail}}}$, simulating small, medium, and large-scale attacks. Transaction fees were assigned values of 100, 200, and 500 sat/vB, corresponding to minimum, medium, and higher fees to assess the impact of fee manipulation on transactions. Mempool congestion levels were modeled at 25%, 50%, and 75% of network capacity to represent varying network conditions from low to high congestion. The number of attack attempts was varied between 2, 5, and 10 to examine the effects of repeated attacks on the target’s liquidity. By combining each level of every parameter with all levels of the other parameters, we created a total of 81 unique experimental scenarios (i.e., calculated by $3 \times 3 \times 3 = 81$).
• Trial execution. For each scenario, we set the specific parameter values and simulated the attack by initiating the specified number of Transfer operations from the attacker’s address $A_m$ to the target address $A_T$, using the designated transfer amounts $m$ and transaction fees $f_{\text{tx}}$ under the given mempool congestion level $C_m$. We meticulously recorded the delay time $T_{\text{delay}}$ for each transaction and observed the cumulative impact on the target’s transferring balance $B_{A_{\text{trans}}}$ and available balance $B_{A_{\text{avail}}}$, noting how much of the target’s liquidity was locked and for how long.

Data collection & calculation. We collect the following data: (i) The delay $T_{\text{delay}}$ caused by each Transfer operation initiated by the attacker; (ii) the total volume of tokens pinned in the target’s transferable balance $B_{A_{\text{trans}}}$ as a result of the $N$ attack attempts; (iii) whether each trial meets the attack’s success criteria — specifically, if $T_{\text{delay}} > T_{\text{bar}}$ and if the cumulative impact on the target’s liquidity is significant; (iv) for each parameter combination, we calculate the average liquidity outage duration and the attack success rate.

5.3 Evaluation Results

We provide a detailed analysis of experimental data, explaining how each attack parameter impacts the attack.

Evaluation on $O_{-1}$. We first evaluate the success rate (see Fig.3(a)). We categorize success rates across three levels of mempool congestion (25%, 50%, and 75%) and three scales of attack attempts (2, 5, and 10 times) at a constant transfer amount and transaction fee (10% and 100 sat/vB, respectively).

Then, we evaluate the average transaction delay (cf. Fig.3(b)). We show the distribution of average transaction confirmation delays across different levels of mempool congestion (25%, 50%, and 75%) and varying scales of attack attempts (2, 5, and 10 attempts).

• Key observations. (i) As $N$ increases from 2 to 10, there is a clear trend of increasing success rate across all levels of mempool congestion; (ii) higher mempool congestion levels significantly amplify the success rates of attacks. For instance, at 75% congestion, the success rates jump from around 60.68% at 2 attempts to an impressive 81.06% at 10 attempts; (iii) as $N$ increases, not only does the success rate improve, but the variability in transaction delay also increases. At higher congestion levels, the delay peaks are notably higher, and the spread of delay times widens, indicating more frequent extreme values.
• Strategic insights. We obtain two insights: (i) the data suggests maximizing the number of attempts during periods of high mempool congestion could be the most effective strategy for executing a pinning attack, capitalizing on the network’s vulnerabilities during high traffic to maximize disruption; (ii) while increasing $N$ at high $C_m$ levels provides higher success rates, it also might raise the risk of detection if not managed stealthily, requiring attackers to balance the increased success potential against the potential for heightened scrutiny.

Evaluation on $O$-2. We evaluate (Fig.4(a)) the variations in average transaction delays across different transaction fees ($f_{tx}$) under three predefined levels of mempool congestion (25%, 50%, and 75%).

• Key observations. (i) There is a notable decrease in transaction delays as the transaction fee increases from 100 sat/vb to 500 sat/vb, demonstrating a strong inverse correlation between $f_{tx}$ and delay time; (ii) at lower fees (100 sat/vb), there is a wide range of transaction delays, particularly at higher congestion levels, indicating greater variability in transaction processing times; (iii) the reduction in delay is most pronounced when transitioning from 100 sat/vb to 200 sat/vb, suggesting that a minimal increase in fee can significantly enhance transaction processing speed.
• Strategic insights. (i) Regardless of the level of congestion, employing lower transaction fees is a strategic approach for attackers to prolong the duration of the attack; (ii) conversely, defenders might focus on anomalous transaction patterns at lower fees during peak congestion as potential indicators of pinning or similar attacks, especially when these transactions deviate from typical user behavior in terms of speed and fee levels.

Evaluation on $O$-3. We evaluate (cf. Fig.4(b)) the impact of the number of attempts (i.e., 2, 5, 10) on the percentage of pinned tokens, segmented by the size of the transfer (small, medium, large). Additionally, we also evaluate (see Fig.4(c)) the attack success rate impacted by mempool congestion levels (25%, 50%, 75%).

• Key observations. (i) An increase in pinned tokens as the number of attempts $N$ increases, with larger transfers having a more pronounced effect; (ii) the success rate is independent of the transfer size. It consistently increases with mempool congestion across all transaction sizes, reinforcing the findings from $O$-1.
• Strategic insights. (i) While large transfers inherently pin a high percentage of tokens in fewer attempts, multiple small transfers can cumulatively achieve similar disruption levels; (ii) under high congestion, even small transfers become considerably effective. This tactic is particularly useful in scenarios where avoiding attack detection is important, as transactions with large transfer amounts are more easily noticed.

6 APPLYING ATTACKS AGAINST BINANCE

In this section, we extend our attack to a real-world project by targeting Binance’s ORDI wallet. ORDI ranks as the No.,1 BRC20 token in terms of market capitalization and on-chain activity. Binance has the largest trading volume for ORDI, occupying 26.24% of the total market volume, making its ORDI wallet the most active. The second-largest volume is held by OKX, occupying 15.99%. This significant market share makes Binance’s ORDI wallet an ideal target to demonstrate the practical implications of our attack.

6.1 Preparation

Attack target. The target of the attack was Binance’s ORDI wallet address: bc1qhuv3dhpnm0wktasd3v0kt6e4aqfqsd0uhfdu7d. At the time of the attack, this wallet held a substantial amount of 8,196,950 ORDI tokens (valued at approx. US$9,052,645 based on the then-current ORDI price of US$1.10 per token). We selected this address as our primary target for attacking for several reasons: (i) The large amount of tokens held in the wallet: This significant holding means that any successful attack could impact a considerable volume of assets, demonstrating the potential severity of the BRC20 pinning attack. (ii) OKX explorer [45] indicates that it is one of the most active addresses for ORDI, handling deposits and withdrawals for a large user base. By focusing on an address with high transactional throughput (150 txns/day), we can easily assess how the attack might disrupt normal operations.

Attack tools. We used the Ordinals wallet interface [11] to interact with the ORDI protocol, creating multiple inscribeTransfer transactions targeting the wallet. We employed the Mempool.space API [47] to monitor Bitcoin’s mempool congestion in real-time. We also used the Ordiscan explorer [48] to verify the status of the ORDI wallet during the attack and Unisat [12] to track specific transaction details and evaluate the impact on Binance’s operations.

6.2 Execution of Attack

Attack overview. Our pinning attack against Binance’s ORDI wallet consisted of several successive attack attempts (cf. Fig.5). We achieved this by executing transactions with low transaction fees and large token amounts under high mempool congestion, pinning Binance’s ORDI in the transferable balance for an extended period. During the execution of our attack, we successfully locked the entire liquidity of the wallet and caused an operational shutdown of Binance’s ORDI wallet. This led to a temporary halt in withdrawals.

---

1 As of the time of writing, ORDI’s MarketCap is $711M, according to CoinMarketCap.

2 Data is calculated by Total txns/Total days, according to OKX [Oct. 2024].

and transfers for users, lasting approximately 3.5 hours. Following this period, recovery mechanisms were implemented, and normal operations were restored.

We mark the malicious inscriptions (i.e., under our attacks) in purple, while the recovery ones are in teal. The remaining normal inscriptions/transactions (i.e., requests from users) are in black.

Ethical considerations. It is important to highlight that this attack was conducted under white-hat principles. Our intention was to stress-test the BRC20 protocol and inform Binance about potential vulnerabilities. After the attack, we immediately disclosed our findings to the Binance security team to prevent malicious actors from exploiting similar vulnerabilities.

First attempt (1st Tx in Fig.5). The first attack (1st Tx, inscriptionID: #46374444) took place on Dec. 7, 2023, at 16:36:58, targeting Binance’s ORDI wallet to inscribe a transfer of 8,196,950 ORDI tokens, the entire balance of the wallet. Given the high mempool congestion (149.48% capacity), we executed the attack using a low-fee and large-amount strategy (200 sats/vB, approximately 0.000278 BTC), significantly lower than the average transaction fee of 0.00051525 BTC [49], to delay transaction confirmation. We provided the attack information below.

Attack	1st Tx
Block ID	#820,107
Transaction ID	8f609c036686f478b6123…291f27479fa9995
Source Address	bc1p7k2nuhqg5anj6ds5…e778x8swgk439 (Taproot address)
Target Address	bc1qhuv3dhpnm0…sd0uhfdu7d (Binance’s ORDI address)
Amount	Input: 0.00028346 BTC, Output: 0.00000546 BTC
Fee rate	200 sats/vB
Fee used	27,800 sats (between fees for Tx1 and Tx2)
Attack result	Fail

The first attack failed due to an unforeseen concurrent transaction. While we initiated the attack to inscribe a transfer of 8,196,950 ORDI tokens, a withdrawal transaction (inscriptionID: #46374443) was simultaneously confirmed, reducing the Binance wallet’s balance by 6,337 ORDI tokens.

This reduction in the wallet’s balance resulted in our attack attempting to lock more tokens than were available in the wallet — specifically, our inscribed amount exceeded the wallet’s remaining total by the amount withdrawn. Since the intended amount to be locked could not surpass the wallet’s actual holdings, the attack was ultimately unsuccessful.

Subsequent attempts (2nd-4th Txs in Fig.5). After the initial failure, we proceeded to launch three successive attacks approximately one hour later. We continued to use an attack strategy with large inscription transfer amounts and low fees. Inscriptions with higher amounts effectively maximize liquidity locking, while low fees prolong the transaction’s presence in the mempool.

At 19:02:21, we initiated our second attack (2nd Tx, inscriptionID: #46385830) using a fee rate of 201 sats/vB and successfully locked 8,210,108 ORDI tokens, nearly the entire balance of the target address. This rendered the withdrawal functionality of the target wallet inoperative, as all tokens were locked in $B_{\text{trans}}^t$.

Subsequently, at 19:11:19, the target address received two consecutive token transfers totaling 5,076 and 1,022 tokens (inscriptionIDs: #46387804 and #46387805). These two transactions appeared to be legitimate inscriptions initiated by Binance. OKLink indicates that the sending addresses are associated with Binance’s internal wallets. The likely purpose of these transfers was to replenish the target wallet’s available balance $B_{\text{avail}}^t$ by transferring additional ORDI tokens to it, thereby restoring withdrawal functionality for users.

Attack	2nd Tx
Block ID	#820,119
Transaction ID	de31d83400784112a3e…7f14087b351971f0e
Source Address	bc1pclw7e5azt70plf…xgesc4jh7s9vta4y (Taproot address)
Target Address	bc1qhuv3dhpnm0…sd0uhfdu7d (Binance’s ORDI address)
Amount	Input: 0.00028146 BTC, Output: 0.00000546 BTC
Fee rate	201 sats/vB
Fee used	27,800 sats
Attack result	Success

We launched the third attack (3rd Tx, inscriptionID: #46389818) at 19:42:02, targeting exactly the sum of the newly received 6,099 tokens, which once again locked all liquidity at the target address.

Concurrently with this third attack, the target address received an additional transfer of 2,683 tokens (inscriptionID: #46391171), prompting us to initiate one more attack (4th Tx, inscriptionID: #46393039) at 19:59:47, with an equal amount of 2,683 tokens.

Attack	3rd Tx
Block ID	#820,123
Transaction ID	b1de4af2a262bf2732f550…750c33e32a32c129e9486
Source Address	bc1ppre27yktdsz34…240c2g504qs403sks (Taproot address)
Target Address	bc1qhuv3dhpnm0…sd0uhfdu7d (Binance’s ORDI address)
Amount	Input: 0.00028346 BTC, Output: 0.00000546 BTC
Fee rate	201 sats/vB
Fee used	27,800 sats
Attack result	Success

Attack	4th Tx
Block ID	#820,125
Transaction ID	fa5680d61e17dde63954…1c149164bbf2e35d0a4b3e1
Source Address	bc1plyms21kqagpm…j0urd128w0vm629 (Taproot address)
Target Address	bc1qhuv3dhpnm0…sd0uhfdu7d (Binance’s ORDI address)
Amount	Input: 0.00014346 BTC, Output: 0.00000546 BTC
Fee rate	201 sats/vB
Fee used	27,800 sats
Attack result	Success

These consecutive attacks completely stripped the target address of liquidity, rendering it unable to perform standard operational transactions, including withdrawals and receipts. We noted that no further transactions occurred at the target address in the Bitcoin network for about 3.5 hours following the attacks. This sequence not only demonstrated the effectiveness of pinning attacks but also highlighted the strategic value of successive attack tactics in practical scenarios.

Liquidity recovery. After we alerted Binance to our white-hat pinning attack on their ORDI wallet, the Binance team promptly undertook measures to restore the wallet’s liquidity at 23:36:11. The recovery approach used by Binance involved initiating a new transfer transaction (Tx2) that corresponded to the original inscribed transaction (Tx1) in the two-step inscription-based transfer.

9OKLink is a blockchain explorer that provides address associations for transactions; see #46387804 and #46387805, respectively.

^During this interval, a normal ORDI transfer transaction (#46382402) occurred.

---

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