Pre-Liquidation

Step-by-step guide to deploying pre-liquidation contracts, authorizing borrowers, and building monitoring bots with Solidity and TypeScript examples.

Deploy a pre-liquidation contract, authorize it for borrowers, and build a monitoring bot.

Prerequisites

  • Understanding of pre-liquidation concepts (see Learn → Pre-Liquidation)

  • Familiarity with the PreLiquidation API (see Reference → Pre-Liquidation)

  • Access to Lotus market parameters and tranche configuration

Step 1 — Choose Parameters

Before deploying, choose the six parameters that define the pre-liquidation behavior. The tradeoffs are:

  • PRE_LLTV: The LTV where pre-liquidation begins. Closer to LLTV means a narrower zone and less protection for borrowers. A wider gap gives borrowers more runway but means pre-liquidation kicks in earlier.

  • PRE_LCF_1 / PRE_LCF_2: The close factor range. PRE_LCF_1 is the minimum close factor at PRE_LLTV; PRE_LCF_2 is the maximum at LLTV. Higher values mean more aggressive pre-liquidation (more debt repaid per call). PRE_LCF_1 must be ≤ PRE_LCF_2 and PRE_LCF_1 must be ≤ 1e18.

  • PRE_LIF_1 / PRE_LIF_2: The incentive factor range. PRE_LIF_1 is the minimum incentive at PRE_LLTV (must be ≥ 1e18, i.e. at least 100%); PRE_LIF_2 is the maximum at LLTV (must be ≤ WAD.divWad(LLTV), i.e. 1e36 / LLTV). Higher incentives attract liquidators but cost borrowers more collateral.

  • Oracle: The oracle used for pre-liquidation price checks. Can be the same as the tranche's oracle or a faster-updating alternative.

Sensible starting values for a tranche with LLTV of 90%:

Parameter
Value
Meaning

preLltv

0.85e18

Pre-liquidation starts at 85% LTV

preLCF1

0.05e18

5% close factor at PRE_LLTV

preLCF2

0.20e18

20% close factor at LLTV

preLIF1

1.01e18

1% incentive at PRE_LLTV

preLIF2

1.05e18

5% incentive at LLTV

preLiquidationOracle

tranche oracle

Same oracle as the tranche

Step 2 — Deploy via Factory

Deploy a pre-liquidation contract using the PreLiquidationFactory. The factory uses CREATE2 for deterministic addresses.

You can compute the deployment address before deploying:

This is useful for allowing borrowers to authorize the contract before it exists on-chain.

Step 3 — Borrower Authorization

The borrower must authorize the pre-liquidation contract to withdraw collateral on their behalf. Without this, pre-liquidation calls will revert.

Direct authorization:

EIP-712 signed authorization (gasless for borrower):

The authorization is protocol-wide — it allows the pre-liquidation contract to call withdrawCollateral on any of the borrower's positions. The pre-liquidation contract itself is scoped to a single market and tranche, so it can only act on the position it was deployed for. Repayment does not require authorization; anyone can repay on behalf of any borrower.

Step 4 — Monitor and Execute

The following TypeScript example shows how to build a bot that monitors positions and executes pre-liquidations:

For flash-funded pre-liquidation (no upfront capital), implement IPreLiquidationCallback:

Step 5 — Testing

A Forge test showing a complete pre-liquidation flow:

See Also

Last updated