Technical Overview v1
Code snippets capturing the core logic behind order placement, matching, finalisation, and settlement in Fermi DEX v1
Introduction
You can learn more about the technical architecture on the following pages: Key Data Structures Instructions Events
SDK Here we outline the order flow process with simplified code snippets, illustrating the core logic behind the implementation of Fermi's intent-based DLOB.
Order flow Logic
1. Order Placement
When placing an order, 1% of the order value is deposited as security to ensure credibility. The remaining amount of tokens needed for the trade are delegated from the user to the Market Authority, to be conditionally transferred later if the order is filled. A counter is maintained to account for cumulative approvals of a token for a user across all of their open orders on a market.
In case of a limit order, the user's position (tokens deposited & tokens approved) is recorded in their user-specific openOrders struct. In case of a taker order the order is immediately filled and added to eventQ, or cancelled.
2. Order Matching Engine
Any limit orders placed are matched against the opposing bookSide to see if they can be partially or fully filled:
The following depicts key parts of the matching code (book.new_order):
If an order is partially or fully filled, a fillEvent is generated and added to the EventQueue. This fill event contains all the information needed to "Finalize" the order, and execute just-in-time transfers from both counterparties.
3. Order Finalization
Can be called by either counterparty/ a third party "cranker". Unlike Openbooks' consume_events function, this is an atomic function, so a trade can be finalised sequence independently, even if there are other matched orders before/after this order on the eventQueue that have not yet been finalized.
A. atomic_finalize_events
Accounting
After executing just-in-time transfers from both parties, their openorders balances are updated to reflect the completed trade:
B. atomicFinalizeEventsDirect
This function is used to conduct JIT transfers directly into each counterparties' wallet, without using the intermediate openorders for accounting. The purpose of this is convinience for taker orders, and easier integration with aggregators.
4. Handling Settlement Failure: Cancel With Penalty
Last updated