Skip to main content

Matching Mechanism

In the earlier chapters, we mentioned the use of Junge Exchange’s order-matching engine when a trader opens a position. Here, we will cover the mechanisms in detail.


Capital Efficiency

Capital efficiency is a key innovation at Jungle Exchange. A number of unresolved issues related to capital efficiency and OI limit have hindered the long-term prosperity of market dynamics in DeFi.

  • Concentrated Liquidity

    Market makers can specify their price range by defining the spread at the time of Market Maker Pool creation. Along with the order-matching engine that prioritizes price, capital utilization is optimized in a flexible manner - same amount of capital, more trading activities, greater depth.

  • 10x Leverage To Amplify Liquidity

    Just like trading, the idea of leverage is quite straightforward - same amount of capital, with smaller deposits put into MM pools, hence better capital efficiency.

  • The multi-objective level playing field

    Consider the following scenario: Trader A opens long position. Due to Jungle’s order-matching mechanism and MM Pool design, orders can be matched both in a parallel and perpendicular manner. Due to the fact that trades and MM pools can be created permissionlessly, the upper limit of order-matching efficiency further extends.

    Trader A opens long

    ⇒ Trader B, C, D, … opens short

    ⇒ Trader B, C, D, … closes long

    ⇒ Pool A, B, C, … opens short

    ⇒ Pool A, B, C, … closes long

Theoretically, there is no upper limit on supported OI, allowing for the potential leverage of substantial OI by cyclically utilizing funds. The better the capital efficiency, the more fair competition there is, the better the dynamics of the market, the better the capital efficiency - a virtuous cycle of capital efficiency.

Amplify your trading and market making strategies with less upfront capital and better OI support. Jungle’s Order-Matching mechanism, the capital efficiency you were promised.


Priority

Routing, or Order-matching mechanism determines the market maker by which an order will be taken. Currently, orders will be matched automatically to the best price, which means that manual selection or switching is not feasible to takers. The priority of order-matching process, in descending order, is as follows:

  1. Price Priority (the best price after accounting for the Price Spread)

  2. Close Position Priority - liquidity pools with positions available to close will be matched.

  3. Randomization - the blockhash is used to generate random numbers for fill order pool selection. This ensures fair and decentralized order distribution for MM Pools to fill and hence unbiased liquidity utilization.


To illustrate the priority rules, consider the following example:

Case 1 : If there is only one pool, Pool A with optimal price, Pool A will be matched.

Case 2 : If there are ten pools with the optimal price, while only Pool B has positions available to be closed, positions in Pool B will be matched.

Case 3 : If there are ten pools with the optimal price, but there is either no pool, or more than one pool with positions available to be closed, then the market maker pool that fills the order will be selected in a randomized manner.


The Dynamics Between MM Pool Position and Trader Position

When users are satisfied with the optimal price quoted, and have confirmed the opening or closing of positions, the next step accordingly is the position creation or adjustment phase. Several possible scenarios include:

  1. Trader opening a position while the MM pool is closing a position:

  2. Trader opens long position ⇒ MM pool closes long position

  3. Trader opens short position ⇒ MM pool closes short position

  4. Trader opening a position while the liquidity pool is opening a position:

  5. Trader opens long position ⇒ MM pool opens short position

  6. Trader opens short position ⇒ MM pool opens long position

  7. Trader closing a position while the liquidity pool is opening a position:

  8. Trader closes long position ⇒ MM pool opens long position

  9. Trader closes short position ⇒ MM pool opens short position

  10. Trader opening a position while the liquidity pool is opening a position:

  11. Trader closes long position ⇒ MM pool closes short position

  12. Trader closes short position ⇒ MM pool closes long position


In summary, when both the user and the liquidity pool are performing the same operation (either opening a position or closing a position), their long or short direction is opposite. Otherwise, if they are taking opposite actions, then both parties have the same long or short direction.


Edge Case

Ideally, the liquidity pool corresponding to the quote provided by the order-matching engine can fully take the trader’s order, allowing for a straightforward position adjustment. However, it is common for the market maker pool with the best price to have insufficient liquidity to execute the entire order. In such cases, the system will sequentially attempt to match MM pools with the second-best quote, the third-best quote, and so on. If none of these quotes results in a complete execution, the order will be returned, and the user's margin balance and trading costs will be refunded. The only loss incurred by the trader will be the gas fee paid during the transaction.