|
| 1 | +# QReservePool (QRP) |
| 2 | + |
| 3 | +## Available Options |
| 4 | +> Option 0: no, dont allow |
| 5 | +
|
| 6 | +> Option 1: yes, allow |
| 7 | +
|
| 8 | +## Table of Contents |
| 9 | + |
| 10 | +1. [Introduction](#1-introduction) |
| 11 | +2. [Goals and Non-Goals](#2-goals-and-non-goals) |
| 12 | +3. [Core Model](#3-core-model) |
| 13 | +4. [Interface Summary](#4-interface-summary) |
| 14 | +5. [Access Control](#5-access-control) |
| 15 | +6. [Integration: QThirtyFour (QTF)](#6-integration-qthirtyfour-qtf) |
| 16 | +7. [Future Integrations: RL-family Projects](#7-future-integrations-rl-family-projects) |
| 17 | +7. [Code](#8-code) |
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | +## 1. Introduction |
| 22 | + |
| 23 | +QReservePool (QRP) is a shared on-chain reserve vault implemented in `src/contracts/QReservePool.h`. |
| 24 | +Its purpose is to provide a simple, reusable backstop reserve that allowlisted smart contracts can draw from when their own per-epoch cashflow is insufficient to meet obligations. |
| 25 | + |
| 26 | +At the current stage, QRP is required by `src/contracts/QThirtyFour.h` (QTF) as a reserve source for payout floors and jackpot carry rebuild scenarios. |
| 27 | +In the future, other RandomLottery-style projects are expected to use this same pool instead of deploying separate reserve contracts. |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +## 2. Goals and Non-Goals |
| 32 | + |
| 33 | +### Goals |
| 34 | + |
| 35 | +- **Centralize reserve management** in a single contract. |
| 36 | +- **Restrict withdrawals** to allowlisted smart contracts only. |
| 37 | +- **Keep the surface minimal** and easy to audit. |
| 38 | +- **Enable reuse** by future RL-family contracts via allowlisting. |
| 39 | + |
| 40 | +### Non-Goals |
| 41 | + |
| 42 | +- Per-consumer accounting or “sub-balances” per project. |
| 43 | +- Rate limiting, per-epoch quotas, or per-winner limits. |
| 44 | +- Enforcement of any consumer economics/spec rules (those belong to consumer contracts). |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +## 3. Core Model |
| 49 | + |
| 50 | +### Reserve Definition |
| 51 | + |
| 52 | +QRP treats its available reserve as the net balance of its entity: |
| 53 | + |
| 54 | +- `availableReserve = incomingAmount - outgoingAmount` (clamped to >= 0) |
| 55 | + |
| 56 | +### Withdrawal Model |
| 57 | + |
| 58 | +- A consumer contract requests a withdrawal by calling `GetReserve`. |
| 59 | +- If the caller is allowlisted and enough reserve is available, QRP transfers the requested amount to the invocator. |
| 60 | + |
| 61 | +--- |
| 62 | + |
| 63 | +## 4. Interface Summary |
| 64 | + |
| 65 | +| Method | Type | Purpose | |
| 66 | +|--------|------|---------| |
| 67 | +| `GetReserve` | Procedure | Withdraw reserve to an allowlisted contract (caller = invocator). | |
| 68 | +| `AddAvailableSC` | Procedure | Owner-only: add a contract index to the allowlist. | |
| 69 | +| `RemoveAvailableSC` | Procedure | Owner-only: remove a contract index from the allowlist. | |
| 70 | +| `GetAvailableReserve` | Function | Read available reserve (net balance). | |
| 71 | +| `GetAvailableSC` | Function | Read allowlisted smart contracts. | |
| 72 | + |
| 73 | +--- |
| 74 | + |
| 75 | +## 5. Access Control |
| 76 | + |
| 77 | +### Allowlisted Withdrawals |
| 78 | + |
| 79 | +- `GetReserve` must be callable only by allowlisted contract IDs. |
| 80 | +- End users (wallets) cannot withdraw directly. |
| 81 | + |
| 82 | +### Owner Governance |
| 83 | + |
| 84 | +- The allowlist is maintained via owner-only procedures: |
| 85 | + - `AddAvailableSC` |
| 86 | + - `RemoveAvailableSC` |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +## 6. Integration: QThirtyFour (QTF) |
| 91 | + |
| 92 | +QRP is currently needed for QTF (`src/contracts/QThirtyFour.h`) to support: |
| 93 | + |
| 94 | +- **Payout floors backstop:** when epoch revenue is too low to meet minimum guaranteed payouts. |
| 95 | +- **Carry/jackpot rebuild support:** when QTF needs to reseed/rebuild carry after a k=4 jackpot win (subject to QTF’s own safety rules). |
| 96 | + |
| 97 | +QRP itself does not encode QTF-specific limits. QTF must enforce its own caps and policies before calling `GetReserve`. |
| 98 | + |
| 99 | +--- |
| 100 | + |
| 101 | +## 7. Future Integrations: RL-family Projects |
| 102 | + |
| 103 | +The long-term intent is for multiple RL-derived contracts (RandomLottery-style) to share the same reserve pool: |
| 104 | + |
| 105 | +- New consumer onboarding should be done by adding the contract to QRP allowlist (by contract index). |
| 106 | +- Each consumer contract must implement its own safety caps, governance constraints, and usage policy. |
| 107 | + |
| 108 | +This approach avoids deploying (and auditing) a separate reserve contract for every RL-family project. |
| 109 | + |
| 110 | +--- |
| 111 | + |
| 112 | +## 8. Code |
| 113 | + |
| 114 | +[QThirtyFour](https://github.com/N-010/core/blob/feature/2025-11-04-QThirtyFour/src/contracts/QThirtyFour.h) |
| 115 | + |
| 116 | +[QReservePool](https://github.com/N-010/core/blob/feature/2025-11-04-QThirtyFour/src/contracts/QReservePool.h) |
| 117 | + |
| 118 | +--- |
0 commit comments