Fermi DEX: How it works
How Liquidity works on Fermi DEX
Last updated
How Liquidity works on Fermi DEX
Last updated
On Fermi DEX, your liquidity can be shared across open trades. What does this mean? Let's demonstrate with a few examples:
Firstly, to open a trade (limit order, bid/ask), you must approve the correct amount of liquidity to execute the trade. Say you want to bid 100 USDC for 5 wSOL, you must have at least 100 USDC at the time of placing the order, in the USDC vault of Fermi DEX. If you do not have these deposits, as part of the new_bid function, the DEX will attempt to approve 100 USDC to the USDC vault - if the transfer fails, the new order will revert.
So how is this different from regular orderbook DEXes? The key difference is that orders can be opened without locking funds. This means that the same funds can be used to open multiple trades. Thus, you can place another order, say a bid of 50 USDC for 2 wSOL, and a third bid for 30 USDC, for 1 wSOL - all with the same collateral of 100 USDC! Since only some of these orders may get filled, you get to take advantage of various potential trades with a single deposit- increasing your capital efficiency.
So when really is the liquidity locked? The answer is never - liquidity is only debited when there is a corresponding credit in another asset.
Say your second order (50 USDC / 2 wSOL) is filled, at this moment, 50 USDC will get debited from your vault, and at the exact same moment, 2 wSOL will get credited to your balance. In a manner of speaking, liquidity is thus never locked - trades are atomically finalised, and funds are only debited if the desired trade amount of the other asset has also been credited. This process is called trade finalization.
If liquidity is not locked in advance, what happens if a matched order cannot be filled?
When finalizeMatch is invoked, if either counterparty to a trade has insufficient funds in their vault for providing JIT liquidity, the trade enters a pending state - where it can be finalised once again when the counter-parties have the requisite liquidity, or cancelled at the option of either party. No funds are lost or locked.
Failure Penalties, and other incentive mechanisms (such as trader reputation leading to discounts) may be designed in the future to minimize such pending trades, and incentivise users to close out open orders in advance when not needed, to prevent pending JIT transactions and increase trade finalisation certainty.
In this section, we describe how to perform each step in a trade lifecycle on the interface. In the next section Technical Overview, we discuss the underlying programs that make this possible.
In this setup, it is also possible to employ cross-market liquidity abstraction (CMLA), to further increase the value that can be extracted from a single deposit. With CMLA, you can also use the same USDC deposit to open trades on other markets. Say you want to place a bid of 15 USDC for 10000000 BONK, you will be able to do that as well, without making any further deposits.
Dive in to learn about the different steps in a trade lifecycle: