Full Report
BRC20 tokens are a non-fungible asset on the Bitcoin network. The tokens are embedded into a Satoshi using Ordinal Theory. The ordinals protocol can assign more information on top of a satoshi called an inscription. The Satoshis each have an ID, which is ordered by how they were mined on the Bitcoin network. The Ord data is stored in a Taproot script-path spend script. The Ord is the reference of a particular Satoshi. The Inscription is the information about the token itself, which can be an image, text, or anything else. Commonly, the metadata is stored in the witness data of the transaction. It should be noted that the Bitcoin itself hasn't changed - just how people are viewing said Bitcoin. BRC20 has three operations: deploy, mint (create) and transfer. The inscribed operations are not executable actions. They leverage the OP_RETURN OPCODE in a bitcoin transaction that is not spendable then add arbitrary data to the end of the script, called an Inscription which contains a JSON payload to specify what is happening. The transfer requires two transactions: Inscribe the JSON-style content into a satoshi marked with a unique sequence number. This is sent to yourself. Execute the actual transfer by sending the previous inscription to the receiver. The BRC20 token balance structure has three values: available balance, transferrable balance and overall balance. Available balance is what a user can freely spend. Transferrable balance is a token that has been inscribed in a token transfer but hasn't been sent to the user yet. The overall balance is just the sum of these two. I don't fully understand how this system works tbh. Here are a two articles: one and two. The attack targets the transferable balance field. When a token transfer is initiated via an inscription, the tokens move from available to transferrable, waiting for pending transactions to be confirmed. First, an attacker sends a bunch of false transfers from the target to the user. When doing this, they make the first tx with the inscription update happen but make the second one have a very low fee to guarantee it will not happen for a long time. By doing this, the system is locked up. The requests for usage appear to require sequential transactions. So, if there's a transfer happening to you then you are unable to perform any actions. By intentionally getting the transactions stuck for long periods of time, it locks your targets wallet as well. They ran this locally then on a popular wallet used on Binance. I personally think that testing a live system like this without notifying the party first is completely unethical. I'm still confused on how the tracking of BRC20 tokens works. None-the-less, this was an interesting vulnerability that abused multiple parts of how Bitcoin and BRC20 function, which is cool. This was a systemic issue on Bitcoin which is pretty crazy. Overall, I wish more context was provided on token tracking but an interesting vuln!
Analysis Summary
# Vulnerability: BRC20 Pinning Attack (Liquidity Lockup)
## CVE Details
- **CVE ID**: Not yet assigned (Research published Oct 2024 - June 2025)
- **CVSS Score**: Estimated 7.5 (High)
- **CWE**: CWE-664: Improper Control of a Resource Through its Lifetime; CWE-400: Uncontrolled Resource Consumption (Mempool Pinning)
## Affected Systems
- **Products**: Bitcoin BRC20 Token Protocol and compatible platforms (e.g., Ethscription, BSC20, SOLs).
- **Versions**: All implementations utilizing the two-phase "Inscribe-then-Transfer" mechanism.
- **Configurations**: Hot wallets (notably Binance ORDI hot wallet), BRC20 indexers, and any service requiring sequential transaction processing for BRC20 assets.
## Vulnerability Description
The BRC20 protocol requires a two-step process to transfer tokens:
1. **Tx1 (Inscribe):** The user sends a transaction to themselves to inscribe a "transfer" JSON payload, moving tokens from "Available" to "Transferable" balance.
2. **Tx2 (Transfer):** The user sends the inscribed satoshi to the recipient to finalize the move.
The vulnerability stems from an inherent design flaw in how these transactions are sequenced and fee-weighted. An attacker can initiate a flood of "false" transfer inscriptions (Tx1) targeting a specific wallet. By setting a very low fee for the subsequent transfer (Tx2), the attacker ensures Tx2 remains "pinned" in the mempool indefinitely. Because BRC20 indexers often require these operations to be processed sequentially or because the tokens are moved to a "Transferable" state (locked), the target's liquidity is frozen. The attacker exploits the fee asymmetry where Tx1 is confirmed but Tx2 is intentionally stalled.
## Exploitation
- **Status**: PoC available; verified via controlled exploitation on live exchange environments (Binance).
- **Complexity**: Medium
- **Attack Vector**: Network (Bitcoin Mempool / P2P Network)
## Impact
- **Confidentiality**: None
- **Integrity**: Low (Balances are not stolen, but the state is manipulated)
- **Availability**: High (Total loss of access to BRC20 funds; "Liquidity Lockup")
## Remediation
### Patches
- **Protocol Update**: There is no direct "patch" for the Bitcoin network itself. However, BRC20 indexers and protocol maintainers must update the logic for how "Transferable" balances are calculated and timed out.
- **Exchange Updates**: Binance and other exchanges have implemented internal logic to better handle incoming BRC20 inscriptions to prevent automated wallet locking.
### Workarounds
- **RBF (Replace-By-Fee)**: Users can attempt to use RBF to increase fees on stuck transactions, though this is difficult if the attacker controls the initial inscription.
- **Manual Indexer Intervention**: Indexers can implement rules to ignore inscriptions that haven't been spent/transferred within a certain block window.
- **CPFP (Child Pays For Parent)**: Attempting to "push" the transaction through by spending the output in a high-fee child transaction.
## Detection
- **Indicators of Compromise**:
- A sudden influx of small BRC20 "transfer" inscriptions sent to a wallet from unknown addresses.
- Large "Transferable" balance relative to "Available" balance that remains static for many blocks.
- **Detection Methods**: Monitoring the mempool for BRC20 transfer transactions with intentionally low fee rates (sats/vB) that target high-volume hot wallets.
## References
- **Research Paper**: `https://arxiv.org/abs/2410.11295v3`
- **Protocol Info**: `https://domo-2.gitbook.io/brc-20-experiment/`
- **Market Data**: `https://www.brc20.io/`