Product Architecture

4. Product Architecture

On product architecture, we have 3 major objectives - (1) solving the order book UTxO contention issue, (2) concentrating protocol liquidity and (3) maintaining the fairness of order processing. DeltaDeFi aims to build an infrastructure compatible with UTxO blockchains. Considering the technical nuances among different blockchains within the UTxO ecosystem. The below architecture description will be based on the technical details of our first implementation on the Cardano blockchain. In this session, we will describe how we designed the product on the Cardano eUTxO model to achieve all 3 of the objectives.

4.1. Solving Order Book UTxO Contention

Building decentralized applications on the UTxO model must solve the UTxO contention issue - where there are possibilities of multiple parties attempting to consume the same UTxO. In that case, only one of those attempts would eventually succeed. Although it would not cause any loss of funds, leaving the UTxO contention issue unresolved would hugely undermine the user experience.

The UTxO contention issue is even more critical in DeltaDeFi VOB architecture’s transaction throttling, where the system would hold up signed transactions. In that base setting, any user actions spending the input UTxO would make the throttled order invalid. Even if we assume zero cost in syncing with the blockchain state in real-time, there is still a window of block processing time to undermine the finality of order matching (i.e. users have to wait till blockchain confirmation to get confidence in passing the order). DeltaDeFi faces contention issues in 2 aspects - (1) contention between application actions and users' actions outside of the application and (2) contention among various application actions. We have in turn developed the below solutions to tackle the contention issues.

4.1.1. Account layer to solve contention with other wallet actions

We introduced a smart contract account layer, where users have to deposit their funds into the “account” before trading on DeltaDeFi protocol. It could prevent users from innocently signing other transactions and voiding the throttled transactions.

4.1.2. Emergency action mechanism to solve withdrawal contention

DeltaDeFi’s users can withdraw any funds out of the protocol without permission from DeltaDeFi. However, bad actors might take advantage of the non-custodial nature of the protocol to undermine other users’ order finality. Thus, DeltaDeFi has introduced the emergency withdrawal mechanism, where users have to conduct multiple steps before withdrawing funds outside of the protocol in a fully permissionless manner. Meanwhile, the DeltaDeFi team remains in control of tying the order-matching engine priority with on-chain status. As a result, we retain the necessary power for each party to pursue the pure efficiency of the protocol.

With such architecture, DeltaDeFi could provide high confidence to users that their order could be successful at the time of sending a request to our matching engine. In simple words, we move the blockchain confirmation from “confirmation event” to “settlement event”, while users can have a highly assured confirmation just by API response itself.

4.2. Protocol Liquidity Concentration

Spinning up an order book from its inception is difficult, especially in a relatively unexplored market like UTxO blockchains. The single most important blocker for an order book to become successful is the liquidity of the book. Without sufficient liquidity, sophisticated traders lack opportunities to profit from trading on book, while vanilla users face a huge bid-ask spread which might make their trade less attractive or even cost-prohibitive. Therefore, DeltaDeFi takes reference from our established financial markets and employs 2 major methodologies to concentrate liquidity.

4.2.1. Standardized and Layered Order Size

Taking wisdom from traditional financial markets, we standardize the size of each trading pair for the users. It could help facilitate the coincidence of wants from buyers and sellers with similar desired trading sizes. From the blockchain point of view, this architecture could also prevent the issue of UTxO dust from happening (i.e. leftover small orders that would not be taken by anyone when the protocol fee overrides the trading utility). With this design, a derived issue is that the size chosen might favor either small-size traders or large-size traders. With this in mind, we also provide layered order sizes, where users can choose the layer with a size suitable for them to trade.

4.2.2. Batcher-less Batching at Order Matching

The VOB design allows liquidity takers to sign the exact transaction that settles the trade. To reduce the friction of taking orders, the protocol is also designed with the capability to allow batched liquidity taking, where one liquidity take can take up to 10-20 orders at signing the single transaction. It could help incentivize more people trading on the protocol and hence enhancing the liquidity.

4.3. Order Processing Fairness

While the VOB is powerful at providing pure efficiency to traders, DeltaDeFi indeed retains the discretion to process the orders. In the previous session, we covered the high-level mechanism to retain protocol governance. Here we cover the technical procedure where we could produce a fair order processing backend.

4.3.1. Single priority rule handling all orders

As aforementioned slightly, for each trading pair, we would have a single priority rule covering all order requests (post order, take orders, and cancel order). We would in no circumstances process orders deviated from the priority rule. If any unexpected issues are happening, they will be mitigated by our protocol governance procedures.

4.3.2. Single blocking thread processing same trading pairs

When handling different orders from the same trading pairs, the backend would have a single blocking thread processing orders. It could avoid unexpected overrides and retain the priority of orders strictly in compliance with the rule set out.