Liquidator execution capacity

Liquidator execution capacity is primarily derived from the amount of time it takes a liquidator to fully perform a liquidation with an amount of capital they have on hand, such that the same capital is once again ready to be used in another liquidation. We can represent this execution capacity as:

\begin{align} C_{\text{exec}} = \frac{C_{\text{capital}}}{T_{\text{liquidation}}} \end{align}

Where $C_{capital}$is the amount of capital the liquidator has available for liquidation and $T_{liquidation}$ is the amount of time it takes to fully execute a liquidation, re-collateralize, and be ready to execute another one.

This equation shows that the larger the liquidator's available capital and the shorter the liquidation time, the higher their execution capacity will be.

This calculation assumes a fast and efficient liquidation process, and the actual execution capacity may be lower due to factors such as network congestion, transaction fees, or price slippage.

In an effort to practically implement an effective system, the risk engine in mrgnlend estimates liquidator execution capacity based on static parameters with conservative assumptions. At present, mrgnlend considers a liquidator execution time of 3 seconds per liquidation. This is a significantly conservative estimate when compared to the execution rates of best-in-class MEV searchers on Solana, whose execution engines achieve similar performance in less than 100 milliseconds.

Risk engine simulations typically assume a conservative liquidator capital base of less than $25,000 USDC.

As liquidations become more frequent, and where applicable, mrgnlend’s risk engine will track historical liquidations and use a combination of historical:

• Liquidation execution timelines

• Network congestion

$\text{to estimate $T_{\text{liquidation}}$.}$

This approach assures a conservative yet dynamic estimation of liquidator execution capacity. The SMA is utilized when execution times are decreasing, implying that liquidators are becoming more efficient, while the EMA is preferred when execution times are increasing, indicating that liquidators are becoming less efficient. Moreover, potential increases in network congestion are accounted for by adjusting the maximum of the SMA and EMA of execution times.

The estimation of liquidator execution capacity, denoted as $T_{liquidation}$ is given by:

\begin{align} T_{\text{liquidation}} = \max(\text{SMA}_{28d}, \text{EMA}_{28d}) + \text{SMA}_{N_{\text{cong}},28d} \end{align}

where,

$\text{SMA}_{28d} = \frac{1}{28}\sum_{i=1}^{n} T_{\text{liquidation},i}, \text{ } \text{SMA}_{N_{\text{cong}},28d} = \frac{1}{28}\sum_{i=1}^{n} N_{\text{cong},i}$

$\text{EMA}_{28d} = \left(\frac{T_{\text{liquidation},\text{t}} - \text{EMA}_{\text{t-1}}}{\frac{2}{n+1}}\right) + \text{EMA}_{\text{t-1}}$

In this model, $T_{liquidation}$ is the time that an execution takes in seconds $i$, $N_{cong, i}$ is the expected time that network congestion could add based on a configured percentile of observed network transactions per second on day $i$, and $t$ denotes the current day.

To represent the network congestion, we introduce $N_{cong, i}$ which is calculated as follows:

$N_{\text{cong},i} = \text{pctl}_p\left(\text{tps}_{i, 1:g}\right)$

Here, $tps_{i, 1:g}$ denotes the observed network transactions per second for the past $g$ days on day $i$, and $pctl_{p}$ represents the $p$ percentile of these observed values.

This calculation assumes that network congestion can slow down liquidation execution, and it uses historical data to model this impact conservatively. By using a high percentile, $N_{cong, i}$ is likely to overestimate rather than underestimate the time added by network congestion, thus providing an extra margin of safety.

By incorporating the effects of network congestion, mrgnlend's risk engine provides a more realistic and dependable estimate of liquidator execution capacity. This model reflects the dynamism of the DeFi landscape, and its built-in conservatism aids in ensuring the safety and resilience of the protocol.