10 — Planned modules¶
As of 2026-05-28. This is a CROSS-LINK doc — every claim points to the authoritative spec doc in docs/.
Why this doc exists¶
Reference docs 01–09 cover code that runs today: services in QuantaTradeAI/platform, the Java matching engine, the admin panel, the data model, the event bus, the EC2 deployment. This doc covers everything that is specified in docs/ but is not yet code — the smart contracts (M2/M5), the ICO/presale platform (M3), custody (M2), compliance (M4), the chain indexer (M2), the strategy engine (M4), Phase 2 deliverables (M6–M10), and the cross-cutting legal/oracle blockers that gate M5 sign-off. Per the components index, 14 components are planned across the contract; 8 of them have either no code or only a scaffold. Where work has started, the section says so. Where it hasn't, the section says so. The authoritative design lives in docs/*-proposal.md, docs/*-spec*.md, and docs/*-plan.md — this doc does not duplicate them, it points at them.
Status legend (borrowed from milestone-1-status.md): 🟢 in production, 🟡 in flight / partial, 🔴 not built.
1. Smart contracts¶
The contract repo is QuantaTradeAI/contracts. As of 2026-05-02 it carries 12 Solidity files totalling 1,471 LOC, 115 tests passing, and 99–100% statement coverage on the M2 surface (token + sale + vesting). The M5 surface (staking + revenue router) sits at 0% coverage and remains design-only. See milestone-2-status.md for the full per-line audit.
1.1 $QTRA ERC-20 token¶
Milestone: M2. Status: 🟡 — implementation written, supply cap wrong, testnet deploy not run.
The token is an OpenZeppelin ERC20 + ERC20Burnable + ERC20Permit extension at QTRAToken.sol:17. The spec calls for 1,200,000,000 fixed supply with mint permanently disabled and no admin key, no upgrade proxy (system-spec-summary.md §2, tokenomics-proposal.md "Token Overview"). The contract today has MAX_SUPPLY = 1_000_000_000e18 — 1B, not 1.2B — and still exposes a mint() function gated by MINTER_ROLE rather than removing the mint path entirely (QTRAToken.sol:20, 27–29, audited in milestone-2-status.md §Token).
Both deviations are tracked as open question T-1 (supply cap) in tokenomics-open-questions.md and the immutability posture question §4 in staking-open-questions.md. The client has confirmed hard-immutability for the token contract specifically: "no admin key, no upgrade proxy for the token contract", per system-spec-summary.md "What this spec clarifies". The implementation must be amended to match before audit.
Authoritative spec: tokenomics-proposal.md "Token Overview" table; system-spec-summary.md §2 "Token basics".
Key blockers:
- Supply cap mismatch (1B vs 1.2B) — milestone-2-status.md open question T-1.
- Mint function still present despite spec saying "permanently disabled" — needs removal, not just role gating.
- Chain selection still nominally TBD per tech-decisions.md §1 (recommendation: Base), though tokenomics-proposal.md already names Base as the deployment target.
1.2 SaleManager¶
Milestone: M2. Status: 🟡 — six rounds implemented, dual on-chain / Merkle-import path needs disambiguation, no testnet deployment recorded.
SaleManager.sol accepts USDC purchases against six rounds — PRE_SEED (0), SEED (1), PRIVATE_A (2), PRIVATE_B (3), PRIVATE_C (4), PUBLIC (5). Per-round caps (tokenCap, usdcCap, per-wallet walletCap) are enforced at SaleManager.sol:192–210. Whitelist gating uses MerkleProof.verify against round.merkleRoot for non-public rounds (SaleManager.sol:179–183); the public round skips the Merkle check. USDC is the only payment token (single immutable address at SaleManager.sol:40, 220). The contract test suite covers all of the above and passes (milestone-2-status.md §Sale).
Richard's M2 checklist (milestone-acceptance-criteria.md §Sale) lists only Private A / B / C / Public — Pre-Seed and Seed are intended to land via AllocationVesting Merkle import (off-chain rounds, on-chain claim). The contract currently supports both paths. Open question §T-2 / §S-6 in milestone-acceptance-criteria.md asks whether the on-chain Pre-Seed/Seed path should be removed or left as a fallback.
Authoritative spec: tokenomics-proposal.md "Sale Round Details", milestone-acceptance-criteria.md §"Smart Contracts — Sale".
Key blockers:
- Round pricing discrepancy 3–7x between tokenomics-proposal.md and system-spec-summary.md — open question §1.1 in tokenomics-open-questions.md. Until the price schedule is fixed, the setRound() configuration calls in scripts/setup-testnet.ts can't be parameterised correctly.
- Seed allocation total (160M per Richard vs 120M per system spec, resolved 2026-04-22 in favour of 120M — but the 160M figure has propagated into multiple client docs that need correcting; see tokenomics-open-questions.md §1.3).
- Multi-sig wiring on ADMIN_ROLE is missing — the contract is currently a single EOA. SaleManager.sol:10–11 carries an AUDIT comment recommending OZ Safe + TimelockController. Must be addressed before mainnet (milestone-2-status.md §Custody — Institutional).
- Testnet deployment never executed end-to-end; no recorded contract addresses (milestone-2-status.md §Delivery).
1.3 Vesting¶
Milestone: M2. Status: 🟡 — 6 schedules hardcoded, Merkle import works, end-to-end test passes, claim totals not yet reconciled against real Merkle trees.
AllocationVesting.sol carries the six per-round vesting schedules hardcoded at AllocationVesting.sol:102–107:
| Round | Cliff | Linear | TGE unlock |
|---|---|---|---|
| Pre-Seed | 12 mo | 24 mo | 0% |
| Seed | 6 mo | 18 mo | 0% |
| Private A | 3 mo | 12 mo | 0% |
| Private B | 3 mo | 12 mo | 0% |
| Private C | 1 mo | 9 mo | 0% |
| Public | 0 | 6 mo | 25% |
These match tokenomics-proposal.md "Vesting Parameters". The Pre-Seed and Seed rounds are claimed via Merkle proof through claimAllocation() (AllocationVesting.sol:145–167). Continuous claims work via claim() and collectVested() (AllocationVesting.sol:211–227); all claim paths are gated on tgeTimestamp > 0 && block.timestamp >= tgeTimestamp. The "End-to-end: Merkle import → claim allocation → vest" test in AllocationVesting.test.ts (one of 59 tests) exercises the Pre-Seed flow Richard explicitly named.
Team vesting (a separate bucket from sale rounds) is not yet wired as a contract path — see open question §1.4 in tokenomics-open-questions.md: tokenomics-proposal.md says "12mo cliff, 36mo linear" (48mo total), system-spec-summary.md §3 says "12mo cliff, 24mo linear" (36mo total). The schedule that's in the executed investor agreements is the authoritative one — needs counsel to confirm.
Authoritative spec: tokenomics-proposal.md "Vesting Parameters", system-spec-summary.md §3.
1.4 Staking¶
Milestone: M5. Status: 🔴 — design complete and unambiguous on parameters, 8 open questions block contract freeze, code is StakingVault.test.ts placeholder only (18 tests, 0% coverage on the actual contract).
The staking design is the most fully-specified non-built component in the project. staking-system-spec.md (the client's FINAL .docx) covers: revenue-funded reward pool (no inflation), five lock tiers with immutable weights (7d/1.00x, 30d/1.05x, 90d/1.20x default, 6mo/1.40x, 1yr/1.60x), six immutable safeguards (10M token activation threshold, 100 staker min, 2% wallet cap per epoch, 1K $QTRA stake min, $5M annual treasury floor, continuous per-second accrual), six automatic circuit breakers, 7-day claim vesting with forfeit-to-pool on break, 7-day warmup, 3-day cooldown, auto-compound by default. m5-token-utility-plan.md translates this into StakingVault.sol + RewardDistributor.sol + CircuitBreaker.sol (sketched Solidity in §"Detailed Specifications"). Stress tests at $0.10 token price project ~37% APY at 50% adoption (Y5).
Eight open questions sit in staking-open-questions.md. Of these, four are hard blockers for contract freeze:
| § | Blocker | Why it blocks |
|---|---|---|
| 1.1 | Price oracle design (Chainlink, DEX TWAP, or custom aggregated) | Circuit breaker §5 "token price drops >50% in 7 days → buyback doubles" reads from an oracle that doesn't exist on-chain natively; thin-liquidity TWAP is manipulable. |
| 1.2 | Revenue attester role | The revenue router must know how much fiat/USDT revenue arrived. The attester role contradicts the spec's "no admin can change" language unless the trust assumption is made explicit. |
| 4 | Immutability posture per contract | Token confirmed strict; staking and router are still open. Strict-immutable contracts with critical bugs are permanent. Industry standard is parameter-immutable + multisig+timelock pause. |
| 6 | Legal / jurisdiction | Revenue-share yield may be an investment contract (Howey) in the US. Jurisdictional reach + KYC gating on the staking contract changes the contract surface (Merkle whitelist vs ERC-1404 transfer restrictions). |
The remaining four are clarifications (warmup/cooldown semantics, early-unlock penalty retroactive vs forward-only, tier expiry auto-roll vs drop, claim-stream/unstake interaction) that change behaviour but not architecture. Each is itemised in staking-open-questions.md §3 and §5.
Authoritative spec: staking-system-spec.md (full 8-section design); m5-token-utility-plan.md §WS1 (Solidity sketch); staking-open-questions.md (8 unresolved items).
1.5 Revenue router¶
Milestone: M5. Status: 🔴 — highest-risk contract per client, dedicated audit budgeted separately from staking.
Per system-spec-summary.md §6 quoting the FINAL PDF directly: "The revenue router is the highest-risk contract in the token-economy layer — a bug misdirects staker or buyback funds. It needs a dedicated audit separate from staking contracts." The router receives USDT/USDC revenue from off-chain platform earnings and routes immutable percentages on-chain. Three streams flow through it (per system spec §6, which supersedes tokenomics-proposal.md "Revenue to Staking Pool"):
| Stream | Stakers | Buyback (L1) | Ops / treasury | Retained |
|---|---|---|---|---|
| Subscriptions (AI + Intelligence) | 50% | — | 25% | 25% |
| Exchange trading fees | 20% | 10% | 25% ops + 25% treasury | 20% |
| Platform trading profit | 20% | 10% | 30% | 40% |
| Licensing (B2B) | — | 10% | 50% | 40% |
Only the staker + L1 buyback splits are enforced on-chain; operational/treasury splits are managed off-chain to avoid gas waste. m5-token-utility-plan.md §WS4 sketches RevenueRouter.sol with SUBSCRIPTION_SHARE = 5000, EXCHANGE_FEE_SHARE = 2000, TRADING_PROFIT_SHARE = 2000 (basis points), and a depositRevenue(amount, revenueType) entry point gated by onlyAuthorized.
The router also flows into a TreasuryBackstop.sol ($5M annual floor + $1.5M emergency reserve, per staking-system-spec.md §3 safeguard and §5 circuit-breaker rows). Backstop tops up the reward pool automatically if revenue collapses, and activates the emergency USDC reserve after 90 days of zero revenue. See staking-open-questions.md §1.2 for the revenue-attester design dependency and §2 for the USDT→$QTRA conversion path question (the router receives stablecoins but stakers are paid in $QTRA — the swap happens somewhere, mechanics unresolved).
Authoritative spec: system-spec-summary.md §6 (revenue table + client quote), m5-token-utility-plan.md §WS4 (Solidity sketch + off-chain bridge), staking-open-questions.md §2.
Key blockers: same set as staking §1.4 above (price oracle, revenue attester, immutability posture, legal). Plus: the buyback mechanics — system-spec PDF cover advertised a Buyback section but the extracted PDF is truncated and the section is missing (system-spec-summary.md "Still missing"). Without it, the relationship between router buyback (L1) and the second "L2 buyback" referenced in the overview is undefined.
2. ICO / presale platform (M3)¶
Repo: QuantaTradeAI/presale-app (planned, stub per components-index.md §frontend/presale-app, status 🟡 planned). Milestone: M3. Status: 🔴 — no production code.
The presale app is a Next.js 15 + wagmi/viem frontend that lets whitelisted investors purchase $QTRA against USDC during the four on-chain rounds (Private A/B/C, Public). Scoped deliverables per repo-bootstrap-plan.md §8 and components-index.md:
- Wallet connect (wagmi connectors)
- Round selector (active round + cap status pulled from
SaleManagerview functions) - USDC payment flow (approve +
purchase()call) - Whitelist Merkle-proof check before purchase
- KYC integration gate (Sumsub Tier check — see §5 below; Sumsub itself is M4 scope, so M3 may ship without it and gate the Public round only)
- Transaction receipt + claim portal entry point
The accompanying investor dashboard (QuantaTradeAI/investor-dashboard, also M3, also 🔴) shows per-round holdings, vesting schedule, claimable amount, transaction history. Pulls from the chain indexer (§6 below) which itself isn't built.
The admin panel for presale operations (whitelist CSV upload, Merkle root publish, round status control, TGE config, audit log viewer) is partially in flight as part of QuantaTradeAI/admin-panel — a force-cancel button landed for trading admin (see 01-architecture.md and milestone-1-status.md), but presale-specific admin pages are not yet built. See repo-bootstrap-plan.md §10.
Authoritative spec: architecture.md "Frontend Layer" diagram (lines 34, 51); milestone-acceptance-criteria.md §M2 Sale (drives M3 UI requirements); repo-bootstrap-plan.md §8–10.
Key blockers:
- All M2 smart-contract blockers (round pricing, supply cap, deployed addresses) flow through to the presale app — it can't connect to contracts that don't exist.
- Sumsub contract / API credentials still pending per tech-decisions.md §3.
3. Custody integration (M2)¶
Repo: QuantaTradeAI/custody-service (planned). Milestone: M2. Status: 🟡 — event handler exists in order-router, BitGo webhook upstream not wired.
Custody provider is BitGo, confirmed by client (Richard) on 2026-04-19 — superseding the earlier Fireblocks mandate that had appeared in some draft docs. See tech-decisions.md §2 and the open-question resolution in milestone-acceptance-criteria.md §S-2 (resolved). The contract scope (per Richard's M2 checklist) covers wallet provisioning, policy enforcement, multi-sig approval flows, stablecoin rails (USDC + USDT on Ethereum / BSC / Solana / Tron), fiat rails (SEPA / SWIFT / ACH), and a treasury allocation framework (50% active capital, 50% liquidity/risk reserve).
Today, the custody.deposit.confirmed NATS handler does exist in order-router as a result of the 2026-05-27 deposit-sync wiring — see 01-architecture.md "Authority and trust boundaries" and milestone-1-status.md "Resolved 2026-05-27: balance-sync gap closed". When that event arrives, order-router calls the matching engine's deposit RPC and follows it with a ledger.credit RPC to ledger-service (using txHash as the idempotency key). What is missing is the upstream side: there is no BitGo webhook ingester translating BitGo's HTTPS callbacks into custody.deposit.confirmed NATS messages. For tests today, the event is manually published. See 03-ledger-accounting.md for the downstream ledger semantics and 08-event-bus.md for the NATS subject contract.
Other M2 custody acceptance gates are entirely unstarted per milestone-2-status.md §Custody:
- Multi-sig on the SaleManager ADMIN_ROLE — currently a single EOA (SaleManager.sol:10–11 AUDIT comment).
- USDT support and non-Ethereum chains (BSC/SOL/Tron) — contract side is USDC-only on EVM today.
- Fiat rails — banking-partner decision still open per milestone-1-status.md §S-4.
- Treasury balance-visibility / reporting UI.
Authoritative spec: milestone-acceptance-criteria.md §Custody — Institutional / Multi-signature / Stablecoin rails / Fiat rails / Treasury; tech-decisions.md §2; repo-bootstrap-plan.md §5.
Key blockers: BitGo API credentials + sandbox access pending from client (per components-index.md custody-service entry).
4. Compliance / KYC / AML (M4)¶
Repo: QuantaTradeAI/compliance-service (planned). Milestone: M4. Status: 🔴 — types and tiers encoded in shared types + Prisma schema, no service code.
Per tech-decisions.md §3, Sumsub is the recommended KYC provider — the project already has integration patterns to lean on, and Sumsub natively supports the tiered model the platform needs. Provider selection and contract execution are still pending per components-index.md.
The data model is partially in place. @quantatrade/types exports KycStatus and (per the shared package summary in 01-architecture.md "Shared packages") the user model has a kycLevel field. The mapping is tiered:
none— no KYC, view-only accessbasic— email + phone, low withdrawal limitintermediate— government ID + selfie, higher limitsadvanced— proof of address + source-of-funds attestation, institutional limits
KycLimits (TS interface in @quantatrade/types) defines per-tier withdrawal ceilings. The api-gateway already has KYC tables (per 01-architecture.md "Where the architecture diverges from the original plan"), but no service implements webhook handling, document verification, sanctions screening, or AML transaction monitoring. None of these flows runs today.
Compliance also intersects with staking: staking-open-questions.md §6 asks whether staking requires KYC and at what tier. If the answer is "yes for retail", the staking contract grows a whitelist mapping or ERC-1404 transfer restrictions — a contract-design choice, not just a UI gate.
Authoritative spec: tech-decisions.md §3 (provider rationale), architecture.md "Compliance Layer", repo-bootstrap-plan.md §6 (clone-from source).
Key blockers:
- Sumsub contract + API credentials.
- Jurisdictional scope decision (US, EU, UK, Singapore — staking-open-questions.md §6).
- AML transaction monitoring tooling selection (out of scope for the spec docs as written).
5. Chain indexer (M2)¶
Repo: QuantaTradeAI/chain-indexer (planned new). Milestone: M2 baseline, extended in M3 and M5. Status: 🔴 — no code.
Per components-index.md backend/indexer and repo-bootstrap-plan.md §11, the chain indexer watches on-chain events from the token, sale, vesting, staking, and revenue-router contracts and mirrors state into PostgreSQL + TimescaleDB. Stack is Node.js 20 + viem. Consumers are the investor dashboard (per-round holdings, vesting schedule), the presale admin panel (reconciliation against expected raise totals), and the staking UI (live APY calculation from indexed claim/stake events — see staking-open-questions.md §7 on UI refresh cadence).
The indexer is also where on-chain burn auditability lives (m5-token-utility-plan.md §WS2 "Buyback & Burn") — every BuybackExecuted event flows through to a dashboard showing cumulative burned, remaining supply, and deflation rate.
Authoritative spec: architecture.md "Chain Indexer" entry, repo-bootstrap-plan.md §11, m5-token-utility-plan.md §WS2.
Key blockers: blocked behind M2 contracts being deployed to testnet at all — until then there are no events to index.
6. Strategy engine (M4)¶
Repo: QuantaTradeAI/strategy-engine (planned). Milestone: M4. Status: 🔴 — no code, out of M1 hot path.
Python 3.12 + FastAPI service running ML/quant strategies. Per repo-bootstrap-plan.md §12, the bootstrap source is QuantaTradeAI/backtest-engine + QuantaTradeAI/strategies, adapted from FX-specific strategies (mean reversion, funding-spread arbitrage) to crypto. The engine emits signals consumed by the matching engine and (post-M7) by the AI scanners.
Called out here so readers of the M1 docs don't expect Python strategies — kill-switches and venue failover in milestone-1-status.md §Safeguards are flagged 🔴 partly because the strategy engine doesn't exist; there's nothing to kill yet.
Authoritative spec: delivery-plan-review.md (where present), tech-decisions.md §6, components-index.md strategy-engine entry, repo-bootstrap-plan.md §12.
7. Market data service (M6)¶
Repo: QuantaTradeAI/market-data (planned mixed Rust + Node.js). Milestone: Phase 2 M6 ("M1" inside Phase 2 = M6 overall by the contract numbering). Status: 🔴 — dedicated service not built; baseline data flows do work via other paths.
Today, the matching engine itself exposes L2 depth via gRPC (milestone-1-status.md §Execution Engine confirms GET /api/v1/markets/BTC-USDT/orderbook returns real bids/asks), and the ws-gateway streams trade events and depth updates to clients (per 01-architecture.md §"Services in platform/services/"). External market data is partially flowing too — the venue-adapter-binance scaffold landed in [PR#6] as a read-only Binance feed publishing venue.*.trade.* NATS subjects (milestone-1-status.md §Safeguards, slippage-controls row).
The dedicated market-data service is a Phase 2 deliverable per the M6 contract scope (CLAUDE.md "Milestones Summary" Phase 2 table): DOM visualisation, L2/L3 microstructure analytics, sentiment engine, news aggregation. Reference source for clone: QuantaTradeAI/market-data-relay (repo-bootstrap-plan.md §13).
Authoritative spec: CLAUDE.md "Milestones Summary" Phase 2 row 1; repo-bootstrap-plan.md §13; architecture.md where present.
8. Signal / AI research engine (M7)¶
Milestone: M7. Status: 🔴 — no code.
Per CLAUDE.md Milestones Summary Phase 2 row 2: signal engine, AI scanners, backtesting environment. Lives alongside or inside the strategy engine repo (§6 above). Phase 2 deliverable, not in M1–M5 critical path. See delivery-plan-review.md where the original delivery-plan PDF intent is captured.
9. Margin / derivatives / perps (M8)¶
Repo: QuantaTradeAI/platform/services/risk-service (scaffold exists). Milestone: M8. Status: 🟡 — service runs, end-to-end margin path not enforced.
Honest partial state: per 01-architecture.md §"Services in platform/services/", risk-service runs on port 3009 at ~1.5k LOC. Per 04-risk-controls.md (cross-link), this service is the derivatives-prep margin and liquidation engine, distinct from the pre-trade risk-checker that lives in order-router. The pre-trade risk-checker is what landed the slippage guard in [PR#4] (see milestone-1-status.md §Safeguards); the margin engine is what M8 will exercise.
The order-router's marginMode flag on order placement is the visible margin surface today: it is rejected for non-margin pairs (M1 platform is spot-only) and accepted but not enforced for margin-enabled pairs. There are no margin-enabled pairs in production. Position tracking is also partial — per milestone-1-status.md §Trading System, pms-service runs and is NATS-subscribed but the trading UI's Positions tab uses mock data; spot-only positions ≈ balances, so the gap doesn't matter until M8.
Authoritative spec: CLAUDE.md "Milestones Summary" Phase 2 row 3 ("Margin accounts, liquidation engine, perps"); 04-risk-controls.md and 05-services-reference.md for the existing risk-service surface.
10. Liquidity / market making (M9)¶
Repo: QuantaTradeAI/market-maker (planned, clone-from QuantaTradeAI/quantatrade-mm). Milestone: M9. Status: 🔴 — repo not bootstrapped; engine substrate exists.
The matching engine substrate already supports the MM flows Richard called out in his M1 amendment (milestone-acceptance-criteria.md §"Market maker support"): post-only orders (LIMIT_POST_ONLY in exchange-core2 OrderType), maker rebates via fee/FeeSchedule.java + FeeService.java, and quote APIs (gRPC PlaceOrder + CancelOrder + L2 orderbook). See 02-trading-system.md (cross-link) for fee tier mechanics and milestone-1-status.md §"Market maker support" for the confirmation.
The full MM engine (Java Spring Boot, spread management, liquidity-provisioning logic, external incentive accounting) is M9 scope. Bootstrap clone source per repo-bootstrap-plan.md §14.
Authoritative spec: CLAUDE.md "Milestones Summary" Phase 2 row 4; repo-bootstrap-plan.md §14; milestone-acceptance-criteria.md §M1 "Market maker support".
11. Portfolio / institutional risk (M10)¶
Milestone: M10. Status: 🔴 — no code, no detailed spec.
Per CLAUDE.md "Milestones Summary" Phase 2 row 5: portfolio optimization, risk analytics. No spec doc treats this in detail beyond the contract milestone description. Phase 2 final deliverable.
12. Cross-cutting: legal / regulatory open questions¶
These are the questions that cross every M5+ contract and most M4 service work. They are reproduced here (with line references) because they're the gating items for sign-off, and a planned-modules doc that doesn't surface them is misleading.
From staking-open-questions.md¶
| § | Question | Status | Impact |
|---|---|---|---|
| 1.1 | Price oracle source (Chainlink vs DEX TWAP vs custom) | Open | Blocks staking circuit-breaker contract |
| 1.2 | Revenue attester role design | Open | Blocks revenue router immutability claim |
| 2 | USDT/USDC → $QTRA conversion path (on-chain swap vs off-chain treasury buy) | Open | Blocks reward distribution mechanics |
| 3.1 | Warmup semantics (delays accrual vs delays counted stake) | Open | UX copy + contract semantics |
| 3.2 | Early-unlock penalty retroactive vs forward-only | Open | Contract gas + audit surface |
| 3.3 | Tier expiry behaviour (auto-roll vs drop to 1.00x vs require restake) | Open | Default-matters UX |
| 3.4 | Claim-stream + unstake interaction | Open | Edge cases in reward forfeit |
| 4 | Immutability posture per contract (token/router/staking) | Token closed; router + staking open | Determines audit budget + formal-verification scope |
| 5 | Stress tests at $0.30 and $1.00 token price | Open | Economic sustainability check |
| 6 | Jurisdictional reach + KYC gating | Open | May force ERC-1404 / whitelist contract redesign + securities counsel sign-off |
| 7 | Live APY refresh cadence and indexer source | Open | Drives chain-indexer scope (§5 above) |
From tokenomics-open-questions.md¶
| § | Question | Status | Impact |
|---|---|---|---|
| 1 | Authoritative tokenomics doc (v1 proposal vs system-spec FINAL PDF) | Blocker | Engineers must build against one set of numbers; conflicts exist on almost every economic parameter |
| 1.1 | Round price schedule (3–7x apart between docs) | Blocker | SaleManager round configuration |
| 1.2 | Total raised to date ($31.8M vs $7.883M — 4x delta) | Blocker | Whether Pre-Seed/Seed "Closed" rounds are mis-attested |
| 1.3 | Final allocation buckets; staking-rewards bucket implies inflation contrary to revenue-funded principle | Blocker (Seed amount partially resolved — 120M ✓) | Pick emission-based vs revenue-funded model |
| 1.4 | Team vesting 36mo vs 24mo linear | Blocker | Already in executed investor agreements — legally binding |
| 2 | Fee rebate tiers (six-tier model vs single $QTRA-holder discount) | Open | Matching-engine fee logic depends on this |
| 3 | Chain confirmed (Base?) | Open | Affects gas, bridges, listings |
| 4 | Buyback basis (10% of net profit vs per-stream percentages) | Open | Different on-chain flows |
| 5 | Current sale-round status + Merkle roots for closed rounds | Blocker | SaleManager deploy needs accurate initial state |
| 6 | Epoch reference (wall-clock vs relative-to-deploy) | Open | Cap-enforcement edge cases |
From milestone-acceptance-criteria.md (M1/M2 open questions)¶
| § | Question | Status | Impact |
|---|---|---|---|
| S-1 | Seed allocation 160M (Richard) vs 120M (system spec) | Resolved 2026-04-22 — 120M | Multiple client docs still carry 160M — needs cleanup |
| S-2 | Custody provider (BitGo confirmed) | Resolved 2026-04-19 | BitGo integration work begins on credentials arrival |
| S-3 | Solana integration scope | Open | Non-EVM SDK + SPL handling — confirm M2 or defer |
| S-4 | Fiat rails — direct vs banking partner | Open | Direct is out of scope for 10-week build |
| S-5 | Audit scope (token+sale+vesting / router / staking) | Open | Three independent audit engagements |
| S-6 | Pre-Seed/Seed Merkle import — by design | Open | Whether to remove on-chain Pre-Seed/Seed path in SaleManager |
What this means for M5 sign-off¶
staking-open-questions.md "Sign-off required before M5 kickoff" enumerates eight items, all currently Open. Items 1.1, 1.2, 4, and 6 are the hard blockers (oracle, attester, immutability, legal). Without written sign-off on those four, the M5 contract surface (StakingVault, RewardDistributor, CircuitBreaker, RevenueRouter, TreasuryBackstop, BuybackEngine per m5-token-utility-plan.md §"Smart Contract Architecture") cannot be frozen for audit. The remaining open items (1.3, 2, 3, 5, 7, 8) change behaviour but can be parameterised; the four blockers change architecture.
Repos that exist but contain placeholder code¶
Per repo-bootstrap-plan.md "Bootstrap Execution Order", these QuantaTradeAI/ repos exist on GitHub but mostly carry scaffolds — clone-from operations are partial or not yet run:
| Repo | Milestone | What's in it today |
|---|---|---|
contracts |
M2 / M5 | 12 contracts, 1,471 LOC, 115 tests (M2 surface) — see §1 above |
presale-app |
M3 | scaffold per components-index.md |
investor-dashboard |
M3 | scaffold |
custody-service |
M2 | scaffold; live event handler is in platform/services/order-router instead |
compliance-service |
M4 | scaffold; types only in @quantatrade/types |
chain-indexer |
M2 | not bootstrapped |
market-data |
M6 | not bootstrapped |
strategy-engine |
M4 | not bootstrapped |
market-maker |
M9 | not bootstrapped |
The platform monorepo (QuantaTradeAI/platform) is the only repo with substantial production code today; that surface is documented in reference docs 01–09.
Maintenance¶
When a planned module moves from spec to code:
1. Delete its section here (or move it down to a brief "now built — see [0X-name].md" pointer).
2. Add a new reference doc 0X-name.md and link it from 00-index.md.
3. Update components-index.md status flag.
4. Update the relevant milestone status doc (milestone-1-status.md, milestone-2-status.md, or the M3+ status doc when created).
When a new open question is identified:
- M2 / token / sale / vesting items go in tokenomics-open-questions.md.
- M5 / staking / router / buyback items go in staking-open-questions.md.
- M1 / M2 acceptance items go in milestone-acceptance-criteria.md "Open questions" section.
- This doc's §12 cross-cutting table picks them up on next refresh.