Author: Trustless Labs
After in-depth research on the BRC-20 code and mechanism, we found potential attack methods against huge holders during the transfer phase. In order to help exchanges check for process specification issues and also practice white-hat spirit, we attempted to use tested methods to lock the assets of Binance's ORDI hot wallet, leading to Binance suspending ORDI withdrawals. We promptly notified the Binance team, communicated the operation details to help Binance resume withdrawals as soon as possible, and three hours later, Binance resumed ORDI withdrawals. This article will start from the design principles of BRC-20, systematically analyze the reasons for Binance's suspension of ORDI withdrawals, and help everyone understand why anyone can lock your BRC-20 balance.
First, let's take a look at what happened on-chain on UniSat.
This is the Binance ORDI hot wallet balance displayed on UniSat at the time of writing, divided into three parts: Transferable, Available, and Balance. This involves three basic concepts in BRC-20: Transferable balance, Available balance, and Overall balance. Transferable balance refers to the balance that can be directly transferred out, Available balance refers to the balance that can be converted into Transferable balance, and Overall balance is the sum of the previous two, representing the current address's total balance. At this point, you may wonder, since the current Binance ORDI hot wallet has so much balance, why can't it be withdrawn? Don't worry, let's continue reading.
BRC-20 transfers require two steps: first, inscribe a transfer's Inscription, and second, transfer this Inscription to the recipient to complete the BRC-20 transfer. Since Inscription transfer is based on UTXO, that is, the amount of Inscription inscribed in the first step is the amount of BRC-20 that can be transferred in the second step, so the previously mentioned Transferable balance is also based on UTXO. To help everyone understand, let's take an example. Suppose A is a newly created address, and then you mint m ORDI to address A, or transfer m ORDI from another address to address A, at this time, A's Available balance and Overall balance are both m, and Transferable balance is 0. Then, we transfer n ORDI from address A to address B. In the first step, inscribe an Inscription with an amount of n to address A (this Inscription is valid only when n = m), at this time, A's Transferable balance is n, Available balance is m - n, Overall balance is m; in the second step, transfer this Inscription with an amount of n to address B, at this time, A's Available balance and Overall balance are both m - n, Transferable balance is 0, B's Available balance and Overall balance are both n, Transferable balance is 0, and the transfer is completed.
Taking the Binance ORDI hot wallet transaction list displayed on UniSat as an example, the Method in the image corresponds to the first step operation mentioned above as inscribe-transfer, and the Method as receive or send corresponds to the second step. The last two transactions in the image together form a complete BRC-20 transfer. In addition, the three inscribe-transfer transactions inscribed Inscriptions with amounts of 8,210,108, 6,099, and 2,683, which together form the Transferable balance. So if you want to withdraw ORDI from the Binance ORDI hot wallet now, you can only withdraw the three corresponding amounts of ORDI, which cannot meet the diverse withdrawal needs of users.
The reason for this situation is that anyone can inscribe any Inscription to any address, so anyone can lock the BRC-20 balance of any address by executing the first step of the BRC-20 transfer. So how should Binance solve the current problem it faces? In fact, it's simple, just transfer the three previously mentioned Inscriptions to yourself, which can turn Transferable balance back into Available balance, and then inscribe the corresponding amount of Inscription to withdraw according to the user's withdrawal needs. However, this can only solve the immediate problem and cannot fundamentally solve the problem. Only by improving the protocol itself and addressing the existing flaws in the BRC-20 design can the problem be permanently resolved.
免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。