What needed solving.
Related contracts can appear to offer a guaranteed payout, but titles alone do not establish identical settlement rules; fees, book depth, partial fills, and broken legs can erase the apparent edge. The desk requires human-approved outcome relationships and models full package cost before execution.
- 01Approved outcome relationships
- 02Cost + depth + execution checks
- 03Hedged package or halt
Simplified from the implementation and project notes.
How it fits together.
Approved relationship data enumerates exhaustive mutually exclusive outcome states and which YES legs pay in each state. The engine enumerates 2–3 leg YES/NO combinations whose payoff is at least one dollar in every state, walks order books leg by leg, adds venue fees and execution allowance, then applies entry price, profit, depth, and risk gates. The executor requotes, enters the thinnest leg first, uses fill-or-kill and limited completion attempts, unwinds unresolved exposure, and halts.
Risk controls include paper-by-default behavior, size and capital caps, minimum venue cash, exposure limits, a loss stop, and halts on broken hedges, unknown order state, fee mismatch, or stale quotes. Venue integrations are isolated behind adapters. A server/dashboard and event stream expose system state.
The separate replay tool is offline-only and cannot submit orders. It uses receipt-time ordering, preregistered policy/eligibility files, latency and queue assumptions, explicit fee metadata, sequence-gap handling, candidate denominators, and censored unknown execution risk. The replay labels its results as hypothetical and unpriced; public L2/trades cannot prove routing priority or counterfactual fills.
Inside the software.
Prediction-market research and execution tooling: human-approved settlement relationships, package cost and depth checks, and fail-closed order handling. Offline replays and research studies retain their assumptions; modeled returns are not verified fills or evidence of a profitable strategy.
Market pulse dashboard
Monitor venue connectivity, market data and desk state through a local dashboard and event stream.
Node/TypeScript service exposes status and server-sent events alongside venue adapters; the portfolio image intentionally shows exchange-offline initialization state.
Implemented; live data depends on venue connectivity and credentials.
Implementation references
trading-desk/README.mdtrading-desk/srctrading-desk/config/desk.json
Explicit settlement relationship model
Require approved, exhaustive, mutually exclusive outcome states before treating related contracts as a hedged package.
Relationship config enumerates settlement states and paying YES legs; validation checks coverage and supports two- or three-leg combinations.
Implemented; relationships require human review and approval.
Implementation references
trading-desk/config/relationships.jsontrading-desk/README.mdtrading-desk/src
Package cost and depth scanner
Enumerate combinations that cover every approved outcome, walk order books, include fees and execution allowance, then apply price, profit, depth and risk gates.
Rules engine calculates worst-state payout and full package cost from available levels, with venue fee assumptions and configured limits.
Implemented; market inputs and fee assumptions can change.
Implementation references
trading-desk/srctrading-desk/src/risk.tstrading-desk/config/desk.jsontrading-desk/README.md
Sequential hedge execution and fail-closed risk
Requote and execute the thinnest leg first with limited completion attempts; unwind unresolved exposure and halt on uncertain state.
Paper mode is default; caps cover size, capital, venue cash, exposure and loss. Broken hedges, unknown order state, fee mismatch and stale quotes stop execution.
Implemented; live execution requires deliberate configuration/authentication and carries execution risk.
Implementation references
trading-desk/src/executor.tstrading-desk/src/risk.tstrading-desk/config/desk.jsontrading-desk/README.md
Isolated Kalshi and Polymarket US adapters
Keep venue-specific market data, fee and order operations behind adapter boundaries.
Adapters normalize venue operations for scanner and executor; fee checks halt when realized fees exceed modeled assumptions.
Implemented; API availability and account configuration are external dependencies.
Implementation references
trading-desk/srctrading-desk/README.mdtrading-desk/config/desk.json
Offline execution replay
Replay a recorder cohort in receipt-time order under preregistered eligibility, latency and queue assumptions, with unresolved execution risk censored.
Standalone research replay cannot submit orders; writes candidate and order lifecycle evidence with explicit fees and sequence-gap handling.
Implemented research tool; outputs are hypothetical and cannot establish routing priority, counterfactual fills or profitability.
Implementation references
trading-desk/research/REPLAY.mdtrading-desk/researchtrading-desk/README.md
Registered market research studies
Maintain separate reproducible research modules for market structure, crypto, sports, books and trade-tape questions, with preregistration, hashes, tests and review handoffs.
Research subprojects hold frozen/registered configs, data capture and audit scripts, statistical outputs, amendments and explicit evidence classifications; each study has its own assumptions and data window.
Implemented research artifacts. Each report records its sample, window, and uncertainty. These studies do not establish general profitability.
Implementation references
trading-desk/research/REPLAY.mdtrading-desk/research/run_registered_batch.pytrading-desk/research/sports_push_live_v4/REGISTERED.mdtrading-desk/research/crypto_economics_v2/README.mdtrading-desk/research/book_v1/README.md
Building and checking it.
Operators inspect contract rules and approve a relationship, run read-only scans, then authenticate and use paper mode unless live behavior is explicitly configured and invoked. Before approval, each leg's settlement source, rounding, release, outcome coverage, and resolution timing are checked. The sequential executor halts on uncertain state rather than continuing with an incomplete hedge.
Research replay consumes one recorder cohort in receipt order under predeclared policy and eligibility assumptions, writing per-candidate/order lifecycle evidence and censoring unresolved positions. Its purpose is diagnostic evaluation, not a backtest claim of profitability.
No profitability or realized execution result is asserted. Replay fills use explicit queue, latency, and fee assumptions; they cannot reconstruct routing priority, market impact, or settlement. A complete hedge on paper can still fail during execution.
Source notes
Based on repository code and project records reviewed on October 30, 2026. Historical checks are described as recorded, not rerun for this article. Screenshots, renders, and mockups are labeled individually.
trading-desk/README.mdtrading-desk/config/desk.jsontrading-desk/config/relationships.jsontrading-desk/src/executor.tstrading-desk/src/risk.tstrading-desk/research/REPLAY.md