BRC-20 Swap: A New Breakthrough in Decentralized Trading and Liquidity

无论铭文还是符文，这些创新的资产发行方式已经非常成熟，从部署到 mint 、转账等平台和工具也十分全面，而流动性一直以来最想解决的问题，目前除了已经上所的铭文符文代币外，其他的都还是只可以在 UniSat 、 OKX 以及 MagicEden 等平台进行订单簿式进行购买或者销售，只可以买卖固定数量的代币，同时如果想购买多个，则需要多笔交易费用。 如果之后这些代币需要有更多的应用场景，Swap 则是最需要先解决的技术。

What is BRC-20 Swap

BRC-20 Swap is a new product launched by UniSat, aimed at allowing users to quickly and easily swap BRC-20 tokens without intermediaries. From October 2023 to May 2024, UniSat continues to promote the development of BRC-20 Swap. In October 2023, UniSat announced the release schedule for BRC-20 Swap and the initial available assets supported at the launch on the mainnet. In April 2024, during the Bitcoin halving, UniSat updated BRC-20 Swap and advanced the standardization work. By May 2024, UniSat announced that the status update of BRC-20 Swap's standardization had been open-sourced and defined the relevant specifications.

The main maintainers of BRC20, ++@unisat_wallet++ and ++@bestinslotxyz++, discussed the new BRC20 "Swap module" upgrade with ++@domodata++ and ++@isabelfoxenduke++ on June 6, which will enable the creation of liquidity pools within the BRC20 protocol. We believe we will soon see the emergence of this functional product.

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 a counterparty but trade with the liquidity pool and obtain calculated prices based on preset mathematical formulas. Similar to the basic concept of AMM in DeFi, slippage refers to the difference between the actual trading price and the expected or quoted price, which usually occurs during high market volatility or low liquidity. Imbalanced trades may result in transaction costs being higher or lower than expected.

A transaction fee of 0.3% is charged for each trade, of which 1/6 goes to the platform, and the remaining portion goes to LPs. LP tokens represent a share of the assets in the pool, and as fees accumulate in the pool, the value of the BRC-20 assets behind the LP tokens will automatically grow, but the impact of impermanent loss on profitability needs to be considered.

User balances are divided into three categories: BRC-20 balance, module balance, and approved balance. A set of operation codes (OPs) is defined to facilitate the transfer of balances between these categories.

• deposit allows users to transfer BRC-20 balance to approved balance.
• approve and conditional-approve allow users to transfer module balance to approved balance.
• withdraw allows users to withdraw module balance to BRC-20 balance.

Once a user's balance enters the approved balance, they can perform swap operations, which will be executed by a sorter through a submit operation. A set of sub-operation codes (Sub-OPs) is defined, allowing 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 amount of sats for each sub-operation code 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 operate independently, with each Indexer only needing to parse data related to the modules of interest while still maintaining BRC-20 balance consistency with other Indexers. The modular expansion of BRC-20 is achieved in the following ways:

In the above image, we can see that each extension module exists independently of the core BRC-20 protocol, with the following advantages:

Permissionless Development: Developing new modules for BRC-20 is a permissionless process, with new modules starting as black modules, naturally separating from the core protocol and other modules.

Isolated Execution: If any module's implementation encounters issues, the isolation between black modules ensures that it does not affect the operation of the core protocol and other modules.

Consensus Upgrade: When the majority of indexers recognize and implement indexing for a specific module, that module can transition to a white module, becoming a natural part of the BRC-20 protocol.

Black Modules: Modules as Black Boxes

When a module operates as a black module, there is a drawback to the modular expansion model, namely the inability to achieve free withdrawals, as shown in the following image:

This is because when a module operates as a black module, the main indexers do not recognize the reliability of its operations. 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 regarded as a valid BRC-20 balance, and the assets within this module cannot be freely withdrawn to BRC-20.

If black modules could arbitrarily expand the BRC-20 protocol, developers might create modules similar to BRC-20 with 100x capabilities, allowing users to receive deposits of a hundred times the amount. For example, if you deposit 5 $ordi, you would 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 Modules: 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 ultimately deemed reliable and transitions to a white module, becoming part of the upgraded consensus. Transitioning to a white module means that its calculated balance is widely recognized and can securely interact with the BRC-20 mainnet. In other words, users can safely, freely, and at any time withdraw to the BRC-20 mainnet (as shown in the image). The fundamental difference between black modules and white modules lies in whether users are allowed to withdraw freely.

Withdrawing Assets from Black Modules

From a functional perspective, a system that only allows deposits without permitting withdrawals is unacceptable. Inspired by the matching mechanism in UniSat Marketplace activities, it dynamically matches user A's withdrawal requests with user B's deposit requests, enabling the system to utilize deposit transactions to meet withdrawal needs. The process is illustrated in the following image:

User A submits a withdrawal request for 80 $ordi, while user B submits a deposit request for 20 $ordi. At this point, the system dynamically matches their needs, using 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 fulfill more withdrawals.

Decentralization

In the early stages of BRC-20 development, UniSat provided users with complete transaction and balance query indexing services, raising concerns about centralization: if the system relies on UniSat for rule interpretation and execution, could UniSat hold some form of centralized power that might lead to the BRC-20 protocol being controlled by a single development team? There are three levels of understanding regarding this issue:

Non-Compulsory: Indexing primarily involves analyzing and organizing on-chain data to make it easier for users to understand, relying on predefined rules of the protocol. It operates on immutable data, unable to change past transactions. UniSat's indexing and execution code is open-source, allowing anyone to inspect it to ensure compliance with BRC-20 rules.

Competition and Robustness: The emergence of multiple indexing service providers increases reliability. Errors in the results of one indexing provider are more easily identified by others. If any indexer stops operating, it will not affect the overall results. In fact, even if all indexers cease to function, BRC-20 can continue to operate robustly, and users can still DEPLOY / MINT / TRANSFER as usual. No critical operations rely solely on indexing support.

Governance and Consensus: Given the participation of multiple indexers in the system, the implemented module mechanism allows different service providers to effectively learn how to govern and expand the BRC-20 protocol in a manageable way.

In the modular architecture, the threshold for service providers to index data is further lowered. In the past, indexers needed to accurately handle all network transactions to be considered valid indexers. Now, they only need to index data within their own black modules to begin providing indexing services, which requires much less effort than processing all BRC-20 data on the network. Therefore, with the widespread adoption of modules, the number of indexers is expected to 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 sparked FOMO in the market, which may promote the entire inscription market. We look forward to the launch of the Swap functionality, making the Bitcoin ecosystem more prosperous and offering more application scenarios.