SignatureQueue

Purpose

The SignatureQueue enables instant user deposits or redemptions using off-chain signed approvals from a trusted consensus group. This queue type bypasses the normal time-delayed queuing mechanism (e.g., DepositQueue, RedeemQueue) by verifying orders via EIP-712 or EIP-1271 signatures, offering fast-lane access for users while preserving oracle-bound price safety.

Key Features

• Instant execution without waiting for oracle price reports

• Nonce-based signature protection to prevent replay attacks

• EIP-712/EIP-1271 compatible signed orders

• Oracle price validation enforced on-chain

• Stateless and removable (i.e., does not accumulate shares or process claims)

• Fee-bypassed: No depositFee or redeemFee is charged for actions via this queue

High-Level Workflow

1. Off-chain consensus actors (e.g., operators, curators, admins) generate signed Order messages.

2. A user submits this order to the SignatureQueue contract for execution.

3. The queue:

   • Verifies the order signature

   • Validates nonce, queue address, asset match, deadline, and caller

   • Computes the implied asset/share price and checks it against the vault's oracle

4. If all checks pass, the order is executed atomically.

Order Structure

Each order encapsulates all the necessary metadata for verification:

struct Order {
    uint256 orderId;       // Off-chain tracking ID
    address queue;         // Must match queue address
    address asset;         // Token involved in deposit/redeem
    address caller;        // Must match msg.sender
    address recipient;     // Recipient of assets or shares
    uint256 ordered;       // Assets in (deposit) or shares out (redeem)
    uint256 requested;     // Shares out (deposit) or assets in (redeem)
    uint256 deadline;      // Expiration timestamp
    uint256 nonce;         // Unique per caller
}

Signature Validation

• Orders are signed by a quorum of validators registered in the Consensus contract.

• Signatures can conform to:

  • EIP-712 (structured message hashing)

  • EIP-1271 (smart contract-based signature schemes)

The order hash is computed via:

keccak256(
    abi.encode(
        ORDER_TYPEHASH,
        order.orderId,
        order.queue,
        order.asset,
        order.caller,
        order.recipient,
        order.ordered,
        order.requested,
        order.deadline,
        order.nonce
    )
);

Price Safety Check

After signature verification, SignatureQueue uses the vault’s Oracle to validate the price:

• Deposits: price = requestedShares / depositedAssets

• Redemptions: price = burnedShares / redeemedAssets

• Oracle must confirm:

  • Price is within allowed bounds

  • Price is not marked as suspicious

Otherwise, the operation is rejected with InvalidPrice.

Storage Layout

struct SignatureQueueStorage {
    address consensus;                        // Signature validator contract
    address vault;                            // Parent vault (Vault.sol)
    address asset;                            // Supported ERC20 token or native ETH
    mapping(address => uint256) nonces;       // Per-user nonces
}

Interface Compatibility

Despite not using claimable balances, SignatureQueue implements stub methods for compatibility with the IQueue interface:

• claimableOf(...) → 0

• claim(...) → false

• handleReport(...): no-op

• canBeRemoved() → true: confirms it has no persistent state

Events

event OrderExecuted(Order order, IConsensus.Signature[] signatures);

Emitted after a signed order is successfully executed.

Security Assumptions

• Only trusted off-chain actors (consensus group) are authorized to sign orders.

• Price quotes must match oracle-defined asset/share rates.

• Users cannot reuse old signatures due to nonce tracking.

• Orders must be executed before deadline.

Use Cases

• Instant UX: bypassing delays in DepositQueue or RedeemQueue

• Institutional integrations: where trusted relayers or coordinators pre-sign valid actions

• Fallback mechanism: during oracle lags or downtime

Limitations

• Does not charge fees (unlike time-delayed queues)

• Requires trusted off-chain actors

• Less decentralized if consensus actors are not well-audited or rotated