Liquidation Queue Configuration

Liquidation Queue

The liquidation queue determines the order in which components must be liquidated by the Rebalancer when processing redemptions. This enforces a predictable liquidation strategy and enables Node Owners to prioritize components based on liquidity costs, withdrawal delays, and other risk factors.

Configuration

Node owners set the queue order:

function setLiquidationQueue(address[] calldata newQueue) external onlyOwner

Requirements:

All addresses must be active components
No duplicate components
No zero addresses
Can be updated any time

Queue Enforcement

Components are checked against queue order via:

function enforceLiquidationOrder(address component, uint256 assetsToReturn) external view

This validates that no component earlier in the queue has sufficient assets to fulfill the redemption.

Router Implementations

ERC4626 Components

function fulfillRedeemRequest(address node, address controller, address component) external returns (uint256) {
    // Validate queue order
    INode(node).enforceLiquidationOrder(component, assetsRequested);

    // Liquidate full component balance if needed
    uint256 componentShares = IERC4626(component).balanceOf(address(node));
    
    // Execute immediate withdrawal
    assetsReturned = _liquidate(node, component, componentShares);
}

ERC7540 Components

function fulfillRedeemRequest(address node, address controller, address component) external returns (uint256) {
    // Validate queue order
    INode(node).enforceLiquidationOrder(component, assetsRequested);

    // Can only process already-claimable assets
    uint256 maxClaimableRedeemRequest = IERC7540Redeem(component).claimableRedeemRequest(0, node);
    uint256 maxClaimableAssets = IERC7575(component).convertToAssets(maxClaimableRedeemRequest);

    // Execute withdrawal of available assets
    assetsReturned = _executeAsyncWithdrawal(node, component, MathLib.min(assetsRequested, maxClaimableAssets));
}

Key differences:

ERC4626: Immediate withdrawals of full component balance
ERC7540: Only processes already-claimable assets
Both follow same queue order enforcement
Both revert if earlier component has sufficient balance

Example

For queue [A, B, C] where A is ERC7540 and B, C are ERC4626:

Must check A's claimable balance first
Can only use B if A's claimable balance insufficient
Can only use C if both A and B insufficient
Pending (non-claimable) balances in A don't block using B or C

This ensures predictable liquidation behavior while accommodating different component withdrawal mechanics.

PreviousFees Configuration NextMax Deposit Limits

Last updated 19 days ago

function fulfillRedeemRequest(address node, address controller, address component) external returns (uint256) { // Validate queue order INode(node).enforceLiquidationOrder(component, assetsRequested); // Liquidate full component balance if needed uint256 componentShares = IERC4626(component).balanceOf(address(node)); // Execute immediate withdrawal assetsReturned = _liquidate(node, component, componentShares); }

function fulfillRedeemRequest(address node, address controller, address component) external returns (uint256) { // Validate queue order INode(node).enforceLiquidationOrder(component, assetsRequested); // Can only process already-claimable assets uint256 maxClaimableRedeemRequest = IERC7540Redeem(component).claimableRedeemRequest(0, node); uint256 maxClaimableAssets = IERC7575(component).convertToAssets(maxClaimableRedeemRequest); // Execute withdrawal of available assets assetsReturned = _executeAsyncWithdrawal(node, component, MathLib.min(assetsRequested, maxClaimableAssets)); }