Overview
TheQueue contract provides a shared foundation for time-gated asset processing in systems like DepositQueue and RedeemQueue. It tracks user requests via timestamped checkpoints and processes them using oracle-based pricing.
This abstract module is not directly deployable but is designed to be extended by concrete implementations, which define the behavior of _handleReport and allowed user actions (deposit / redeem functions).
Purpose
- Serves as a modular base for deposit/redeem queues
- Enforces Vault request processing initially triggered by Oracle
- Stores timestamped user action traces via
Checkpoints.Trace224 - Ensures vault-controlled access and proper report validation
Derived contracts
DepositQueue: handles queued deposits after a delayRedeemQueue: handles redemption requests similarly
Use Cases
- Prevents manipulation by requiring delayed processing relative to price updates
Storage Structure
- asset: token used for this queue (ERC20 or native ETH)
- vault: only this address can call
handleReport(...) - timestamps: request history used in the implementations
Initialization
- Must be called by child contracts
- Initializes asset, vault, and creates a starting checkpoint
Oracle Integration
- Called by the vault when an oracle report is available
- Verifies:
- Caller is the
vault - Price is non-zero
- Timestamp is in the past (timestamp < block.timestamp)
- Caller is the
- Internally delegates to
_handleReport(...)(must be implemented by child)
Abstract Hook
- Read and process requests from
_timestamps() - Apply pricing logic to convert shares↔assets
- Mint/burn shares, transfer tokens, etc.
View Functions
Internal Helpers
Events
- Emitted when
handleReport()completes - Signals that all eligible requests up to
timestampwere processed