Skip to content

System Specification — Open Questions for Client

Source doc: QuantaTrade_AI_System_Specification FINAL.docx.pdf (8 pages, via docs/system-spec-summary.md, reviewed 2026-04-22) Audience: QT Labs (client), product, compliance, auditors Purpose: Resolve before Milestones 1, 2, 4, and 5. Questions here are distinct from staking-open-questions.md (staking spec) and tokenomics-open-questions.md (tokenomics v1 draft).

Many of the items below were flagged as "missing sections" in system-spec-summary.md — the PDF appears truncated. Full system spec request is the primary action.

1. Missing PDF sections (primary request)

PDF cover advertises sections the extract does not contain. These are hard blockers until received:

  • Buyback engine mechanics (L1 + L2 two-layer structure, trigger conditions, execution venue, MEV handling) — blocks M5 contract design
  • Technical requirements section — blocks M1 architecture sign-off
  • §10.1 "Pre-funded defences" itemised ($4.60M aggregate referenced, not broken down) — blocks budget reconciliation and treasury modelling

  • §§7–9 (transition from §6.5 to end is abrupt) — unknown content, blocker unknown

  • Action: Request full FINAL version from client. Without these, M5 contract freeze cannot happen.

2. §5.1 Exchange fee math — "78% discount" does not compute

Spec states: - Standard maker/taker: 0.05% / 0.10% - $QTRA holder: 0.03% / 0.06% - "$QTRA holders get ~78% discount"

Direct calculation: - (0.05 − 0.03) / 0.05 = 40% off maker - (0.10 − 0.06) / 0.10 = 40% off taker

  • Question: What baseline is the "78% discount" measured against? Binance standard (0.10/0.10)? Coinbase retail (0.60% taker)? A blended "majors average"? The baseline is load-bearing for the marketing claim and must be defined.
  • Risk: The UI rule (§5.1) mandates displaying "exact rates + $QTRA discount on the trading page". If the displayed discount number doesn't match the math, users will flag it and compliance can treat it as a misleading promotional claim.

3. §5.2 Automated Trading — "all tiers get the same AI"

Eight subscription tiers from $9.99/mo (Basic, ≤$2.5K portfolio) to $3,999/mo (Institutional, unlimited). Spec states: "all tiers get the same AI. Differentiator is portfolio size, not features."

  • Question: If the AI is identical, what stops a $3,999 user from splitting a $200K portfolio into 80 × $2.5K Basic accounts at $9.99 each (saving ~$3,200/mo)?
  • Question: Is the portfolio-size gating enforced per wallet, per KYC identity, per payment method, or per account? This is an anti-abuse / KYC question that affects compliance design (M4) and exchange engine account model (M1).
  • Question: Are tiers enforced by blocking trades above the ceiling, or by price-based throttling (e.g. lower execution priority)? First is a hard limit; second is a soft SLA. They are different product experiences and different regulatory postures.

4. §5.4 AI Hedge Fund — fund economics and regulation

"$10M → $100M AUM, 25% target ROI, 70/30 investor/platform split. Y5 platform profit $7.5M."

Arithmetic: $100M × 25% × 30% = $7.5M ✓.

  • Question: Is the 30% platform share taken from gross period profit or net of high-water-mark (HWM) carry-forward? In a drawdown year, first design takes fees on no recovery; second does not. Standard hedge-fund structure is net-of-HWM.
  • Question: Are there management fees (e.g. 2% of AUM) in addition to the 30% performance split, or is this a 0-and-30 structure? Affects Y5 revenue line.
  • Question: Is the fund a regulated vehicle (investment adviser, AIF, Reg D offering)? "AI Hedge Fund" accepting up to $100M from "investors" with a 70/30 split is a securities-regulated product in every major jurisdiction.
  • Question: Legal structure — Cayman master-feeder, Delaware LP, BVI SPC, offshore SAC? Affects onboarding and cross-border wires.

5. §5.6 EBITDA trajectory — Y1 30% margin is aggressive

