QanVaultDocs
Launch App
Technical Whitepaper & Smart Contracts

Solvency & Escrow Proofs

This document presents the formal mathematical proofs establishing protocol solvency, non-custodial asset conservation, and constant-time gas scaling for QanVault.

Theorem 1: Conservation of Protocol Solvency#

Statement

For all valid states S_t of the protocol at block time t, total liquid escrow assets held by the PrizeEscrowVault contract are strictly greater than or equal to total outstanding protocol liabilities:

\text{Balance}(\text{Vault}_t) \ge \sum_{j \in \{D, D+1, W, M\}} \text{Reserve}_j(t) + \sum_{k \in \text{Unclaimed}} \text{Prize}_k(t)

Proof

  1. Base Case ($t=0$):

Prior to ticket purchases, \text{Balance}_0 = 0, \text{Reserve}_j(0) = 0, and \text{Unclaimed}_0 = 0. The equality holds trivially ($0 \ge 0$).

  1. Inductive Step (Ticket Purchase):

Assume the condition holds at state S_t. At state S_{t+1}, a player purchases N tickets, transferring $100 \times N$ QANX into the vault.

The smart contract partitions the inflow across the accounting variables according to the fixed basis point vector:

$$\vec{B} = \langle 5000, 3000, 750, 500, 750 \rangle

The change in assets is:

$$\Delta \text{Assets} = 100 \times N

The change in liabilities is:

$$\Delta \text{Liabilities} = (50.0 + 30.0 + 7.5 + 5.0) \times N = 92.5 \times N

The platform operations fee is:

$$\Delta \text{Ops} = 7.5 \times N

Because \Delta \text{Assets} = \Delta \text{Liabilities} + \Delta \text{Ops}, and \Delta \text{Ops} \ge 0:

$$\Delta \text{Assets} \ge \Delta \text{Liabilities}

Therefore, solvency is preserved across every purchase transaction. \blacksquare

Theorem 2: Zero Double-Counting of Ticket Entries#

Statement

No ticket ID T_i can ever be credited more than once within the same draw tier.

Proof

  1. Each ticket batch transaction records a contiguous interval of tickets:
$$I_k = [T_{\text{start}}^{(k)}, T_{\text{end}}^{(k)}]
  1. The global counter increments strictly monotonically:
$$T_{\text{start}}^{(k+1)} = T_{\text{end}}^{(k)} + 1
  1. Therefore:
$$I_j \cap I_k = \emptyset \quad \forall j \ne k
  1. Because all intervals are mutually disjoint, each ticket integer T_i \in \mathbb{N} maps to exactly one owner address and exactly one purchase timestamp. Double counting is impossible by construction. \blacksquare

Theorem 3: Rollover Asset Conservation#

Statement

When a prize goes unclaimed past the 72-hour window, the rollover transition preserves total protocol equity without loss or leakage:

\Delta \text{Total Liabilities}_{\text{rollover}} = 0

Proof

When triggerRollover(drawId) executes:

  1. The unclaimed prize balance \text{Prize}_k is deducted from the pending claim ledger:
$$\text{PendingClaims}_{\text{new}} = \text{PendingClaims}_{\text{old}} - \text{Prize}_k
  1. The exact same quantity \text{Prize}_k is credited to the seed reserve of draw k+1:
$$\text{Reserve}_{k+1, \text{new}} = \text{Reserve}_{k+1, \text{old}} + \text{Prize}_k
  1. The net change in total protocol obligations is:
$$\Delta \text{Obligations} = (-\text{Prize}_k) + (+\text{Prize}_k) = 0

No tokens leave the vault, no new claims are manufactured, and zero fees are extracted during rollover. \blacksquare

Theorem 4: Logarithmic Winner Resolution#

Statement

Given B total purchase batches, the gas cost of identifying the winning wallet address for an arbitrary winning ticket ID T_{\text{win}} scales as:

O(\log B)

Proof

Because batch ranges are strictly sorted and monotonically increasing:

T_{\text{start}}^{(1)} < T_{\text{start}}^{(2)} < \dots < T_{\text{start}}^{(B)}

The contract searches for the interval containing T_{\text{win}} using binary search:

  • At each comparison step, the search interval is halved:
$$B_{k+1} = \left\lfloor \frac{B_k}{2} \right\rfloor
  • The maximum number of comparisons is bounded by \lceil \log_2 B \rceil.
  • For a draw with 10,000 separate purchase batches, winner identification requires at most 14 storage reads, guaranteeing safe execution within standard block gas limits. \blacksquare

Next Steps#

PreviousSystem Architecture & SpecsNextContract Registry & Addresses