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

struct Request {
    uint256 pendingRedeemRequest;  // Shares pending redemption
    uint256 claimableRedeemRequest; // Shares ready to be claimed
    uint256 claimableAssets;       // Assets ready to be claimed
    uint256 sharesAdjusted;        // Shares after swing pricing
}

Redemption Lifecycle

1. Request Phase

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

• Shares are transferred to Escrow

• pendingRedeemRequest is increased

• sharesAdjusted records shares after any swing pricing penalty

• sharesExiting is increased to track pending withdrawals

1. Fulfillment Phase

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

• Rebalancer processes request during rebalance window

• Can fulfill from reserve or liquidate components

• Must follow liquidation queue order

• Updates request state via finalizeRedemption

1. Claim Phase

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:

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

• Validates liquidation order

• Processes component withdrawal

• Updates request state via Node's finalizeRedemption

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