PredictX CLOB Live Readiness Audit

Status: Not live-ready yet.

Date: 2026-06-13 Scope: Current PredictX /clob-demo route, current public CLOB component, and archived Kuest/PredictX CLOB reference files.

Executive verdict

The current PredictX CLOB page is a visual architecture preview. It is not a live CLOB and must not be presented as one.

It is acceptable as an investor-facing product preview. It is not acceptable for real-money trading, live order routing, production matching, deposits, withdrawals, wallet signing, contract settlement, or user balances.

Current live-app state

Current live route:

• src/app/[locale]/(platform)/clob-demo/page.tsx
• src/app/[locale]/(platform)/_predictx/ClobDemo.tsx

Current behaviour:

• Static bid and ask rows.
• Static activity rows.
• Static ticket preview.
• Static review checklist.
• No backend order API used by the page.
• No database writes.
• No matching service.
• No wallet/signature flow.
• No live balance or reservation system.
• No settlement service.

Live blockers

1. Legal and compliance blocker

Before any real-money or real-value market activity, PredictX needs formal legal review for jurisdiction, product classification, KYC/AML, age gating, user eligibility, market rules, responsible-gambling or financial-risk controls, terms, privacy, and operational obligations.

No code should enable live value transfer before this is complete.

2. Product blocker

The CLOB page currently says and behaves like a visual preview. A real product needs:

• User accounts with verified identity flow.
• Eligibility checks.
• Market rule pages.
• Market lifecycle states.
• Market close and resolution rules.
• Audit trails for every user-visible change.
• Admin tooling for market review, suspension, correction, and incident handling.

3. Balance and risk blocker

The archive contains signed-order and settlement ideas, but the current live app does not have a production balance engine.

A real CLOB needs:

• Ledger-first accounting.
• Available balance vs reserved balance.
• Atomic reservation at order placement.
• Atomic release on cancel/expiry.
• Exposure limits.
• Per-market and per-user caps.
• Negative-balance prevention.
• Integer-unit accounting only.
• Reconciliation jobs.

4. Matching-engine blocker

The archived matching engine is useful reference code, but it is not production-grade yet.

Live matching needs:

• Transactional locking.
• Idempotent match jobs.
• Replay protection.
• Deterministic ordering.
• Cancel/replace semantics.
• Partial-fill correctness tests.
• Integer-only math.
• Concurrency tests.
• Full event journal.

5. Security blocker

Live CLOB requires an external security review before production.

Required reviews:

• Application security review.
• Auth/session review.
• API abuse review.
• Rate-limit review.
• Database RLS review.
• Secrets management review.
• Infrastructure and deployment review.
• Smart-contract audit if any on-chain layer is enabled.

6. Operations blocker

A live market product needs operations before launch:

• Incident response runbook.
• Admin permissions model.
• Manual market halt controls.
• User support workflow.
• Monitoring and alerting.
• Error budgets.
• Uptime targets.
• Data backups and restoration tests.
• Fraud/abuse review workflow.

Production architecture required before live

Recommended architecture path:

1. Keep current public CLOB page as architecture preview.
2. Build an internal paper-trading CLOB first.
3. Add database-backed order submission in test mode only.
4. Add integer-unit matching engine with transaction locks.
5. Add reserve/release balance ledger using demo credits only.
6. Add admin market controls and audit logs.
7. Add automated test suite.
8. Run staging load tests.
9. Conduct legal/compliance review.
10. Conduct external security review.
11. Only after sign-off, plan a controlled private beta.

Recommended next implementation phase

Phase 1: Paper CLOB, no real money.

Build:

• market_orders table.
• market_trades table.
• ledger_entries table.
• user_demo_balances table.