Dynamic Liquidation Engine (DLE)

Overview

The Dynamic Liquidation Engine (DLE) is a sophisticated liquidation management system implemented in Curvance's protocol. It orchestrates market liquidations through a combination of OEV (Optimal Extractable Value) auctions and a fallback queue-based system, ensuring that unhealthy positions are always liquidated efficiently while maximizing value capture for the protocol.

Technical Architecture

Multi-Phase Liquidation System

OEV Integration with Atlas

The contract integrates with Atlas for OEV (Optimal Extractable Value) capture:

• OEV Auction Mechanism: When price updates make positions liquidatable, an off-chain auction (~300ms) allows liquidators to bid for execution rights

• Bundler Whitelist: Approved bundlers (tx.origin verification) can bypass the queue system entirely

• Atomic Execution: Winning bids are executed immediately in the same block as oracle updates

• Bid Distribution: Successful liquidation bids are distributed to Curvance and the auctioneer according to predefined splits

• Graceful Fallback: If OEV auctions fail, the system falls back to the queue-based liquidation process

Nonce System

The contract implements a sophisticated nonce system for secure, sequential liquidations:

• Unique Identifiers: Each liquidation cycle receives a unique nonce, incremented after completion

• Security Function: Prevents exploitation of old liquidation permissions and replay attacks

• State Tracking: Associates priorities and timestamps with specific liquidation instances

• Liquidation Targeting: Differentiates between token-specific and full account liquidations

Liquidation Types

The contract supports two distinct types of liquidations:

1. Token-Specific Liquidations:

   1. Targets individual collateral positions within an account

   2. Uses the eToken address as the liquidation target

   3. Ideal for soft liquidations where only specific assets need adjustment

2. Full Account Liquidations:

   1. Liquidates all collateral positions for accounts with bad debt

   2. Uses address(0) as the liquidation target

   3. Triggers socialization of any remaining bad debt among lenders

   4. Essential for maintaining protocol solvency

Dual-Oracle Architecture

Curvance's pricing system is designed with risk mitigation as its primary focus through a dual-oracle approach that enhances reliability and security.

For each supported asset, Curvance can simultaneously integrate with two independent oracle providers. This creates redundancy and provides additional verification of asset prices, with the following benefits:

• Enhanced security: Mitigates risk from oracle failures or manipulation

• Continuous operation: Ensures liquidations can proceed even in volatile markets

• Safety Buffer: Creates a safety buffer when valuing collateral during distressed situations

Price Selection Logic

When determining an asset's price, Curvance employs the "most safe" selection algorithm:

1. Each oracle reports its price for the asset

2. The system applies sanity checks to both reported prices:

   1. Deviation from previous price must not exceed configured limits

   2. Price must be above minimum threshold (non-zero)

   3. Oracle must have reported within the maximum allowable reporting window

3. For borrowable assets, the system selects the higher of the two valid prices

4. For collateral assets, the system selects the lower of the two valid prices

This approach ensures that in liquidation scenarios, the protocol always errs on the side of protecting itself from bad debt, while giving borrowers the benefit of the most favorable valid price.

Validation Process

Liquidation attempts undergo multiple validation checks:

in _validateLiquidation() inLiquidationManager.sol:

checks if if specificSequencingActive is false, if so allow liquidation (OEV disabled)

// CASE: OEV is turned off by admin to allow liquidation without
//       queue validation.
if (!specificSequencingActive) {
    return;
}

checks if tx.origin is a whitelisted bundler via _checkAtlasOevAllowed(), if true allow liquidation (Auction winner)

// CASE: Called from SolverOp within Atlas tx so allow liquidations
//       without queue validation.
if (_checkAtlasOevAllowed()) {
    return;
}

checks if OEV is turned on but not an Atlas transaction

if (liqQueue.nonce == 0 || liqQueue.endLine < block.timestamp) {
        revert LiquidationManager__InvalidLiquidator();
}
...

// The liqQueue.endLine < block.timestamp check earlier ensures
// that verifying priorityStartLine != 0 also verifies that
// priorityStartline > block.timestamp - END_DURATION
if (
    priorityStartLine > block.timestamp || priorityStartLine == 0
    ) {
           revert LiquidationManager__InvalidLiquidator();
       }

Risk Mitigation

The system incorporates several safeguards:

