# Architecture

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.

## Order stages

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.

<figure><img src="https://2294933522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FewLyC4ny0ztkYYXokV4j%2Fuploads%2F9h7Pajk2s38xR1qNUt85%2FScreenshot%202023-03-13%20at%201.21.16%20pm.png?alt=media&#x26;token=68a44551-6743-4b45-b1eb-5d32791ad933" alt=""><figcaption><p>Simplified schematic of order stages</p></figcaption></figure>

As shown, newly placed orders are stored in the **Orderbook** (i.e., bids and asks PDA). When a match is found (see [matching-logic](https://fermi-dex.gitbook.io/fermi-dex-docs/technical-overview/architecture/matching-logic "mention")), 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.&#x20;

## Object flow diagram

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.

<figure><img src="https://2294933522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FewLyC4ny0ztkYYXokV4j%2Fuploads%2FYiRLge3dXuJhFnqM4Di1%2FScreenshot%202023-03-13%20at%201.28.02%20pm.png?alt=media&#x26;token=d04dee29-99f0-4db1-9edd-81b9038fe2ea" alt=""><figcaption><p>What happens when you place an order on Fermi DEX?</p></figcaption></figure>

## Accounting

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.

{% hint style="info" %}
**Note**: Since matching is not a complete guarantee of trade finalisation, orders are NOT popped from the orderbook if matched, but their status is set to filled. Only upon order finalisation are the orders removed from the orderbook. This means, you may see crossed bids and asks in the orderbooks - they indicate there are matched orders which are still pending finalisation.
{% endhint %}

## Technical Notes

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 underlying`new_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.

{% content-ref url="architecture/matching-logic" %}
[matching-logic](https://fermi-dex.gitbook.io/fermi-dex-docs/technical-overview/architecture/matching-logic)
{% endcontent-ref %}

{% content-ref url="architecture/just-in-time-liquidity" %}
[just-in-time-liquidity](https://fermi-dex.gitbook.io/fermi-dex-docs/technical-overview/architecture/just-in-time-liquidity)
{% endcontent-ref %}

{% content-ref url="architecture/liquidity-abstraction" %}
[liquidity-abstraction](https://fermi-dex.gitbook.io/fermi-dex-docs/technical-overview/architecture/liquidity-abstraction)
{% endcontent-ref %}