
Technical Analysis of Potential Attack Vectors in BRC-20 Wallets
TechFlow Selected TechFlow Selected

Technical Analysis of Potential Attack Vectors in BRC-20 Wallets
Analyze the reasons behind Binance's suspension of ORDI withdrawals systematically, starting from the design principles of BRC-20.
Author: Trustless Labs
After analyzing the BRC-20 code and mechanisms in depth, we identified a potential attack vector during the transfer phase that could target huge holders. In an effort to help exchanges review their operational procedures and uphold white-hat principles, we attempted—using tested methods—to lock the Binance ORDI hot wallet assets, which led Binance to temporarily suspend ORDI withdrawals. We immediately notified the Binance team and shared details of our actions to assist them in restoring withdrawal functionality as quickly as possible. Three hours later, Binance resumed ORDI withdrawals. This article will systematically analyze, from the design principles of BRC-20, the reasons behind Binance's suspension of ORDI withdrawals, helping readers understand how anyone can potentially lock your BRC-20 balance.
First, let’s examine what happened on-chain using UniSat.

This image shows the balance of Binance’s ORDI hot wallet displayed on UniSat at the time of writing, divided into three parts: Transferable, Available, and Balance. These correspond to three fundamental concepts in BRC-20: Transferable balance, Available balance, and Overall balance. The Transferable balance refers to the amount that can be directly transferred out; the Available balance is the portion that can be converted into Transferable balance; and the Overall balance is the sum of the two, representing the total balance held by the address. At this point, you might wonder: if Binance’s ORDI hot wallet has such a large balance, why couldn’t it process withdrawals? Don’t worry—let’s continue exploring.
A BRC-20 transfer requires two steps: first, inscribing a transfer inscription, and second, transferring that inscription to the recipient to complete the BRC-20 transfer. Since inscription transfers are based on UTXO (Unspent Transaction Output), the amount (amt) inscribed in the first step determines exactly how much BRC-20 can be transferred in the second step. Therefore, the previously mentioned Transferable balance is also UTXO-based. To make this clearer, consider the following example: suppose address A is newly created, and you mint m ORDI tokens to address A, or transfer m ORDI from another address to A. At this point, A’s Available balance and Overall balance are both m, while its Transferable balance is 0. Now, if you want to send n ORDI from A to address B, the first step is to inscribe an inscription with amt = n to address A (this inscription is valid only if n ≤ m). After this step, A’s Transferable balance becomes n, its Available balance becomes m - n, and its Overall balance remains m. The second step involves transferring this inscription (with amt = n) to address B. Once completed, A’s Available balance and Overall balance become m - n, and its Transferable balance returns to 0; meanwhile, B’s Available balance and Overall balance become n, with Transferable balance at 0—the transfer is now complete.

Taking the transaction list of Binance’s ORDI hot wallet shown on UniSat as an example, transactions labeled "inscribe-transfer" under Method represent the first step described above, while those labeled "receive" or "send" correspond to the second step. The last two transactions in the figure together form one complete BRC-20 transfer. Additionally, the other three "inscribe-transfer" transactions created inscriptions with amounts of 8,210,108, 6,099, and 2,683 respectively. These three inscriptions collectively constitute the current Transferable balance. Therefore, any outgoing transfer from Binance’s ORDI hot wallet can currently only consist of these three fixed amounts, clearly insufficient to meet diverse user withdrawal demands.
The root cause lies in the fact that anyone can inscribe an arbitrary inscription to any address. As a result, anyone can lock the BRC-20 balance of any address simply by performing the first step of a BRC-20 transfer. So how should Binance resolve this issue? Actually, the immediate fix is simple: by transferring the three aforementioned inscriptions back to itself, Binance can convert the locked Transferable balance back into Available balance. It can then inscribe new transfer inscriptions according to actual withdrawal needs and proceed with transfers. However, this is merely a temporary workaround. To truly solve the problem, the underlying protocol must be improved to address the inherent design flaws in the current BRC-20 standard—only then can such issues be permanently resolved.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News