• Configurable timeframes ensure OEV auction completion before queue liquidations can execute

• Atomicity of OEV liquidations prevents front-running of auction winners

• Fallback mechanisms ensure liquidations proceed even if OEV components fail

• Clear separation between auction-based and queue-based liquidation paths

Protocol Benefits

• Value Capture: Extracts MEV from liquidations that would otherwise go to third parties

• Liquidation Efficiency: Ensures timely liquidations even during high volatility

• Gas Optimization: Prevents gas wars for queueing liquidations by decoupling queue position from execution priority

• Graceful Degradation: Protocol remains secure even if OEV auctions fail

• Flexible Configuration: Chain-specific duration parameters accommodate varying block times

By implementing this sophisticated liquidation system, Curvance balances the needs of protocol security, liquidator incentives, and value capture, creating a robust framework for position management across diverse market conditions.

---

User Interaction Functions

liquidationStatusOf()

Description: Determines whether an account can be liquidated by calculating its liquidation factor (lFactor), based on the ratio of their collateral to outstanding debt. The function returns the lFactor and current prices for the specified tokens.

Contract: MarketManager/MarketManagerIsolated

Function signature:

function liquidationStatusOf(
    address account,
    address earnToken,
    address positionToken
) public view returns (uint256 lfactor, uint256 earnTokenPrice, uint256 positionTokenPrice)

Type	Name	Description
address	account	The account to check liquidation status for
address	earnToken	The eToken (debt token) to be repaid during potential liquidation
address	positionToken	The pToken (collateral token) to be seized during potential liquidation

Return data:

Type	Description
uint256	lFactor - Account's current liquidation factor. A value of 0 indicates a healthy position. A value between 0 and 1e18 (WAD) indicates a soft liquidation state. A value of 1e18 (WAD) indicates a hard liquidation state.
uint256	earnTokenPrice - Current price for the earnToken (debt token)
uint256	positionTokenPrice - Current price for the positionToken (collateral token)

---

flaggedForLiquidation()

Description: A convenience function that determines whether an account can currently be liquidated in this market. This function utilizes cached exchange rates for each mToken, ensuring that accumulated but unrecognized interest is not included in the calculation.

Contract: MarketManager/MarketManagerIsolated

Function signature:

function flaggedForLiquidation(address account) external view returns (bool)

Type	Name	Description
address	account	The account to check for liquidation flag

Return data:

Type	Description
bool	Whether the account can be liquidated currently (lfactor > 0)

---

canLiquidate()

Description: Checks if a liquidation should be allowed to occur for a specific account, and calculates how many position tokens should be seized when liquidating. This is a view function that does not modify state, used to check liquidation viability.

Contract: MarketManager/MarketManagerIsolated

Function signature:

function canLiquidate(
    address eToken,
    address pToken,
    address account,
    uint256 amount,
    bool liquidateExact
) external view returns (uint256, uint256)

Type	Name	Description
address	eToken	Debt token to repay which is borrowed by the account
address	pToken	Position token collateralized by the account that will be seized
address	account	The address of the account to be liquidated
uint256	amount	The amount of eToken underlying being repaid
bool	liquidateExact	Whether the liquidator desires a specific liquidation amount

Return data:

Type	Description
uint256	The amount of eToken underlying to be repaid on liquidation
uint256	The number of pToken tokens to be seized in the liquidation

---

canLiquidateWithExecution()

Description: Similar to canLiquidate, but this function also executes collateral removal and validates that the liquidator is authorized to perform the liquidation through the OEV (Orderflow Extractable Value) queue system.

Contract: MarketManager/MarketManagerIsolated

Function signature:

function canLiquidateWithExecution(
    address eToken,
    address pToken,
    address liquidator,
    address account,
    uint256 amount,
    bool liquidateExact
) external returns (uint256, uint256)

Type	Name	Description
address	eToken	Debt token to repay which is borrowed by the account
address	pToken	Position token which was used as collateral and will be seized
address	liquidator	The address that will perform the liquidation
address	account	The address of the account to be liquidated
uint256	amount	The amount of eToken underlying being repaid
bool	liquidateExact	Whether the liquidator desires a specific liquidation amount

Return data:

Type	Description
uint256	The amount of eToken underlying to be repaid on liquidation
uint256	The number of pToken tokens to be seized in the liquidation

---