Whether it is inscriptions or runes, these innovative asset issuance methods are already very mature, and the platforms and tools from deployment to mint, transfer, etc. are also very comprehensive. Liquidity has always been the most pressing issue to be solved. Currently, except for the inscription rune tokens that have been listed, the others can only be purchased or sold in order books on platforms such as UniSat, OKX, and MagicEden. Only a fixed number of tokens can be bought and sold, and if you want to buy more, multiple transaction fees are required. If these tokens need to have more application scenarios in the future, Swap is the technology that needs to be solved first.
What is BRC-20 Swap
BRC-20 Swap is a new product from UniSat that aims to allow users to quickly and easily exchange BRC-20 tokens without the need for middlemen. From October 2023 to May 2024, UniSat continued to promote the development of BRC-20 Swap. In October 2023, UniSat announced the release schedule of BRC-20 Swap and the initial available assets supported in the early stage of the mainnet launch. In April 2024, during the Bitcoin halving, UniSat updated BRC-20 Swap and promoted standardization. By May 2024, UniSat announced that the standardized status update of BRC-20 Swap had been open sourced and the relevant specifications were defined.
BRC20 main maintainers @unisat_wallet and @bestinslotxyz joined @domodata and @isabelfoxenduke on June 6 to discuss the new BRC20 "Swap module" upgrade, which will make it possible to create liquidity pools within the BRC20 protocol. I believe we will see the emergence of this functional product soon.
Technical Details
BRC-20 Swap is an AMM-based DEX that uses the x * y = k formula to maintain the balance of two tokens in the liquidity pool. On this platform, traders do not need to wait for counterparties, but trade with the liquidity pool and receive a calculated price based on a preset mathematical formula. Like the basic concept of AMM in DeFi, slippage refers to the difference between the actual transaction price and the expected or quoted price, which usually occurs when market volatility is high or liquidity is low. Unbalanced transactions may result in higher or lower transaction costs than expected.
A 0.3% transaction fee is charged for each transaction, of which 1/6 belongs to the platform and the rest belongs to LPs. LP tokens represent the share of assets in the pool. As the fees in the pool accumulate, the value of the BRC-20 assets behind the LP tokens will automatically increase, but the impact of temporary losses on profitability needs to be considered.
User balances are divided into three categories: BRC-20 balances, module balances, and approved balances. A set of operation codes (OPs) are defined to facilitate balance transfers between these categories.
deposit allows users to transfer BRC-20 balances to approved balances.
approve and conditional-approve allow users to transfer module balances to approve balances.
withdraw allows users to withdraw module balance to BRC-20 balance.
Once a user's balance enters the authorized balance, they can perform swap operations, which will be executed by the sorter through a commit operation. It defines a set of sub-opcodes (Sub-OPs) that allow users to create and operate trading pairs, including DeployPool, AddLiquidity, RemoveLiquidity, and Swap. Since the sorter is responsible for the final script generation and on-chain execution, the sorter will charge a certain number of sats for each sub-opcode to cover its costs.
UniSat's modular proposal
The modular mechanism provides a new way to support various inscription-based applications within the existing BRC-20 framework. Modules run independently, and each Indexer only needs to parse the data related to the module it is interested in, while still maintaining BRC-20 balance consistency with other Indexers. The modular expansion of BRC-20 is achieved in the following ways:
Permissionless development: Developing new modules for BRC-20 is a permissionless process, and new modules start as black modules, naturally separated from the core protocol and other modules.
Isolated execution: If there is a problem with the implementation of any module, the isolation between black modules ensures that it will not affect the operation of the core protocol and other modules.
Consensus Upgrade: When a majority of indexers agree and implement indexing for a particular module, that module can be transformed into a white module and become a natural part of the BRC-20 protocol.
Black module: module as a black box
When a module is a black module, the modular extension model has a disadvantage that it cannot be freely extracted, as shown in the following figure:
This is because when a module is run as a black module, the main indexer does not recognize the reliability of its operation. To them, this module is a black box and its internal state is not considered a valid BRC-20 state. Therefore, the calculated balance is not considered a valid BRC-20 balance and the assets within the module cannot be freely withdrawn to BRC-20.
If black modules can arbitrarily extend the BRC-20 protocol, developers may create a module like BRC-20's 100x, allowing users to receive a hundred times the deposit amount. For example, if you deposit 5 $ordi, you will receive 500 $ordi. Such unlimited inflation is unacceptable for the core BRC-20 protocol. Therefore, all unverified black modules and their internal mechanisms are considered untrustworthy.
White Module: Consensus Upgrade
When a module is executed in the real world, its behavior gradually becomes reliable. As more indexers gradually accept the behavior of the module, it is eventually considered reliable and converted to a white module, becoming part of the upgraded consensus. Converting to a white module means that the balances calculated by it are widely recognized and can interact securely with the BRC-20 main network. This means that users can withdraw to the BRC-20 main network safely, freely, and at any time (as shown in the figure). The fundamental difference between black modules and white modules is whether users are allowed to withdraw freely.
Extracting assets from black modules
From a functional perspective, a system that only allows deposits but not withdrawals is unacceptable. This was inspired by the matching mechanism in the UniSat Marketplace activity. Dynamically matching user A's withdrawal request with user B's deposit request enables the system to use deposit transactions to meet withdrawal needs. The process is shown in the following figure:
User A makes a withdrawal request for 80 $ordi, while user B makes a deposit request for 20 $ordi. At this point, the system dynamically matches their needs and uses user B's 20 $ordi deposit to satisfy part of user A's withdrawal request (20/80). User B can continue to wait for deposits from other users to realize more withdrawals.
Decentralization
In the early stages of BRC-20 development, UniSat provided users with a complete transaction and balance query index service, which raised concerns about centralization: If the system relies on UniSat for rule interpretation and execution, will UniSat have some form of centralized power that could lead to the BRC-20 protocol being controlled by a single development team? There are three levels of understanding on this issue:
Optional: Indexing mainly involves the analysis and organization of on-chain data to make it easier for users to understand and relies on the predefined rules of the protocol. It operates on immutable data and cannot change past transactions. UniSat's indexing and execution code is open source and anyone can check it to ensure it complies with BRC-20 rules.
Competition and robustness: With multiple indexing service providers, reliability is increased. Errors in results from one indexing provider are more easily identified by other providers. If any one indexer stops working, it does not affect the overall results. In fact, even if all indexers stop working, brc-20 can continue to run robustly and users can still DEPLOY/MINT/TRANSFER as usual. No critical operations rely solely on index support.
Governance and consensus: Given that multiple indexers participate in the system, the modularity mechanism implemented allows different service providers to effectively learn how to govern and scale the brc-20 protocol in a manageable manner.
In the modular architecture, the threshold for service providers to index data is further lowered. In the past, indexers were required to process all network transactions accurately to be considered a valid indexer. Now, one only needs to index the data in their own black module to start providing indexing services, which is much less effort than processing all the brc-20 data on the network. Therefore, as the module becomes more widely adopted, it is expected that the number of indexes will increase significantly, and some services may gradually evolve to provide comprehensive data indexing.
Recently, UniSat’s airdrop of the first five-character BRC-20 inscription $pizza has caused fomo sentiment in the market, which may have a promoting effect on the entire inscription market. We look forward to the launch of the Swap function module in the future, making the Bitcoin ecosystem more prosperous and having more application scenarios.
