Matching Engine

When orders are matched P2P, it means that the liquidity utilization rate is always at 100% for each pair of supplier and borrower. This means that there is as much supply and borrow demand as the volume that is matched. However, it is not always the case because most of the time, there may always be a difference in the demand between the suppliers and the borrowers.

For example, there is $10 million worth of funds supplied on NillaConnect, but there are only $8 million worth of borrowing demand. NillaConnect has to select suppliers accumulating to the $8 million borrowing demand to enjoy the P2P rate, while the remaining $2 million will be forwarded to the pool to receive the pool APY.

How does NillaConnect select which order comes first?

First off, we want to ensure simplicity so that a passive user/contract are able to benefit by just supplying/borrowing. Therefore, simplicity should be taken into consideration.

Obviously if possible, we would like the P2P rate to be enjoyed by everyone. Therefore, the first parameter taken into consideration would be Economic Efficiency, where we try to maximize the matching volumes.

However, it is not practical in the DeFi world, because we have to consider the gas costs too. Matching many small orders together will result in accumulating gas costs that could diminish returns, which is not efficient. Therefore, another important parameter would be Gas Efficiency to minimize gas costs and avoid dust problems.

Finally, to ensure a decentralized and fair procedure, fairness should be taken into consideration as one of the parameters. NillaConnect wants to benefit as much liquidity and users as posssible.

To sum up, the four main parameters of the matching engine are:

  1. Simplicity

  2. Economic Efficiency

  3. Gas Efficiency

  4. Fairness

Thus, NillaConnect uses an on-chain priority queue called the value-to-time priority. This means that the user with the higher volume in an order would have to priority to be matched first. In the case where 2 users have the same volume, the user that created the order first will then be matched first.

NillaConnect uses a finite for-loop to pair suppliers and borrowers together meaning that the priority will keep matching until either:

  1. The entire order is filled

  2. The maximum gas limit is reached

Once either of the two scenarios happen, the matching will stop. This protects the users from potentially incurring high gas fees, hence why the predefined maximum gas cost exists. It is called maxGasForMatching which is decided by governance.

Case Study

John is the largest lender with $50M worth of liquidity in NillaConnect. The borrowers will instantly be matched with John until John's liquidity is fully matched, which is when the borrowers will be matched with the second largest lender from John. This limits the number of iterations required to reach borrowers since most will instantly be matched with John.

Let's say there are $150M worth of liquidity supplied (available to borrow) from John and 100 other lenders ($1M each). Kevin comes in and wants to borrow $80M.

In the first iteration, Kevin will be matched with John's $50M. The remaining iterations will be checked for an additional million, meaning that the gas limit will be checked after each lender is matched. Let's say after 11 iterations, the maxGasForMatching is reached. This means that out of Kevin's $80M borrow order, $60M (John's $50M + ($1M x 10)) is matched P2P. This means the $20M requires substitute liquidity from the underlying pool. Kevin's average APY will be the proportion of P2P APY and pool APY, which will lie within both rates giving Kevin a better rate still.

NillaConnect's capital efficiency scales with the blockchain that it is deployed on. This means that the higher the blockchain throughput, the larger the maxGasForMatching can be, the more matches can be executed.

Last updated