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
depositFeeorredeemFeeis charged for actions via this queue
High-Level Workflow
Off-chain consensus actors (e.g., operators, curators, admins) generate signed
Ordermessages.A user submits this order to the
SignatureQueuecontract for execution.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
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
Consensuscontract.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 / depositedAssetsRedemptions:
price = burnedShares / redeemedAssetsOracle 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(...) → 0claim(...) → falsehandleReport(...): no-opcanBeRemoved() → 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
DepositQueueorRedeemQueueInstitutional 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