Skip to content

Liquidation

Overview

The Liquidation module extends the Stability Pool by handling the safe liquidation of under-collateralised positions.
It is deployed as an immutable implementation and is executed only via delegatecall from the StabilityPool (or an authorised proxy).

Warning

Direct interaction with the implementation contract is blocked by onlyProxy.
This guarantees state changes persist in the StabilityPool and prevents standalone abuse.

No Deposit or Minting Fees on Liquidation

When a liquidation occurs, no deposit or minting fees are charged by the LendingPool or the RWA Vault.
The full value of the liquidated collateral is used to restore the Stability Pool and protocol health, ensuring that liquidations are not penalized by protocol fees at any stage.

Purpose

  1. Check borrower health; abort if the position is still safe.
  2. Transfer borrower collateral (ERC-20 / ERC-721) to the RWA Vault and mint iREET.
  3. Split minted iREET per protocol parameters:
  4. Minting fee → Treasury
  5. Burn → permanent removal
  6. Swap → convert to pmUSD
  7. Liquidity rewards → deposit to Curve Gauge
  8. Restore the Stability Pool’s rToken by re-depositing swapped pmUSD into the LendingPool.

Note

Keeping liquidation logic in a delegate-callable module keeps the Stability Pool compact and upgradeable without storage clashes.

Philosophy & Incentives

Manager-Driven Liquidations

  • RAAC does not incentivize external liquidators.
  • Only protocol managers trigger liquidations; this matches the real-estate risk profile.

Conservative Parameters

  • Borrow Threshold: 50%
  • Liquidation Threshold: 60% (10% buffer)

Risk Mitigation

  • Real-estate volatility is low (typical drawdowns are gradual).
  • Oracle updates weekly.
  • Focus on Section 8 housing (government-subsidised).
  • Diversified across low-risk states.

User Incentives

Users deposit rToken → receive deToken → may stake for rental yield and external liquidity incentives, concentrating rewards via gauges.

Liquidation Mechanics

  • The entire position is taken (debt + collateral).
  • The LendingPool clears the user’s debt when finalizeLiquidation is executed; collateral is transferred to the Stability Pool.
  • Collateral is then routed to the RWA Vault to mint iREET, which is split across Treasury / Burn / Swap / Liquidity.
  • The Swap leg (iREET → pmUSD) is re-deposited into the LendingPool to restore rToken used by the Stability Pool.

Swap parameters flexibility

Managers may tune swap parameters so the swap leg targets at least the amount needed to restore rToken used during liquidation.

Excess pmUSD handling

Any excess pmUSD after liquidation is deposited back into the LendingPool, minting rToken to the Stability Pool without minting deToken. In a bad-debt scenario that surplus therefore repairs the pool's backing before it becomes withdrawable value for anyone.

Access Control & Safety

Mechanism Description
onlyProxy Prevents direct calls; execution must come via Stability Pool.
Managers Only managers/owner in Stability Pool can call liquidateBorrower.
Validation • Adapters must be registered • Asset/vault adapter tokens must match • data must validate • Debt > 0 • Pool must hold enough liquidity

Key Functions

Function Type Description
liquidateBorrower(poolAdapter, vaultAdapter, user, data, minSharesOut) external Entry point from Stability Pool; runs the full liquidation cycle and emits BorrowerLiquidated.

vaultAdapter is always the ERC-721 path

poolAdapter is the borrower-side IAssetAdapter; vaultAdapter is the vault-side IVaultAssetAdapter, and in practice it is always RAACNFTVaultAdapterV2. No ERC-20 vault adapter is deployed. The proxy still validates that both adapters report the same asset token before proceeding.

| _handleLiquidation(poolAdapter, vaultAdapter, data) | internal | Routes collateral → RWA Vault → iREET → split (treasury, burn, swap, liquidity). | | _handleSwap(amount) | internal | Swaps iREET for pmUSD via the configured swap implementation. | | _handleLiquidityRewards(amount) | internal | Deposits iREET into a Curve Gauge. | | _handleTreasuryFee(amount) | internal | Transfers the minting-fee share to Treasury. |

Split struct 

struct LiquidationVaultTokenSplit {
    uint256 mintPercentage;      // Treasury
    uint256 burnPercentage;      // Burn
    uint256 swapPercentage;      // Swap
    uint256 liquidityPercentage; // Gauge
} // must sum to 10000 (100%)

Liquidation Flow

  1. Pre-checks: validate adapters, debt, data, and pool liquidity.
  2. Stability Pool → LendingPool: call finalizeLiquidation (debt is cleared; collateral moves to Stability Pool).
  3. Collateral → RWA Vault: deposit collateral; receive iREET.
  4. iREET split: Treasury / Burn / Swap / Liquidity per LiquidationVaultTokenSplit.
  5. Swap leg: iREET → pmUSD via configured pool/route.
  6. Restore rToken: deposit swapped pmUSD back into the LendingPool to regain rToken used by the Stability Pool.
  7. Shortfall branch: if pmUSD proceeds are insufficient, the gap is covered by the Stability Pool's own rToken via lendingPool.withdraw(). The pool is then under-backed until the deficit is repaired — see Backing, Bad Debt and the Treasury Backstop.
  8. Emit BorrowerLiquidated.

Liquidation Process Diagram (detailed)

Liquidation Process Diagram

Notes

  • All percentages use basis points (10000 = 100%).
  • Slippage risk is expected; managers must parameterise swaps conservatively.
  • No external liquidation incentives; liquidations are manager-driven.