● Production · v6.5.8
Backend deep-dive
The architecture that runs every signal. Public on purpose — opacity in a trading system is a red flag, not a feature.
System topology
One DigitalOcean droplet runs 6 PM2-managed processes. Each surface has its own loop, its own env file, its own bankroll state. The dashboard is a separate FastAPI service on the same box.
DigitalOcean droplet (Ubuntu)
+-----------------------------------------------------------------+
| PM2 process supervisor |
| |
| st-bot-loop --> Kalshi ST (scan->predict->execute) |
| st-lt-loop --> Kalshi LT (scan->predict->execute) |
| st-forex-loop --> OANDA FX (scan->predict->execute) |
| st-stocks-loop --> IBKR STK (scan->predict->execute) |
| st-forex-resolver --> Closes FX positions when SL/TP hit |
| st-dashboard --> FastAPI . subscriber feed . UI |
| |
| Surface env isolation: st.env lt.env fx.env stk.env |
| Shared: shared.env (API keys only) |
+-----------------------------------------------------------------+
|
| publishes to
v
+-----------------------------------------------------------------+
| /api/signals/feed (long-poll, cursor-paginated) |
| /api/signals/{id}/ack <--+ |
| /api/signals/{id}/executed <--+ subscriber callbacks |
| /api/signals/{id}/resolved <--+ |
+-----------------------------------------------------------------+
|
v
N subscriber clients
(your phone, laptop, or VPS)
The four surfaces
Kalshi ST live
Short-term prediction markets. Weather (NWS-verified), crypto daily settlements, sports parlays. Cash-settled at market close.
Min edge8%
Min confidence55%
Max positions8 concurrent
Hold timehours → days
Kalshi LT live
Long-term political and macro events. Fed decisions, election cycles, monetary policy. Lower velocity, higher conviction.
Min edge4%
Min confidence55%
Max positions30 concurrent
Hold timeweeks → months
OANDA Forex live
8 major currency pairs. ATR-based bracket orders (TP/SL set at entry). Concentration-capped per correlation cluster (USD / EUR / safe-haven / commodity).
Min edge15%
Min confidence50%
Max positions6 concurrent
Cluster cap3 per group
IBKR Equities funding
US equities via Interactive Brokers (ibeam gateway). Bracket orders. Sector-capped (GICS, 11 sectors).
Min edge8%
Min confidence55%
Max positions4 concurrent
Sector cap2 per GICS
Risk gate chain (Kalshi ST shown)
Every candidate signal traverses a chain of gates before reaching the broker. Failure at any gate logs the rejection reason and skips. Most candidates are skipped. That's the design — the gates are tuned for selectivity, not volume.
1
STOP file checkManual kill switch in the surface's working directory. Operator hits a UI button → file appears → loop reads it on next tick and halts.
2
DeduplicationIf a position on the same market in the same direction is already open (or already dry-filled this session), skip. Prevents loop-tick re-firing.
3
Per-market position capNo more than N contracts on a single Kalshi market regardless of how many signals fire for it.
4
Direction filterAudit-validated; some surfaces have one-sided edges (e.g. ST currently favors NO).
5
Suspended categoriesCategories with degraded recent performance get auto-suspended by the audit tooling.
6
Risk validationKelly sizing, exposure limits, daily loss cap (10% bankroll / 24h), drawdown cap.
7
Slippage checkReject if market has moved more than 3% from the signal price during the predict cycle.
8
Minimum edgeHard floor: 8% on Kalshi, 4% on LT, 15% on FX, 8% on STK. Tuned per surface from historical calibration.
9
Minimum confidenceHard floor on model confidence. Low-confidence predictions never execute, regardless of edge.
10
API cost capDaily limit on Claude/Anthropic spend ($50/day). Stops the bot before research costs eat the day's gains.
Signal pipeline (weather example)
SCAN --> Kalshi events API . filter to KXHIGH{NYC,CHI,MIA,...}
Apply: vol >= 200, spread <= 5c, 4h <= hours_to_expiry <= 48h
Output: ~80 candidate markets
|
v
RESEARCH --> NOAA NWS API: gridpoint forecast + Area Forecast Discussion
Compute baseline probability via normal CDF
(sigma scaled by horizon: 1.5F at 12h --> 4F at 72h)
Output: forecast_high + baseline_p + AFD excerpt
|
v
PREDICT --> Claude Sonnet 4.6
Input: market context + NWS forecast + AFD text + baseline
Output: refined p_model + confidence + reasoning
|
v
DECIDE --> edge = p_model - market_price
If edge >= 8% AND confidence >= 55%:
actionable = True --> fall through gate chain
Else:
actionable = False --> shadow log only (for calibration)
|
v
EXECUTE --> Pass risk gates (1-10 above)
Place Kalshi limit order (operator-side) OR
Publish signal to feed (subscriber-side)
Write trade record with: edge, confidence, eta_hours, atr,
resolution_source tag for forward-only audit clarity
|
v
PUBLISH --> Signal feed entry:
{ signal_id, surface, market_id, direction, edge,
confidence, p_model, kelly_size_pct, ttl_sec: 600,
expires_at, metadata: {city, bracket, forecast, ...} }
Cursor-paginated, long-poll, 401 on revoked token
|
v
RESOLVE --> 4h after market close (weather): query NWS station observations
For Kalshi resolution: poll Kalshi /markets/{id}/result
Compute outcome + PnL (Kalshi cash-settlement math)
Write resolved=true, resolution_source="nws_observation"
Subscriber feed architecture
The hardest part of multi-tenant signal delivery is making it both fast and idempotent. T BOT uses cursor-paginated long-polling against an append-only JSONL log. Each subscriber tracks the last signal_id they processed; the server replays everything after that cursor (modulo TTL).
Operator side Subscriber side (your client)
--------------------- ------------------------------
signal_publisher.py feed.py
| |
| appends one JSONL row | every 30s:
v with TTL=600s | GET /api/signals/feed
signal_feed.jsonl | ?since=<last_cursor>
| | &token=<subscriber_token>
| |
| served by v
v router.py
/api/signals/feed |
(cursor-paginated, drops | for each new signal:
expired signals server-side) | 1. dedup check (state.json)
| 2. surface enabled? sized?
| 3. POST ack (accepted/filtered)
|
v
adapters/{kalshi,oanda,ibkr}.py
|
| place_order(signal, size_usd)
| --> returns fill_price + order_id
|
| POST executed (fill, size, broker_id)
| POST resolved (outcome, pnl) on close
|
v
subscriber_callbacks.jsonl <---------- append-only audit trail (operator)
|
| aggregated by
v
/api/subscribers/aggregate --> win rate, total PnL, per-surface breakdown
(no per-name attribution -- operator sees pool only)
Audit & calibration
Every surface has its own audit tool that compares model predictions against realized outcomes. The audit can scope to a date range (--since 2026-05-01) so post-cutover metrics aren't polluted by historical dry-run noise.
📐
Calibration audit
Bins predictions by confidence band, checks if 70%-confident predictions actually resolved 70% of the time. Detects systematic over/under-confidence.
⏱
ETA calibration
Compares predicted time-to-resolution (computed from ATR × distance-to-stop) against actual resolved_at - timestamp. Detects volatility-implied ETAs that are systematically too short or too long.
🧾
Audit-frequency reminder
Dashboard surfaces an amber chip when any surface hasn't been audited in 7+ days. Operator click → opens audit drawer for that surface.