Architecture
The architecture of Fermi DEX resembles Openbook/Serum at a high level, with many fundamental changes - such as updated internal accounting, PDA structure and ownership.
Last updated
The architecture of Fermi DEX resembles Openbook/Serum at a high level, with many fundamental changes - such as updated internal accounting, PDA structure and ownership.
Last updated
Fermi DEX's on-chain programs are built from a heavily modified, anchor-compatible fork of Serum. To enable all the new capital efficiency oriented features, the internal accounting was redesigned from the ground up. On this page we provide a high level overview, and we dive into specific concepts in the following pages.
An order placed on Fermi DEX follows a slightly different path than an order on a traditional on-chain CLOB, like OpenBook. In some ways, the JIT liquidity abstraction mechanisms provide a similar user feel to centralised exchanges, however, Fermi DEX executes entirely on decentralised rails.
As shown, newly placed orders are stored in the Orderbook (i.e., bids and asks PDA). When a match is found (see Matching Logic), the order is added to the eventQueue, with the "filled" status. Thereafter, any user may choose to atomically finalise a filled transaction in the eventbook, using finaliseMatch.
At this stage, just-in-time liquidity is debited from both counterparties to the trade. If successful, the traded balances are credited to the parties, and the trade is changed to a "finalised" status.
The following diagram shows the flow of an order in a bit more detail. As seen, limit orders are first tested against the best offer from the takers. If it matched, the trade moves directly to the Filled stage, bypassing the orderbook. Otherwise, the order (or any unfilled portion of the order) is posted on the orderbook, to be matched against future orders.
At the order placement stage, the program checks whether you have enough liquidity to fill this trade, were it matched immediately. This check is performed against a cross-market abstracted total of liquidity that you have supplied to the protocol so far. If liquidity supplied is insufficient, the program will attempt to "approve" the required liquidity from your wallet. Later, if the trade is filled, either counterparty can call "finaliseBid" and finaliseAsk" to make the just-in-time transfers from both counterparties. If the trade is finalised, the traded tokens will instead be available for immediate withdrawal. If one of the counterparties' fails to supply liquidity, the others funds will be unlocked and available for instant withdrawal. Thus, there is no period during which any deposited liquidity is inaccessible on Fermi DEX.
Here we discuss a few interesting quirks of designing a JIT based orderbook system. Feel free to skip if this background doesn't interest you. From a birds eye perspective, here are some of the key changes that enable JIT and liquidity abstractions:
Updated NewOrder method, and underlyingnew_bid , new_ask methods under the Orderbook implementation. Significant changes to the internal accounting were made to enable JIT. In addition to interactions with the updated OO accounts, we ensured that any deposits update the unlocked balances, instead of the locked balances.
New FinaliseOrder Method. Analogous to 'cranking' in Openbook, FinaliseOrder is the step in the trade lifecycle where Just-In-Time liquidity is implemented. It accepts two events with the same orderId, and atomically executes the match by JIT'ing liquidity from both counterparties to each other's OOAbs balances.
Further, we will also implement ZeroCopy on the following accounts: EventsQueue, Bids, Asks, OO : To scale the amount of information these queues hold, we implemented zero-copy.
We dive deeper on how each of these changes work together to produce the features of Fermi DEX in the following sections.
