DOB

A DOB effectively addresses the fundamental issues of vAMM. Order book does not suffer from long-short imbalances. In the order book model, traders place long or short orders by specifying the exact price at which they wish to enter a trade. The heart of the order book lies in the order matching process. Two traders’ orders “match” when their directions are opposite and their prices overlap. At this point, the two orders are considered to match and the exchange will execute the orders on their behalf. The order book always maintains equilibrium between long and short positions because every matched order involves an equal and opposite order. Conversely, vAMMs have no concept of order matching, and all trades are based on predetermined functions.

Order books can support higher trading volumes more effectively than vAMMs due to their inherent design and functionality. In an order book system, buy and sell orders are matched based on price and quantity, allowing for efficient handling of large volumes of trades. Additionally, the transparency of order books provides traders with a clear view of market depth and liquidity, facilitating better decision-making. In contrast, vAMMs rely on predefined formulas to determine prices and liquidity, which can become inefficient and prone to significant slippage under high trading volumes. The automated nature of vAMMs may also lead to congestion and higher transaction fees during peak times, further limiting their ability to handle large-scale trading efficiently.

Furthermore, the order book can accommodate various order types, including but not limited to stop loss, take profit, and stop limit orders, in addition to limit orders.

We believe that building an order book is crucial to realizing our vision. We have carefully designed our order book to minimize gas costs while maintaining high performance.

Order Book Optimizations

An order book exchange can expect a heavy flow of order insertions and order deletions from market participants. Market makers can easily place and remove tens of thousands of orders throughout the day. For extremely high frequency assets, this number can reach millions. Therefore, we need to optimize for cheaper insertions and deletions.

Order Book Backed By Red-Black Trees

The order book is supported by two augmented balanced Red-Black Trees, one for bids and one for asks. Utilizing a balanced BST ensures that each taker order requires at most O(log n) storage slot accesses and updates to accommodate the insertion and deletion of nodes, where n represents the number of orders in the BST.

Efficient Taker Order Execution

The execution of a taker order can be implemented using delete-up-to operation: delete-up-to(T, k) = an RB tree that equals {v ∈ T | v > k}

It can be shown that the delete-up-to operation requires access to at most 3 lg n + 2 distinct nodes in the tree.

Asynchronous Maker Order Execution

To limit the cost of a taker order, we use a unique design where the execution of maker orders is asynchronous. Maker orders are placed into an on-chain execution queue, and the exchange keeper is responsible for processing them asynchronously.

Continuous Funding Distribution

Instead of tracking a funding distribution factor for each individual position, we implemented an innovative mechanism that uses a common factor to distribute funding to all open positions. This ensures that changes in liquidation price depend solely on price changes and the funding rate, not on the position’s size or collateral. As a result, maintaining separate lists of long and short positions, each sorted by liquidation price, allows funding updates to preserve the order of each list. This optimization significantly reduces gas costs for keeper duties.

Gas Optimizations

Lowering gas costs for the order book operations is critical to ensuring a great user experience. We employ several techniques to reduce the gas costs incurred when interacting with the order book.

Price Tick

Using an entire uint256 to represent a price is inefficient. Instead, we introduced the concept of a price tick to represent prices, which integrates seamlessly into our tick bitmap structure. We implement the tick bitmap as a 256-ary tree of bits, a data structure specifically chosen to minimize the number of storage loads and updates, thereby maximizing gas efficiency. The tick bitmap methods can be implemented such that only three slots need to be loaded and/or updated. This approach significantly reduces the gas costs required for maintaining and executing triggers in the protocol.

We apply some reasonable bounds and restrictions to the allowed prices on the exchange to minimize the storage requirement for a price:

1. The minimum price is 10⁻⁷ and the maximum price is 1 billion, or 10⁹.

2. Only 5 significant figures will be used to represent prices. This amounts to a minimum spread of 0.001%. NASDAQ itself uses 4 significant figures (or a minimum spread of 0.01%), so we believe this is more than enough for Silver Koi V0.

Triggers Organized By Tick Bitmap

Triggers, such as stop-loss and take-profit orders, are organized by price levels and implemented as a linked list of triggers for each tick. We use a tick bitmap to minimize the number of storage loads and updates required to find the next or previous tick for a given tick. More details can be found in our Litepaper.

Batching

In the EVM model, a single transaction experiences numerous forms of gas overhead. Consequently, batching operations into a single transaction can save a significant amount of gas.

We provide batched versions of each order book method: placeOrderBatch, cancelOrderBatch, and replaceOrderBatch.

Order Struct Packing

Information for an order is packed into a single-slot Order struct and is stored in a mapping from order id to the struct.

Please refer to the Litepaper for detailed gas estimates for each method.