Ordered in build sequence. Items in the same phase can run in parallel.
| ID | Repo | Phase | Title |
|---|---|---|---|
| S1 | services | 0 | Go module + shared platform packages (observability, postgres, nats, grpc) |
| S2 | services | 0 | Docker Compose stack (PG, NATS, Prometheus, Grafana, Loki, Tempo) |
| S2.5 | services | 0 | Scaffold all 4 Go services + proto generation + migration tooling (Resolution Worker deferred) |
| C1 | contracts | 0 | Fork Polymarket contracts + deploy to Polygon mainnet + export ABIs |
| T1 | services | 1 | Trading domain types (Order, Trade, Book, Balance) |
| P1 | services | 1 | Platform domain types (Market, Event, User, Position) |
| T3a | services | 2 | Wallet auth + API keys + JWT sessions. Platform Service issues JWTs from SIWE EOA signatures (now) and Magic Labs smart-wallet signatures (T3b). Trading Service derives API keys + HMAC secrets from the same wallet-signature primitive. Both wallet types coexist permanently. |
| SEC0 | services | 2 | Rate limiting middleware (per-IP, per-user, per-endpoint) (#49) — foundational HTTP middleware applied across both services. Must land before P2 ships user-facing endpoints. Consolidates the previously-separate SEC2 ticket (#42, closed in favor of #49). |
| P2 | services | 2 | Market Admin service (backend CRUD + Pending market creation. On-chain confirmation, resolution, and voiding handled by Platform subscriber reacting to Indexer NATS events. Frontend signs on-chain txns via admin wallet.) |
| P2.4.1 | services | 2 | Add markets to an existing event (POST /admin/events/{id}/{binary |
| T2 | services | 2 | CLOB matching engine (in-memory order book, price-time priority) |
| W2 | services | 2 | Indexer — pure event pipeline (all on-chain event monitoring → publish to NATS). No DB writes, no business logic. Platform Service subscribes to Indexer events for market confirmation, resolution, voiding. |
| T4 | services | 2 | CLOB REST API (order CRUD, book queries, Polymarket compatible) |
| T5 | services | 3 | WebSocket server (NATS to client fan-out, public + private channels) |
| P3 | services | 3 | Market API (public read: events, markets, categories, prices) |
| P4 | services | 3 | Data API (positions, balance, trades, profile) |
| P5 | services | 3 | Affiliate/referral system (tracking, earnings, claim) |
| SEC1 | services | 3 | CORS middleware + security headers + CSRF origin checking (#41) — must land before frontend (F2) makes cross-origin API calls. Blocked by T3a.1. |
| F1 | web | 3 | Next.js scaffold + shared packages, Turbo, Tailwind, wagmi |
| F4 | web | 3 | Admin app (market creation, resolution, users, config, analytics) |
| F2 | web | 3 | Wallet connect + SIWE auth flow (browser wallet users only; email flow moved to T3b) |
| F3 | web | 3 | Market pages (homepage, market detail, event page, charts, order book) |
| F5 | web | 3 | Trading UI (order placement, portfolio, P&L, WebSocket, deposits, withdrawals, referrals) — first working app milestone |
| W1 | services | 4 | Settlement worker (consume matches, submit matchOrders on-chain) |
| W3 | services | 4 | Relayer — lazy Safe/Proxy deployment on first deposit (batch Safe deploy + USDC approve + ERC1155 approve), redemptions, withdrawals. T3a just records the deterministic Safe address at signup; actual on-chain deploy happens here. |
| B1 | bot | 5 | Fork poly-market-maker, configure for our API |
| B2 | bot | 5 | Multi-outcome / neg-risk extension |
| T3b | services + web | 6 | Email auth — Magic Labs (magic.link) smart wallet + referral attribution + frontend UI. Adds Magic Labs alongside the browser-wallet flow; both wallet types remain first-class options. (after F5, pre-launch) |
| T3c | services + web | 6 | 2FA TOTP + frontend UI (after F5, before withdrawals go live) |
| — |
graph TD
S1["S1: Shared platform packages"] --> S2["S2: Docker Compose stack"]
S1 --> S2.5["S2.5: Scaffold all 4 services"]
S2 --> S2.5
C1["C1: Fork contracts + deploy Polygon mainnet"]
S1 and C1 have no dependencies — they can start immediately and in parallel.
graph TD
S2.5["S2.5: Scaffolding"] --> T1["T1: Trading domain types"]
S2.5 --> P1["P1: Platform domain types"]
T1 and P1 can be done in parallel — different services, no dependency.
Goal: admin creates a market, user authenticates, places an order, sees it on the book.
graph TD
P1["P1: Platform domain"] --> P2["P2: Market Admin"]
T1["T1: Trading domain"] --> T3a["T3a: Wallet auth + API keys"]
T1 --> T2["T2: CLOB engine"]
T3a --> P2
C1["C1: Contracts"] --> W2["W2: Indexer"]
W2 -.->|"confirms markets via NATS"| P2
P2 -.->|"markets must exist"| T2
T2 --> T4["T4: CLOB REST API"]
T3a --> T4
P2 comes before T2 in the build order — the matching engine needs markets to operate on. T3a (wallet auth) feeds into both P2 (admin auth) and T4. W2 (Indexer) is Phase 2 — publishes deposit, settlement, and unexpected movement events to NATS. Market lifecycle transitions (creation, resolution, voiding) use direct ethclient verification in the Platform Service at admin request time — no indexer dependency for market admin. T3b (email auth) and T3c (2FA) are deferred to the end of the build — see Phase 6.
Milestone: after T4, the system is testable end-to-end (off-chain). Admin creates market → user authenticates → places order → order enters book.
Frontend can start building against live APIs as they come online.
graph TD
F1["F1: Next.js scaffold"] --> F2["F2: Wallet + auth flow"]
F1 --> F4["F4: Admin app"]
P2["P2: Market Admin API"] -.-> F4
T3a["T3a: Wallet auth"] -.-> F2
P2 --> P3["P3: Market API"]
F2 --> F3["F3: Market pages"]
P3 -.-> F3
T4["T4: CLOB REST API"] --> T5["T5: WebSocket"]
P1["P1: Platform domain"] --> P4["P4: Data API"]
P4 --> P5["P5: Affiliate"]
F3 --> F5["F5: Trading UI"]
T4 -.-> F5
T5 -.-> F5
P4 -.-> F5
Dashed lines = API must exist. F1 can start as soon as Phase 2 APIs are defined. F4 (admin) and F2/F3 (main app) are independent.