> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mellow.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 theme={null}
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 theme={null}
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 theme={null}
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 theme={null}
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