Liquidation process walk through
This page provides a more detailed explanation of Fathom's FXD liquidation process
Last updated
Was this helpful?
This page provides a more detailed explanation of Fathom's FXD liquidation process
Last updated
Was this helpful?
For a position to be considered safe, the below should hold true.
where
RawPrice is the price of collateral from PriceFeed
and LTV is Loan to Ratio.
If a position's value of lockedCollateral(lockedCollateralAmount * PriceWithSafetyMargin)
goes below the debtValue(DebtShare * debtAccumulatedRate)
, the position is considered unsafe/underwater and will be subject to liquidation process. The liquidator bot monitors the health of each position in the Fathom protocol.
Once a position is underwater and spotted by the liquidator bot, the bot can call the liquidate
function in the LiquidationEngine
contract.
Or the bot can call the batchLiquidate
function if it spots multiple underwater positions.
If a bot calls liquidate
or batchLiquidate
functions to LiquidationEngine
without using the _data
param, the liquidator bot needs to have enough balance of FXD token available and should have approved FixedSpreadLiquidationStrategy
as a spender. This is because the process of depositing FXD to liquidate and receive collateral is done in the execute function in FixedSpreadLiquidationStrategy
.
_liquidate
function first goes through some checks in the function args and checks whether the position targeted for liquidation is safe.
Once the position is underwater, the liquidation task is tossed to FixedSpeadLiquidationStrategy
execute function.
The function then validates the input parameters, such as the debt share, collateral amount, and position address. It checks for zero values and valid price feeds to ensure the integrity of the liquidation data.
Then, it calculates the liquidation information based on the current market price, debt share, and collateral amount. This step involves determining the actual debt value to be liquidated, the collateral amount that will be seized, and any applicable treasury fees.
The function then calls confiscatePosition
on the BookKeeper
, adjusting the collateral and debt share of the position in question.
Treasury fees are moved from the liquidation contract to the SystemDebtEngine
if any treasury fees are due.
If flash lending is enabled and valid, the contract facilitates flash lending calls. This step is optional and based on the encoded data provided.
Without flash lending, the contract withdraws the collateral to the liquidator and transfers the required FXD amount to cover the debt. The FXD is then deposited in the BookKeeper
to clear the debt.
Finally, an event LogFixedSpreadLiquidate
is emitted to record the details of the liquidation transaction.
After the execute
function of the FixedSpreadLiquidationStrategy
completes, the remaining liquidation process in the LiquidationEngine
is verification of successful liquidation and recording of systemBadDebt
if needed.
First, updated position data is retrieved:
Then, the decrease of position debt Share is validated, ensuring effective liquidation:
Once the liquidation validation is good with debtShare
, receipt of the expected stablecoin amount by the SystemDebtEngine
is checked:
In case the collateral is fully liquidated with remaining debt, the function records this as systemBadDebt
:
If a bot calls liquidate
or batchLiquidate
functions and has the _data
param filled with encoded data that can be used for address, the liquidator bot doesn't necessarily need to have an FXD token available.
Once liquidation functions are called, the liquidation process starts from the internal function .
The function in FixedSpeadLiquidationStrategy
starts by verifying if the caller has the LIQUIDATION_ENGINE_ROLE
from the AccessControlConfig
associated with the BookKeeper
. This ensures that only authorized entities can initiate the liquidation process.