Skip to content

Tokenomics Proposal v1 — Open Questions for Client

Source doc: docs/tokenomics-proposal.md (DRAFT v1, reviewed 2026-04-22) Cross-checked against: docs/system-spec-summary.md (digest of QuantaTrade_AI_System_Specification FINAL.docx.pdf) Audience: QT Labs (client), smart contract auditors Purpose: Resolve before Milestone 2 (Smart Contracts & Custody) — SaleManager and AllocationVesting contracts cannot be written against contradictory numbers.


1. Authoritativeness (blocker for M2)

docs/tokenomics-proposal.md (v1 DRAFT) conflicts with system-spec-summary.md (digest of the client's FINAL PDF spec) on almost every economic parameter.

  • Question: Is tokenomics-proposal.md superseded by the system-spec FINAL PDF? If yes, this file should be deleted or clearly marked OBSOLETE to prevent engineers from building against stale numbers.
  • Question: If not superseded, which document is authoritative where they conflict?
  • Recommendation: Pick one, delete/archive the other. Keeping both invites a costly mis-build.

1.1 Round prices — 3-5x apart

Round v1 proposal system-spec Delta
Pre-Seed $0.0200 $0.0046 4.3x
Seed $0.0400 $0.0065 6.2x
Private A $0.0600 $0.0090 6.7x
Private B $0.0800 $0.0190 4.2x
Private C $0.0900 $0.0320 2.8x
Public $0.1000 $0.0400 2.5x
  • Question: Which price schedule is correct?
  • Risk: Pre-Seed and Seed are listed as "Closed" in v1 — if real completed sales used system-spec prices ($0.0046, $0.0065), v1's $2.6M / $6.4M raise figures are not just forecasts, they are wrong attestations of historical raise amounts.

1.2 Total raised — $31.8M vs $7.883M

  • v1 claims $31.8M across 6 rounds.
  • System-spec says $7.883M across 6 rounds (matches user memory project_token_and_raise.md).
  • Question: What has actually been raised as of today? A 4x discrepancy is not a rounding error.

1.3 Token allocations don't match

Partially resolved 2026-04-22: Seed round = 120M tokens (client confirmed; system-spec value is correct, v1's 160M is wrong).

Note: the client's own docs/delivery-plan.html (Phase 1 + 2 Delivery Plan) §M2 "Allocation Requirements" also lists Seed = 160M. The 160M figure has propagated into multiple client-produced docs. Every doc carrying 160M is stale and should be corrected.

Bucket v1 proposal system-spec Confirmed
Private rounds (Pre-Seed through Private C) 530M 535M
Public 50M 45M
Team & Advisors 144M (12.0%) 155M (12.9%)
Treasury 180M (15.0%) 200M (16.7%) "& liquidity"
Staking Rewards 120M (10.0%) — (revenue-funded, no inflation)
Ecosystem/Grants 96M (8.0%)
DEX Liquidity 60M (5.0%) Included in "Treasury & liquidity"
Marketing 20M (1.7%) 80M pre + 185M post = 265M (22.1%)
Seed round tokens 160M 120M 120M ✓ (2026-04-22)
  • Question: Reconcile the allocation buckets. v1's 120M "Staking Rewards" bucket implies emission-based rewards — this directly contradicts the system-spec's "revenue-funded reward pool (no inflation)" principle. Pick one model.
  • Question: Does v1's 96M "Ecosystem/Grants" bucket exist at all in the FINAL spec?

1.4 Vesting schedules differ

v1 Team vesting: 12mo cliff, 36mo linear (48 months total). System-spec Team vesting: 12mo cliff, 24mo linear (36 months total).

  • Question: Which schedule is in the executed investor agreements? This is legally binding in individual token purchase agreements.

2. Fee rebate tiers — not in system-spec

v1 §"Fee Rebate Tiers" defines six tiers (0 / 10K / 50K / 100K / 500K / 1M staked) with discounts 0–25%.

System-spec §5.1 states a single $QTRA-holder discount (0.03%/0.06% vs standard 0.05%/0.10%) — no tier structure.

  • Question: Which fee model is correct? A tiered model vs. a single-tier model are entirely different contract designs.
  • Risk: If v1's six-tier model is correct, the fee-rebate logic in the exchange engine (M1) and staking contract (M5) needs to read tier thresholds, not just a boolean is-staker check.

3. Chain selection

v1: "Base (Ethereum L2)". System-spec: "ERC-20 on EVM chain (chain TBD)". tech-decisions.md §1: chain decision pending.

  • Question: Has Base been confirmed? If yes, update tech-decisions.md and delete the "TBD" note. If no, v1's Base assumption is premature.

4. Buyback rate basis

v1: "Normal rate: 10% of net profit". System-spec §6 revenue routing: buyback takes specified percentages of specific revenue streams (10% of exchange fees, 10% of trading profit, 10% of licensing — 0% of subscriptions).

  • Question: Is buyback 10% of net profit (v1) or 10% of certain revenue streams (system-spec)? These are very different mechanics and produce very different on-chain flows.

5. Sale round status claim

v1 marks Pre-Seed and Seed as "Closed" and Private A/B as "Active".

  • Question: Confirm current sale status per round. The SaleManager contract (M2) will need accurate roundStatus initial values so the deploy transaction doesn't reopen closed rounds.
  • Question: For each "Closed" round, do we have the final Merkle root of accepted allocations? Needed for any reconciliation or retrospective claim contract.

6. Epoch definition

v1 §Epoch Definition specifies a 7-day epoch aligned to the 2% wallet cap and weekly revenue deposit.

  • Question: Is the epoch wall-clock (every Monday 00:00 UTC) or relative (7 days from contract deployment)? Wall-clock needs timezone; relative needs a known deploy time.
  • Question: What happens in the last incomplete epoch before cooldown/unstake — does the partial window count toward the 2% cap?

Sign-off required before M2 kickoff

# Item Owner Status
1 Authoritative tokenomics doc (v1 vs system-spec) QT Labs Open — blocker
1.1 Round price schedule QT Labs Open — blocker
1.2 Actual total raised to date QT Labs finance Open — blocker
1.3 Final allocation buckets (incl. staking-rewards inflation question) QT Labs Open — blocker
1.4 Team vesting (36mo vs 24mo linear) QT Labs + counsel Open — blocker
2 Fee rebate: tiered or single-tier QT Labs + product Open
3 Chain: Base confirmed? QT Labs + tech team Open
4 Buyback basis: net profit vs per-stream QT Labs Open
5 Current round status + Merkle roots for closed rounds QT Labs operations Open — blocker
6 Epoch reference (wall-clock vs relative) Spec author Open