# 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:

```solidity
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:

```solidity
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

```solidity
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

```solidity
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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://metavaults.mellow.finance/architecture/queues/signaturequeue.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.