Queued redemption lifecycle

See the queued exit lifecycle diagram.

LifecycleCopy Anchor Link

1. AMM escrows EVE and records request metadata in ExitQueue.
2. Controller prices the current batch using AMM's base price.
3. Controller processes requests individually or in ranges.
4. A request within tolerance burns escrow and credits claimable ETH in AMM. An out-of-tolerance request returns EVE instead.
5. The user submits AMM.claim() to withdraw credited ETH.

Creating a request, crediting ETH, and claiming ETH are separate states and events.

User versus keeper actionsCopy Anchor Link

Users call exit(...), claim already credited ETH, or cancel eligible requests through cancelRedemption(batchId). Mimic keeper executors coordinate batch pricing, liquidity, and processing through Controller.

Timing and accountingCopy Anchor Link

MAX_BATCH_PROCESSING_TIME is three days from pricing. During that window, priced, unprocessed requests contribute a liability and matching escrow-supply offset. Processing removes the offsets and reserves ETH for claims.

Unpriced requests can be cancelled at any time. Priced, unprocessed requests can be cancelled only strictly after three days; at exactly three days they are still processable. After that deadline, an unprocessed request can no longer be paid: pullRequest reverts with ExitQueueBatchExpired. Cancel it to recover EVE; a later redemption requires a new request. Expired offsets lapse without a checkpoint reset. Processed requests cannot be cancelled and credited ETH remains claimable.

The queue keeper's minimum batch age is counted from batch creation and is separate from this window. There is no guaranteed settlement deadline. See Keepers.

Indexing ruleCopy Anchor Link

ExitQueue.closeRequest() deletes request storage before emitting closure. The indexer must preserve request-time fields from the creation event. Claims can combine several redemptions and do not carry a per-request association.

See Activity mapping for event semantics.