Y1 EBITDA 30% while simultaneously launching five product lines (exchange, automated trading, intelligence marketplace, hedge fund, licensing) is high for an early-stage multi-product platform. Comparable multi-product exchanges have Y1 EBITDA near or below 0%.

  • Question: What COGS / OpEx lines is the EBITDA model netting? Specifically:
  • Exchange liquidity provisioning costs (market-maker rebates, LP incentives)
  • KYC vendor per-check cost (Sumsub bulk tier ~$1–3 per check)
  • Cloud infra for matching engine + data warehouse
  • Compliance + legal headcount
  • Customer acquisition cost (CAC) per subscriber across three product lines
  • Payment processing fees (card + wire)
  • Risk: If Y1 EBITDA is materially lower than 30%, the $3.28M working capital (system-spec §4 note) extends to a shorter runway, which changes the urgency of the Public round (M3 timing).

6. §6 Revenue router — off-chain splits still on-chain-visible?

Spec: "token-economy splits (staker rewards, L1 buybacks) enforced on-chain by the immutable revenue router. Operational/treasury/retained splits are managed internally (off-chain — would be gas-wasteful on-chain)."

  • Question: If operational/treasury/retained splits are off-chain, how is this attested to stakers / $QTRA holders? The stakers are receiving their 20–50% share on-chain — do they have assurance the remaining 80% went where the spec claims?
  • Question: Is there an on-chain "revenue deposited" event, separate from "staker reward emitted", so the total revenue flowing through the router is auditable even if splits are off-chain?
  • Question: Are off-chain splits attested by audit firm quarterly? Without attestation the "enforced on-chain" framing is undermined.

7. §3 UI rule — "do not label unlocked tokens as 'available to sell'"

Spec mandates the unlocked-vs-available distinction in UI copy.

  • Question: Is this rule exposed to third-party wallet integrations (e.g. a user's MetaMask or a CEX that lists $QTRA)? The vesting contract's balanceOf semantics determine what wallets show — if the token is transfer-locked pre-vest it shows correctly; if tokens are transferable post-unlock but with a UI warning only in our app, external wallets will still show them as available.
  • Decision needed: is transferability gated at the contract level (strict), or at the UI level only (soft)? Affects vesting contract design (M2).

8. §1 Hedge fund revenue labelling in product-suite table

The §1 "Product suite" table lists Y5 targets as revenue per product — except AI Hedge Fund, which shows "$7.5M platform profit" (profit, not revenue). Y5 revenue total ($59M) excludes this profit line.

  • Clarification needed: is the hedge-fund fee stream included in the consolidated revenue table (§5.6, "Trading profit" row at $7.5M) or separate? §5.6 row label "Trading profit" is ambiguous — does it mean hedge-fund fees, proprietary trading, or both?

9. Subscription currency + payment rails

§5.2: "Paid monthly in USDT/USDC."

  • Question: Does this mean subscribers fund with USDT/USDC only (no card / fiat), or subscribers can pay with card and we convert to USDT/USDC on our side? Huge operational difference — first is web3-native onboarding friction, second needs PCI compliance and a card processor.
  • Question: If card payments are accepted, where does the conversion to USDT/USDC happen, and does the revenue router see the USDT/USDC or the fiat-equivalent?

Sign-off required

# Item Owner Gate
1 Full FINAL PDF (buyback + tech reqs + defences + §7–9) QT Labs M1 architecture freeze, M5 kickoff
2 "78% discount" baseline definition QT Labs marketing Before UI launch
3 Portfolio tier enforcement model QT Labs + compliance M4
4 Hedge fund fee model + regulatory wrapper QT Labs + counsel Before hedge-fund launch (not in M1–M10 scope?)
5 Y1 EBITDA cost breakdown QT Labs finance Before Public round
6 Revenue router off-chain attestation design QT Labs + auditor M5
7 Vesting transferability — contract vs UI QT Labs M2
8 Hedge-fund line in §5.6 — revenue or profit Spec author Reconcile before next status update
9 Subscription payment rail (USDC-only vs card→convert) QT Labs + product M4