QanVaultDocs
Launch App
Security, Legal & FAQ

Threat Model & Attack Mitigations

This document outlines the security perimeter, identified threat vectors, and corresponding smart contract mitigations designed into QanVault.

1. Randomness Manipulation & Frontrunning#

The Threat

An attacker, miner, or compromised keeper attempts to inspect pending transactions or manipulate block headers to force a specific winning ticket ID.

Mitigations

  1. Two-Phase Commit-Reveal: The keeper must commit H = \text{keccak256}(\text{Seed} \parallel \text{DrawId} \parallel \text{BlockHash}) while ticket purchases are still active. Once committed, ticket purchases for that draw are frozen.
  2. Block-Hash Entropy Anchoring: The revealed seed is combined with blockhash(CommitBlockNumber). Because miners cannot predict future block hashes with certainty, neither the keeper nor external actors can unilaterally predetermine the winning index.
  3. VRF Modular Upgrades: Mainnet contracts support cryptographic VRF oracles (Chainlink VRF and native QAN post-quantum VRF) where randomness proofs are verified on-chain before acceptance.

2. Duplicate Ticket Entries & Sybil Flooding#

The Threat

A participant attempts to submit identical ticket IDs across multiple draws or claim a prize twice.

Mitigations

  1. Strict Monotonic Range Allocation: Ticket IDs are assigned as contiguous intervals [T_{\text{start}}, T_{\text{end}}]. The starting ID of batch k+1 is strictly T_{\text{end}}^{(k)} + 1. Duplicate IDs cannot exist.
  2. Distinct Winner Sampling: Multi-slot draws derive distinct winner indices without replacement. If an index resolves to a ticket owned by an already-selected winner, the pseudo-random generator advances to the next candidate until all slots are filled by unique players.
  3. Single Claim Guard: Winning claim statuses are stored in a persistent mapping: draws[drawId].claimed = true. Replaying a claim call reverts immediately.

3. Reentrancy & Escrow Drainage#

The Threat

A malicious smart contract attempts to hijack control flow during a prize claim or token swap to drain vault funds before accounting variables are updated.

Mitigations

  1. Checks-Effects-Interactions (CEI): All state updates (marking tickets claimed, updating prize reserves) are completed before executing external ERC-20 transfers.
  2. Transient Reentrancy Locks: Implements OpenZeppelin's ReentrancyGuardTransient, which utilizes EIP-1153 TSTORE and TLOAD opcodes to block recursive entry points.

4. Cross-Chain Bridge Stoppage or Censorship#

The Threat

The cross-chain bridge encounters congestion, relayer downtime, or network reorganization on Ethereum.

Mitigations

  1. Decoupled Ticket Minting: Ticket purchases on Ethereum are registered in the canonical BSC ledger independently of the background bridge rebalancing operation. A temporary delay in bridge relayer execution does not delay a player's entry into the scheduled draw.
  2. Batch Liquidity Safeguards: Escrow contracts hold liquidity securely until the $2,500 threshold or daily cutoff triggers, preventing small, vulnerable micro-bridge transactions.

Next Steps#

PreviousSecurity Audit & InvariantsNextFrequently Asked Questions (FAQ)