Comment on page
DEX and Swap
Ethereum's ecosystem has thrived and become the de facto standard in the blockchain industry. It is based on the Ethereum Virtual Machine (EVM), which supports Turing-complete smart contracts. Built on this foundation, Ethereum has created a flourishing ecosystem of ERC20 tokens and DeFi applications, attracting a large number of builders.
Decentralized finance (DeFi) aims to solve two fundamental problems: asset ownership and identification, and decentralized asset trading. Only by addressing these core issues can a solid foundation for DeFi be established.
The lack of widely accepted protocols to build the foundation has been a limiting factor for the development of the Bitcoin ecosystem. Now, with the Ordinals protocol addressing asset ownership and identification, and the PSBT improvement protocol addressing the need for atomic swaps, we can believe in the wide and solid underlying value of Bitcoin. The story of the Bitcoin ecosystem is bound to be magnificent.
Transactions based on the PSBT improvement protocol are atomic swaps, which are crucial for achieving trustless decentralized trading. The general process of an atomic swap is as follows: the seller constructs an input pointing to their Ordinals token, then creates a seller's receiving address specifying the amount of BTC to be received, signs the transaction, and passes the PSBT to the buyer. The buyer constructs an input pointing to their unspent BTC (UTXO), creates two outputs: one for their change and one for the seller's Ordinals token receiving address, and then signs the transaction. Finally, the finalized transaction is broadcasted, completing the trade and achieving full trustlessness.
When a user adds liquidity, they are actually creating a Partially Signed Bitcoin Transaction (PSBT). The PSBT created by the user is an incomplete transaction that, technically, requires the conditions set by the initiator to be met in order to be completed. Therefore, the PSBT is currently in a pending state. The PSBT can only be confirmed on the blockchain when the conditions set by the initiator are met. Until then, the PSBT can be safely sent off-chain.
Think of it like the user writing a check for BRC-20 tokens, stating how many tokens they are willing to provide and how much Bitcoin they want to receive in return. However, since the transaction has not been completed, the check has not been submitted to the bank and the user can cancel it at any time. So, the tokens will not be transferred from the wallet until the transaction is truly completed. Technically, the PSBT can be seen as the expectation for a transaction from creation to fulfillment and confirmation on the blockchain, which exists off-chain. During this period, the assets have not left the user's wallet. The transaction is considered complete and the asset exchange takes place only when the buyer meets the expectation and obtains blockchain confirmation. This is somewhat similar to the concept of a flash loan in Ethereum smart contracts. Due to the atomic nature of the order, the exchange of tokens and BTC either happens simultaneously or not at all. This means that the check can circulate before it is submitted to the bank, and the signature mechanism and features of PSBT ensure that it cannot be tampered with.
Since the PSBT represents the off-chain expectation of a transaction, withdrawing liquidity simply means making the PSBT no longer public. As long as the PSBT is withdrawn from the liquidity pool, no one can fulfill the PSBT and complete the transaction, as no third party other than the DEX has access to the PSBT. If a user wants to completely invalidate the PSBT, they can initiate a transaction to themselves and send the assets signed in the PSBT back to their own wallet.
Based on the description above, we know that by utilizing PSBT and multi-signature functionality, it is possible to achieve a fully trustless BRC20 liquidity pool. When users provide liquidity, they are actually providing PSBT single-signature assets with outputs pointing to a multi-signature address shared between the user and the exchange. This design ensures that the exchange cannot directly cash out the PSBT and take away the user's assets.
For liquidity providers who are not willing to give excessive trust, they can offer one-way liquidity from BRC20 to BTC. In this case, the exchange does not have the ability to unilaterally steal any assets. For liquidity providers who are willing to give a certain level of trust, they can provide two-way liquidity. In this case, the exchange does not have the incentive to maliciously cash out BTC for BRC20 PSBT. For this type of liquidity provider, the exchange will offer higher rewards.