Skip to main content

Overview

The Queue 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 delay
  • RedeemQueue: 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)
  • Internally delegates to _handleReport(...) (must be implemented by child)

Abstract Hook

Must be implemented by child classes to:
  • 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 timestamp were processed

Errors