🛸Liquidity Abstraction

Learn more about Fermi's unique approach to liquidity. This page includes features that logically follow from JIT, in Fermi's v0.2 implementation.

Fermi's approach to Liquidity Abstraction

Liquidity Abstraction Logic: Defining how account balances are available across trades, markets and applications, falls under the umbrella of what we call "Liquidity Abstraction". In traditional DeFi markets - AMMs as well as Orderbooks, liquidity is not abstracted beyond the specific currency pair (and often, not even beyond a specific trade). Fermi Labs is changing that.

Fermi introduces the concept of "Liquidity Abstraction" - the goal is to make capital available as freely as possible across a myriad of trades, trading pairs, and even applications - to increase capital utilisation for Market Makers, resulting in higher returns. We do this by adopting innovative abstraction logic - including changing the accounting around opening orders, depositing funds, matching orders, and finalising orders(transferring liquidity), and allowing just-in-time liquidity across applications from a common wallet balance.

This means that, in practice, with a single 10k USDC balance, not only can a user open any number of trades on the USDC/WSOL pair, s/he can also use the same deposited liquidity to create trades on other markets, like USDC/BONK or USDC/SRM. This is "cross-market" liquidity abstraction. Similarly, in the future, users could also open orders on derivatives, or even lending OBs, using the same common pool of deposited liquidity by that user. The concept of liquidity abstraction is enabled by CLOBs with just-in-time liquidity, as described earlier. Users can place orders on the OB without locking up any collateral, and only if any of the orders (across tokens and markets) is filled and finalized, liquidity is debited from the user's balance. There will be a delay period (of a few seconds initially, and later customisable by the MM) - to allow the MM to fetch liquidity from other sources (exchanges or yeild bearing platforms) and make it available for settlement - via the use of automated listener and transfer scripts (templates provided in our SDK). After the atomic finalisation of the trade, the liquidity of the new asset is immediately available, to potentially fill other open orders. Since liquidity is never "locked", it can be moved between orders, as and when they get filled, with maximum efficiency.

Additional updates as of August, 2023 (Fermi v0.2)

Fermi DEX is an onchain CLOB that registers intents instead of committed orders with locked collateral - and allows orders to be settled “just-in-time” if orders are matched and finalized. 1. Order opening requirements In Fermi’s v0.1 prototype, users were required to deposit the full amount required for a trade into the respective Fermi vault, before they were allowed to open an order. The key distinction from regular orderbooks was that this deposited liquidity was not locked, and was also available to open other orders in the same market. At the stage of order finalization, the program simply attempts to adjust the internal token balances of the two counterparties (as stored in their respective OpenOrders Accounts) to execute the trade - and if either counterparty has insufficient deposited funds, the order fails. In Fermi v0.2, we do away with this deposit requirement altogether - now, to open a trade, users are merely required to approve the full required amount of tokens, instead of actually transferring them to the Fermi Vault. This allows them to retain control of the funds, and utilise them for other earning opportunities (both within and outside Fermi), while their order is pending. Once the order is matched, the Fermi program will attempt to transfer the requisite tokens from both counterparties, utilising the approvals that were granted earlier. If the transfers succeed, the trade is completed; if they fail, the trade enters a pending stage, to be cancelled at the option of either party 2. Incentives and Penalties In Fermi v0.2, we’re implementing a simple marginal deposit requirement, equal to 1% of the trade value - to secure your position on the orderbook. This deposit is fully refundable, if the trade is cancelled before matching; if the trade is successfully finalized, it counts towards the trade value. The intention behind this deposit is to encourage users to place honest orders, and to penalise dishonest or spammy order placement. At the order finalisation stage, there are three possibilities: a. Both parties A & B have sufficient balance, allowing the program to transfer their tokens and perform the trade. The trade is sucessful, and no margin is lost. b. Party A has sufficient collateral, but Party B fails to supply the tokens. In this case, at the option of party A, the trade may be cancelled, and the marginal deposit of party B will be forfieted to party A as compensation for the failed trade. The same happens if the roles are reversed. c. Both party A and party B fail to supply the collateral for the trade. The trade is cancelled, and the margin is refunded to both parties without any penalty.

3. Cross Market & Cross application liquidity abstraction In Fermi v0.1, deposited liquidity was available to open multiple orders only in a single market. Cross market liquidity abstraction was mentioned but not yet implemented. In Fermi v0.2, as an implied effect of not requiring any deposit (except a marginal security) for opening orders, users may now utilise the same liquidity to open orders on multiple different markets (eg. Having 1000 USDC in your wallet, and opening orders worth 1000USDC in the USDC/SOL, USDC/BONK, and USDC/SRM markets at the same time). Note that approval limits may apply - and we’re working on making such applications more seamless. 4. SDK We’re now developing an SDK in active consultation with market makers, arbitrageurs and other potential users of the protocol - to serve as a middleware between the on-chain program and the user, and allow them to integrate trading on Fermi DEX with minimal changes / effort.