Protocol
Queued redemption lifecycle
The exact lifecycle for burns that cannot settle immediately in the AMM.
Lifecycle Overview
AMM pushes the request into
ExitQueue.The current batch later gets priced by Controller using the AMM base EVE price.
Queued requests are processed one by one or in ranges.
Each request either redeems within tolerance or closes due to slippage.
If the processing window expires, the user may cancel via the escape hatch.
User Action vs Keeper Action
User can create the queued request through exit(...) and later call cancelRedemption(batchId)
when closure rules allow it.
Keeper prices the batch through Controller and processes requests through AMM / ExitQueue coordination.
Processing Window
ExitQueue.MAX_BATCH_PROCESSING_TIME is 3 days.
Within that window after pricing:
- requests must be processed
- normal closure is blocked
After that window:
- users can close via escape hatch
- the cancellation outcome is distinguishable in events and subgraph fields
Snapshot rule
ExitQueue.closeRequest() emits RequestClosed after deleting storage. That is why the subgraph
must snapshot request fields when the request is first pushed, not at close time.
Last updated on