General architecture overview
CLOB DEX - Permissionless, decentralized exchange protocol with automated orders built on top of Stellar. It uses an on-chain order book to provide a platform with a matching engine, shared asset pools, and settlement on-chain. Using automated orders opens infinite trading possibilities.
This platform will require a decentralized architecture and will be deployed both on-chain and off-chain. Here is the detailed diagram showing the CLOB DEX solution design.
Front-end
Trading view(1a)
Web interface is the entry point to our platform from the user's point of view. The platform provides a full trading experience, which should not be very different from the one in centralized exchanges. Using the React library, we create a modern web application whose main goal is to provide trading functionality. For the Web3 experience, we use the js-stellar-SDK library, which provides the ability to connect to the wallet and perform smart contract interaction.
Onchain components
Soroban DEX smart contract(1b)
The Soroban DEX smart contract plays a very important role in the CLOB DEX architecture. A smart contract would be created using the Stellar Soroban platform, which provides an SDK for the creation and deployment of smart contracts written in the Rust programming language.
This smart contract would have the following functionality:
Accept user deposits
Execute trades of the user's order.
Allow withdrawal of the funds.
While the deposit and withdrawal functionality seems pretty straightforward, the trade execution could be more questionable.
As you probably already know, very mutable operations on the blockchain will require the user to confirm using his wallet and pay some amount of gas. Using the built-in Soroban SDK cryptographic primitives would provide a seamless trading experience for the user. The main idea here is to create a custom trading key for the user. The public part of this would be stored in our smart contract and used for signature verification.
Matching engine(2a)
Designing an order book and matching engine based on the Order Statistics Tree Library involves efficiently structuring smart contracts to store, manage, and match orders.
Smart Contract Modules
OrderBook Contract:
Implements the Order Statistics Tree data structure to manage buy (bid) and sell (ask) orders.
Supports the insertion and deletion of orders, maintaining the tree's balanced structure to ensure efficient access and updates.
It provides functions to query orders based on price or rank, such as finding the best available bid or asking price or retrieving orders by their position in the book.
Matching Engine Contract:
Responsible for matching buy and sell orders according to price-time priority.
Interacts with the OrderBook contract to fetch orders and update the book post-matching.
Handles trade execution logic, ensuring that trades are carried out at fair prices and updating the OrderBook accordingly.
Emit events to generate delta balances.
Order Management Contract:
Get orders from the Order manager.
Validates order parameters (e.g., price, quantity, order type, ID) and user permissions (sufficient balance, ownership via validation ZKP signature).
Interfaces with the OrderBook contract to insert or remove orders.
Data Structure
For handling the orderbook, we need an efficient data structure and search mechanism to store a balanced orderbook; the best option for us is Red-Black Tree.
A Red-Black Tree is a self-balancing binary search tree, a data structure for organizing comparable data, such as numbers or text strings. It provides efficient search, insertion, and deletion operations. The "Red-Black" refers to the key feature of the tree: each node in the tree is colored either red or black, and the color is used to ensure the tree remains approximately balanced.
A Red-Black Tree ensures that no path from the root to the leaf is more than twice as long as any other, which means the tree remains approximately balanced. This balance is needed for maintaining good performance - specifically, O(logn) time complexity for searches, insertions, and deletions, where n is the number of nodes in the tree.
Red-Black Trees are well-suited for building order books due to their ability to maintain a balanced tree structure, ensuring efficient operations. The key reasons why Red-Black Trees are good for building order books include:
Efficient Search, Insertion, and Deletion: Red-Black Trees provide capabilities to the orderbook to rapidly update to reflect incoming orders, cancellations, and trades updates. The ability to quickly find the best bid, ask prices, and insert and remove orders is key.
Self-balancing Nature: The self-balancing properties of Red-Black Trees ensure that the tree remains balanced with every insertion and deletion, preventing the tree from becoming too skewed or unbalanced.
Ordered Data Structure: Being a binary search tree, a Red-Black Tree maintains elements (orders in the case of an order book) in a sorted order.
Fairness and Transparency: ThenRed-Black Tree ensures that orders can be processed fairly and transparently, according to their prices and times of entry.
Third-party components
Stellar node(1c)
Using our smart contract as a key part of the system requires us to somehow track what's going on there and correctly respond to changes. To do so, we will run our own or use the provider's Stellar Node, which gives us access to all data in the Stellar network. Because we are not interested in all data from the Stellar network but only in the one related to our smart contract, we would need anything in addition to this.
Quasar Indexer(1d)
As stated in the previous section, we need to keep track of changes and actions taken with our smart contract. To achieve this, we use the Quasar Indexer open-source project, which allows us to filter from the whole data in the Stellar network and listen only to changes related to the Soroban platform and our smart contract in particular. It provides a very suitable GraphQL API, which allows data retrieval based on different filters. In our case, we will listen to the events emitted by our smart contract and push them to the dedicated services.
Back-end components
Risk engine(2b)
Using the risk engine, we would cover the scenarios for double spending, early withdrawal, and futures trading liquidations. Using the best practices in the industry and our in-house algorithms, the service's main goal is to double-check for fraudulent behavior and warn of criminal acts.
Operator Manager(3a)
This service is the bridge between the user and our smart contract. Using the contract ABI and the Soroban SDK, the smart contract's specific actions(withdrawal execution, trade execution, signature verification) will be prepared and sent for execution.
Event fetcher(3b)
The main goal of this service is to periodically pull from the Quasar Indexer(1d) events emitted by our smart contracts and push them to the Risk engine(2b) for verification. Later, based on this data, the Ririskngine will call the Opoperator manager a) to bypass particular actions in the smart contract.
Last updated
