# Asynchronous Redemptions

### Overview

The protocol implements an asynchronous redemption system where withdrawal requests are processed in two steps:

1. User requests redemption (shares moved to Escrow)
2. Rebalancer fulfills redemption (assets moved to Escrow)

### Request Structure

```solidity
struct Request {
    uint256 pendingRedeemRequest;  // Shares pending redemption
    uint256 claimableRedeemRequest; // Shares ready to be claimed
    uint256 claimableAssets;       // Assets ready to be claimed
}
```

### Redemption Lifecycle

1. **Request Phase**

```solidity
function requestRedeem(uint256 shares, address controller, address owner)
```

* Shares are transferred to Escrow
* `pendingRedeemRequest` is increased
* `sharesExiting` is increased to track pending withdrawals

2. **Fulfillment Phase**

```solidity
function fulfillRedeemFromReserve(address controller)
function fulfillRedeemBatch(address[] memory controllers)
```

* Rebalancer processes request during rebalance window
* Can fulfill from reserve or liquidate components
* Updates request state via `finalizeRedemption`

3. **Claim Phase**

```solidity
function withdraw(uint256 assets, address receiver, address controller)
function redeem(uint256 shares, address receiver, address controller)
```

* User claims available assets from Escrow
* Decrements `claimableAssets` and `claimableRedeemRequest`
* Burns shares from Escrow

### Router Integration

Routers can process redemptions from their respective components using:

```solidity
function fulfillRedeemRequest(address node, address controller, address component)
```

* Processes component withdrawal
* Updates request state via Node's `finalizeRedemption`

For more details on the redemption system, see the full protocol documentation.