Milestone 1 — Hybrid Execution Engine — Status¶
✅ ACCEPTED — signed off 2026-05-29. Core ledger + matching + risk + admin gates accepted. External venue execution + SOR carried as a post-acceptance follow-up (see delivery plan).
Date: 2026-04-30
Spec: docs/milestone-acceptance-criteria.md#milestone-1 (Richard-HFT, 2026-04-19)
Each line item from Richard's checklist mapped to current state. Status legend: 🟢 done, 🟡 partial / unverified, 🔴 not implemented. Evidence column points to the exact file/URL/command that proves the claim.
UI / UX¶
| Item | Status | Evidence |
|---|---|---|
| Full platform UI/UX completed | 🟢 | https://trade.quanta.emoment.tech — sidebar IA per Richard's 2026-04-28 spec, TradingView chart, L2 order book, recent trades, watchlist, balance header, tabbed orders panel, login/auth gates. 26 Playwright tests green: QuantaTradeAI/trading-ui/tests/e2e/. |
Execution Engine¶
| Item | Status | Evidence |
|---|---|---|
| Internal central limit order book | 🟢 | exchange-core2 (LMAX disruptor) inside matching-engine Spring Boot service. Source: /home/ubuntu/qt/exchange-core/. Live GET /api/v1/markets/BTC-USDT/orderbook returns real bids/asks. |
| Internal order matching engine | 🟢 | Same. Order-pipeline e2e test proves POST /orders → api-gateway → NATS orders.submit → order-router → gRPC PlaceOrder → matching-engine → result back → 201 + persisted. |
| External venue routing via REST and WebSocket | 🔴 | order-router/src/ contains only matching-engine-client.ts. No Binance / Coinbase / Kraken adapters. Not implemented. |
| Smart order routing logic | 🔴 | No SOR module. Single internal-only route. Depends on external venue connectors above. |
Trading System¶
| Item | Status | Evidence |
|---|---|---|
| Order Management System (OMS) | 🟢 | Order table in Postgres + order-router service + api-gateway routes (/orders, /orders?status=open, /orders/history, DELETE /orders/:id). Lifecycle events forwarded over WS gateway (order.created/updated/cancelled/filled/rejected). |
| Portfolio Management System (PMS) | 🟡 | pms-service runs on :3008, healthcheck green, NATS subscriptions wired. UI Positions tab still uses mock data — service is reachable but not yet user-facing. Spot-only platform so positions ≈ balances; full position tracking matters from M8 (margin). |
| Double-entry ledger for balances, trades, treasury | 🟢 | ledger-service runs on :3007, subscribes to trades.executed and 4 other service-level subjects. accounts + ledger_entries tables populated end-to-end as of 2026-05-27: a custody.deposit.confirmed NATS event for user cmol48kdq0000iw6hyqa27f2k, 500 USDT, txHash 0xledgersync20260527c produced (a) matching-engine deposit result=SUCCESS, (b) accounts row available=500.000000000000000000, locked=0, © ledger_entries row transaction_id=deposit:0xledgersync20260527c, amount=500, balance=500, entry_type=deposit, reference_type=deposit, reference_id=0xledgersync20260527c. Replay of the same txHash did not double-credit. Wiring committed as fix/deposit-ledger-sync (bc6de6d9 on QuantaTradeAI/platform:main) alongside fix/logger-add-logerror-logtrade (aed137fd). |
Safeguards¶
| Item | Status | Evidence |
|---|---|---|
| Strategy kill-switches | 🔴 | No strategy engine in M1 (Python strategies are M4). Kill-switch surface exists at the gRPC AdminService.HaltMarket level (matching-engine), but no UI/API wired to invoke it. |
| Venue failover routing | 🔴 | Only one venue (internal). N/A until external venues land. Binance read-only market-data adapter landed (platform#6) — trading client + SOR are still required for failover. |
| Slippage controls | 🟡 | Pre-trade guard landed in order-router/risk-checker.ts (platform#4, 5a8a1ca): market orders require a recent reference price, accept an optional maxSlippageBps validated against a per-market ceiling, and apply a worst-case-projection notional floor. 8 new tests. Fill-time enforcement of the cap at the matching engine is a follow-up (engine work). |
| Manual override controls | 🟡 | Force-cancel button landed in admin-panel (admin-panel#2) — modal-gated, surfaces engine errors inline, 8 tests pass. Halt-market gap: AdminService.HaltMarket / PauseSymbol / ResumeSymbol RPCs do not exist in exchange-core's proto. Needs server-side proto + Java AdminServiceImpl change before a UI button is honest. |
Acceptance gates¶
| Gate | Status | Evidence |
|---|---|---|
| Orders can be placed, routed, executed, and reconciled | 🟢 | Place ✓, route ✓ (internal only), execute ✓ (resting), reconcile ✓ (deposit → accounts + ledger_entries round-trip verified 2026-05-27). |
| Internal and external liquidity execution verified | 🟡 | Internal ✓ (e2e test). External: read-only Binance market data flowing (platform#6); external execution still pending (signed Binance endpoints + SOR). |
| Ledger produces auditable trade and balance records | 🟢 | Deposit path verified end-to-end 2026-05-27 with idempotent replay; settled-trade path will exercise the same ledger_entries schema on the next crossing fill. |
Market maker support (Richard's M1 amendment)¶
| Item | Status | Evidence |
|---|---|---|
| Post-only orders | 🟢 | exchange-core2 OrderType includes LIMIT_POST_ONLY. |
| Maker rebates | 🟢 | fee/FeeSchedule.java + FeeService.java implement maker/taker tiers. Volume tracker already running. |
| Quote APIs | 🟢 | Order placement + cancel + L2 orderbook via gRPC; sufficient substrate for an MM bot. |
Honest summary¶
Solid & demoable today (9/16 items green): the internal happy path — UI, CLOB, matching engine, OMS, fee tiers, MM substrate, e2e CI, ledger.
Service exists but unproven (4/16 yellow): PMS UI, external-venue acceptance gate (read-only data flowing; trading client pending), manual-override (force-cancel landed; halt-market needs server-side proto change first), slippage controls (pre-trade guard landed; engine-side enforcement pending).
Not implemented (4/16 red): external venue execution (signed Binance endpoints), smart order routing, strategy kill-switches, venue failover.
The 4 reds still cluster on external venue connectivity — the Binance market-data scaffold is in, but order placement and a router that can split fills are the meaningful remaining work. Realistically a week of focused engineering.
Two paths to M1 sign-off¶
Path A — File for partial M1 acceptance now¶
Submit this status doc verbatim to Richard. Propose: - Accept M1 as ~70% complete; schedule the 5 reds against a defined catch-up window. - Move to M2 immediately on smart contracts so we don't lose the week-2 cadence.
Pro: maintains delivery velocity; keeps the weekly drumbeat. Con: Richard's format is gate-based ("orders can be placed, routed, executed, and reconciled" — all must pass), so partial acceptance is a negotiation, not a default.
Path B — Close the 5 gaps before submitting¶
Estimated 4–6 days of focused work:
- 3–4 days: Binance Spot REST + WS adapter + minimal SOR (single venue with internal fallback)
- 1 day: slippage guard in risk-service + market-order test that exercises ledger writes — done (5a8a1ca on fix/slippage-guard)
- 1 day: kill-switch wired through admin panel + e2e test
- 0.5 day: re-run + amend this status doc to all-green
Pro: clean acceptance, no negotiation. Con: pushes M2 start by a week — risks compounding into the contract timeline.
Resolved 2026-05-27: balance-sync gap closed¶
The 2026-04-30 audit flagged that matching-engine UserRegistry (in-memory) and Postgres accounts were not kept in sync. Fresh users couldn't be funded through the canonical path; only directly-seeded admin SQL worked. That gap is closed.
Wiring: order-router's custody.deposit.confirmed NATS handler now publishes a ledger.credit RPC after the matching-engine deposit succeeds (services/order-router/src/main.ts). Uses txHash as idempotency key; ledger-service's existing transactionId guard makes duplicate NATS deliveries safe. Ledger failure is logged and alertable but does not roll back the matching-engine deposit (the engine is the runtime source of truth; the ledger is the auditable mirror).
Latent bug surfaced during verification: ContextLogger did not implement logError / logTrade despite 30+ call sites. Every catch block and trade-settle log was silently broken. Fixed in packages/logger/src/index.ts (PR #2, aed137fd).
Both PRs merged to QuantaTradeAI/platform:main (bc6de6d9 + aed137fd). EC2 was rebuilt + verified before commit; once a clean rebuild from main happens, source will be fully in sync with upstream.
Verification log (ssh ubuntu@34.199.105.99, 2026-05-27):
publish custody.deposit.confirmed { txHash:0xledgersync20260527c, userId:cmol48kdq..., asset:USDT, amount:500 }
→ matching-engine: Deposit for user 1013: currency=103, amount=500000000, result=SUCCESS
→ order-router: "Ledger credited for deposit", newBalance:"500"
→ postgres accounts: available=500.000000000000000000, locked=0
→ postgres ledger_entries: amount=500, balance=500, entry_type=deposit
replay same txHash → accounts unchanged, ledger_entries count = 1 (idempotent)
Remaining yellows¶
| Item | What's needed |
|---|---|
| PMS UI | Wire the existing pms-service :3008 data into the Positions tab (current UI uses mock data). Spot-only platform so positions ≈ balances; full coverage matters more from M8 (margin). |
| External liquidity gate | Stays yellow until at least one external venue adapter ships — see Path B below for the Binance Spot path. |
| Manual override | AdminService.HaltMarket / force-cancel gRPC surface exists; needs admin-panel buttons + an e2e test exercising both. Half a day. |
Two paths to M1 sign-off (updated)¶
Path A — File for partial M1 acceptance now¶
Submit this status doc to Richard with the now-9-green-plus-the-resolved-ledger-gate count. The two remaining acceptance gates are external liquidity (red until adapter ships) and PMS UI (cosmetic vs. M8 scope). Negotiate one of: - Pro-rata payment for 9/16 + 2 gates green - Or accept M1 contingent on a defined catch-up window for the 5 reds
Path B — Close the remaining reds before submitting¶
~3–5 days:
- 3–4 days: Binance Spot REST + WS adapter (read-only) — done (platform#6, stacked on #4)
- 2–3 days: Binance signed-endpoint trading client + minimal SOR
- 1 day: slippage guard in risk-service + market-order test exercising ledger writes — done (platform#4)
- 0.5 day: force-cancel admin button + e2e — done (admin-panel#2)
- 0.5 day: exchange-core proto + Java for HaltSymbol/ResumeSymbol, then mirror in admin-panel
- 0.5 day: rerun + amend this doc
External-venue execution and admin halt-market are the only material remaining items.
Generated 2026-04-30; updated 2026-05-27 (ledger-sync) and 2026-05-28 (slippage guard PR#4, Binance read-only adapter PR#6, force-cancel admin button admin-panel#2). Re-run before submission.