Skip to content

Commit 52cb637

Browse files
authored
Merge branch 'qubic:main' into main
2 parents e022389 + 80f1ca6 commit 52cb637

File tree

4 files changed

+985
-0
lines changed

4 files changed

+985
-0
lines changed
Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
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

Comments
 (0)