Last updated
In the realm of order-book based DEXs, the dynamics of Ask and Bid orders form the cornerstone of operations. For buyers, taking an Ask Order in the marketplace swiftly meets their purchase requisites. Concurrently, for sellers, taking a Bid Order in the marketplace facilitates a swift satisfaction of their selling requisites. It's only when an order-book based DEX proficiently accommodates both Ask and Bid orders can it optimally cater to the fundamental requisites of both buying and selling parties.
Nonetheless, when the discourse shifts to the Bitcoin network, not every DEX on this network is equipped to offer this foundational feature. Predominantly, DEXs established on the Bitcoin network, be they harnessed on the native network or leveraged through sidechain technologies, are often found to extend solely the Ask Order service to its users.
This scenario manifests a severe imbalance in the trading experience for sellers. An Ask Maker, post crafting an Ask, is poised against a myriad of impediments sprung from uncertainties. Foremost among these is the protracted and stochastic wait prior to the fruition of an Ask order. This waiting period is rife with uncertainties, as no one can ascertain when the conceived Ask order will come to fruition. Should market conditions oscillate during this waiting period, the initially conceived Ask order stands a chance to be supplanted by other orders, consequently lagging in the UI display. This undeniably exacerbates the duration and uncertainty of the waiting period.
So, what are the underpinnings that preclude a majority of Bitcoin network DEXs from supporting Bid Orders?
To dissect the issue at hand, a primer on a core concept within the Bitcoin network—UTXO, or Unspent Transaction Output—is requisite.
UTXO symbolizes the available funds within the Bitcoin network. Transactions within this network do not adhere to a simplistic model of funds transfer from entity A to entity B; rather, it encapsulates a model where funds transit from one or multiple inputs to one or multiple outputs. Inputs are unspent outputs from previous transactions, while outputs delineate new UTXOs.
A simplified exemplification would be: assume user A possesses 3 Bitcoins, all stored within a singular UTXO. We can envisage this UTXO akin to a full-value banknote denominated at 3 Bitcoins. Now, user A decides to expend 2 Bitcoins to pay user B.
However, within the Bitcoin network, partial consumption of a UTXO is not permissible; it necessitates a full consumption.
At this juncture, user A constructs a new UTXO of 2 Bitcoins, locking it to user B's address, thereby accomplishing the payment process to user B.
But since user A initially had 3 Bitcoins and only intended to pay 2, what becomes of the remaining 1 Bitcoin? User A crafts yet another new UTXO, this one denominated at 1 Bitcoin, and locks it to his own address.
Consequently, the residual 1 Bitcoin reverts to user A's account as a new UTXO. This transactional process mirrors a scenario where user A hands over a 3-Bitcoin banknote to user B, and in return, user B provides a 1-Bitcoin banknote as change to user A.
The UTXO model is an inextricable transaction model within the Bitcoin network, which implies that DEXs constructed on the Bitcoin network's framework cannot circumvent the logic of UTXO, be it for ASK or BID orders.
The feasibility of ASK orders on various DEXs is largely attributed to the transaction model of the Bitcoin network, wherein UTXOs of BRC20 tokens and Bitcoins can be provided by the Ask Maker and Taker respectively, and encapsulated within corresponding Inputs and Outputs. This process, along with its logic, is relatively straightforward.
On the contrary, the construction of BID orders is not as facile. BID necessitates the instantaneous matching of Bitcoin's UTXO and BRC20's UTXO at the time of order creation. For order-book type DEXs, this requirement is somewhat lofty. No DEX can guarantee a reservoir of funds that can cater to a seemingly boundless demand for UTXOs. This not only necessitates a considerable financial reserve on the part of the DEX but also calls for a diverse array of reserve types.
So, how was the world's first BID system supported by the Bitcoin native network constructed amidst such circumstances? The answer lies in Orders' proprietary development of the world's first liquidity pool solution based on the Bitcoin native network—PSBT Liquidity Pool, abbreviated as P-LP.
We will focus on delineating the distinctive and groundbreaking features of P-LP to avoid delving too deeply into complex technical knowledge. The technical principles of P-LP will be expounded in a subsequent article.
P-LP, being the first of its kind built on Bitcoin's native network, embraces the core attributes of complete decentralization, trustlessness, and risk-free operation. Through this liquidity pool solution, Orders can acquire sufficient UTXOs from liquidity providers to bolster the BID Order system, morphing Orders into an order-book type DEX that fully supports both ASK and BID Orders.
P-LP affords users the capacity to provide liquidity without exposing them to risks. Courtesy of the underlying PSBT and MutiSig technologies of P-LP, the liquidity provided by users remains in their wallets until utilized, with users retaining full control over these assets. In other words, as long as the liquidity hasn't been tapped into, users can autonomously manage, transfer, or sell these assets.
Post utilization of liquidity, assets are transferred to a multi-signature address co-managed by Orders and the user, thereby ensuring asset security. Upon a user's release of this liquidity, a signing process is undertaken by both the platform and the user to facilitate asset transfer. The induction into a multi-signature address signifies that the platform lacks the authority to independently transfer these assets, as every operation necessitates multiple signatures for completion.
Moreover, users are rewarded with liquidity rewards by the platform upon releasing liquidity.
Essentially, Orders' P-LP enables users to provide liquidity to Orders in a decentralized and trustless manner, bereft of financial risks, thereby propelling the operation of the world's first BID system supported by the Bitcoin native network.
This transaction mechanism is also compared to AMM, known as DIMM (Decentralized Instant Market Maker) mode, which provides users with a trading experience similar to smart contracts on Bitcoin.
Leveraging its technological prowess, Orders has orchestrated a highly decentralized environment, harmonizing liquidity providers, BID Makers, and BID Takers into a unified system. They morph into distinct pivotal roles within the system, engendering the world's first BID system supported by the Bitcoin native network, which in turn, has emerged as one of the core feature functionalities of Orders.
