# 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:

```solidity
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:

```solidity
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**

```solidity
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**

```solidity
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.
