The redemption queue, in depth
Full mechanics of the ExitQueue, including batching, pricing, processing, claims, and recovery.
Testing phase: treat as a test protocol
Everstrat is deployed on Ethereum mainnet (chain id 1), but it is in a testing phase and should be treated as a test protocol. Entry is invite-gated and the software is experimental.
This page explains the full lifecycle of a queued redemption. For the user-facing summary, see Exiting & redeeming.
When does an exit go to the queue?
When you call exit(), the AMM first checks its free balance: the ETH it holds minus any ETH
already reserved for pending claims (freeBalance = address(AMM).balance − lockedForClaims). If the
free balance is enough to pay your redemption at the current base price, the exit settles
immediately. Otherwise your request enters ExitQueue and your EVE is escrowed on AMM.
At the dated snapshot, free balance was zero: all AMM ETH was reserved for existing claims, and the keeper's immediate-exit float top-up was disabled. Deposits go to Controller and do not add to AMM's free balance, so new exits queue.
There is a minimum size for queued exits: your redemption must be worth at least 0.001 ETH (the
default minBatchExitETH). The admin can raise this up to 0.05 ETH if needed to keep batch sizes
economical. Immediate exits have no minimum.
A queued exit, from escrow to claim.
EVE stays on AMM until processing or cancellation. The keeper must process within 3 days of pricedAt; the user then claims ETH. Strictly after 3 days, an unprocessed request cannot settle and must be cancelled to recover EVE. Unpriced requests can be cancelled at any time; already credited ETH remains claimable.
Step-by-step: queued exit lifecycle
Your request joins the current batch. Your EVE tokens are escrowed in the AMM (not yet burned). ExitQueue stores the request metadata and the base price at submission for the slippage check later.
A keeper prices the batch. The keeper calls the Controller, which prices the batch on the
ExitQueue using AMM.eveBasePriceInETH(). Pricing moves that batch's outstanding ETH liability
and escrowed EVE out of active NAV and live supply. Once priced, the batch is locked; requests inside it
cannot be cancelled until the batch processing window expires.
The keeper processes each request. For each request in the batch, the ExitQueue checks whether
the settled price has fallen too far from the price at submission time. If finalEvePrice has
dropped more than your priceTolerance below evePriceAtRequestTime, the request is closed for
slippage. Your EVE is returned to you and you receive no ETH. Otherwise, your ETH entitlement is
computed and credited.
Processing must occur within three days of batch pricing. Strictly after that deadline, an unprocessed request expires and cannot be settled; cancel it to recover EVE.
Your ETH is credited to your claimable balance. The ETH is not pushed to your wallet
automatically. Instead, it is added to claimableBalances[you] and tracked in the AMM's
lockedForClaims counter (which is why it is excluded from the free balance and from NAV). This
pull-over-push pattern ensures one user's reverting wallet cannot block the entire batch from
settling.
You call claim() to withdraw. Once your ETH is in your claimable balance, you call claim()
on the AMM at any time to transfer it to your wallet.
Slippage tolerance
When you queue an exit, you specify a priceTolerance: the maximum percentage drop in base price you
are willing to accept between your submission and the batch settlement. If the price falls more than
this, your EVE is returned and you can try again.
The tolerance must be in the range [0, 100%]. Setting it to 0 means any price drop will trigger a
slippage return; setting it high means you accept significant price movement in exchange for a higher
chance of your exit settling.
The escape hatch
If your batch is priced but the keeper never processes your request (for example, because the protocol
encounters a problem), cancellation becomes available strictly more than 3 days after pricing.
You can call cancelRedemption(batchId) on the AMM to recover your EVE. This is the escape hatch
(MAX_BATCH_PROCESSING_TIME = 3 days).
After that window, processing reverts with ExitQueueBatchExpired. Waiting longer cannot
make the original unprocessed request payable. Cancellation returns EVE; any later redemption
requires a new exit request and a new quote. At exactly three days, processing is still allowed
and cancellation is still blocked.
You can also cancel at any time before the batch is priced. Unpriced batches have no waiting period.
| When | Can you cancel? |
|---|---|
| Before the batch is priced | Yes, at any time |
| After batch is priced, up to and including 3 days | No, the request is still inside the processing window |
| More than 3 days after pricing, still unprocessed | Yes, through the cancelRedemption escape hatch |
| Request already processed | No. Claim the credited ETH instead |
The 3-day window after pricing exists to give the keeper time to process all requests in the batch without users gaming the system by watching the final price and cancelling if they don't like it. The escape hatch applies to each still-unprocessed request. Once a request is processed, its ETH remains claimable even if the user has not claimed it within three days.
Summary of key parameters
| Parameter | Default | Maximum |
|---|---|---|
| Minimum queued exit size | 0.001 ETH | 0.05 ETH (admin-configurable) |
| Escape hatch after pricing | Strictly more than 3 days | Fixed in this implementation |
| Maximum live priced batches | 25 | Fixed in this implementation |
At the dated deployment snapshot, the Mimic queue keeper required a batch to be 24 hours old before automatic pricing, counted from batch creation. A request joining an older batch does not start a fresh 24-hour clock. This is an executor scheduling parameter, separate from ExitQueue's three-day window after pricing. Keeper availability, gas limits, and liquidity affect actual timing. See Keepers and automation.
See also
- Exiting & redeeming: the user-facing summary
- Pricing & the bonding curve: how base price is computed
- Architecture at a glance: how the ExitQueue fits into the full contract map
- Key risks: liquidity and queue timing risks
Last updated on