Skip to main content

Config: Health Factor

To prevent liquidation by Burrow, our contract must maintain a health factor greater than 100%.

However, we do not plan to leverage up to exactly 100%. To ensure the safety of user funds, we aim to maintain a significantly healthy margin above the minimum.

The Problem When Deciding the Healthy Margin​

The Meteor Farm contract was designed as a general-purpose contract that allows the owner to create farming contracts using a Base Token, a Master Farm Token, and a Slave Farm Token of their choice.

When deciding on the "healthy margin," we discovered a key trade-off:

  • A high health factor leads to low APR.
  • A low health factor increases the risk of liquidation under extreme market conditions.

We realized that the decision on what margin to use should also consider:

  • Whether the asset is exposed to bridge risks.
  • Whether the asset is liquid staked, and therefore subject to over-staking risks.
  • Whether the asset experiences high price volatility.

The Smart Solution​

Fortunately, Burrow already performs risk analysis for us. They assess token risks and assign a volatility ratio to each token.

If we trust that Burrow assigns suitable volatility ratios, we can design a formula based on these ratios to determine the appropriate health factor.

This approach allows us to optimize for APR while minimizing the risk of liquidation.

Stable Health Factor​

The Stable Health Factor (denoted as HsH_s) represents the target health factor that our arbitrage bots aim to maintain between transactions. This buffer protects against market volatility and ensures that the contract remains safely overcollateralized.

Let:

  • VcV_c = minimum volatility ratio among all collaterals
  • VbV_b = volatility ratio of borrowed assets

The formula for the Stable Health Factor is:

Hs=Vc×VbH_s = \sqrt{V_c \times V_b}

Temporary Health Factor​

Since the NEAR Protocol does not support flash loans, our leverage and deleverage processes temporarily reduce the health factor. We do this by "borrowing" assets from the existing collateral, which causes the health factor to drop to the Temporary Health Factor (denoted as HtH_t).

However, we always ensure that by the end of each transaction, the health factor returns to HsH_s. This guarantees safety even during transitional states.

Thanks to NEAR’s deterministic transaction execution, once a signed transaction is submitted to the RPC, it will run to completion — even if the arbitrage server fails mid-way. As a result, the contract never remains at a low health factor for long.

Only the master contract uses the temporary health factor. Sub-contracts always maintain the stable threshold.

The formula for the Temporary Health Factor is:

Ht=(Vc×Vb)14=Vc×Vb4H_t = (V_c \times V_b)^{\frac{1}{4}} = \sqrt[4]{V_c \times V_b}