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:

1. Must check A's claimable balance first

2. Can only use B if A's claimable balance insufficient

3. Can only use C if both A and B insufficient

4. Pending (non-claimable) balances in A don't block using B or C

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