Event-Market Trading Platform — SportsQuantX

Overview

What it does

Kalshi is a CFTC-regulated event market where contracts resolve to YES or NO based on real-world events. Sports markets — game outcomes, player props, point spread brackets — have well-defined settlement conditions and predictable market structure. This makes them tractable for automation.

The platform scans active Kalshi markets, evaluates current contract prices against model probabilities, identifies positive expected value positions, and places orders automatically. Stop-loss floors and circuit breakers prevent runaway drawdown. All positions are logged and the system can be monitored remotely without interrupting execution.

This is not a simulation. It trades real capital through the Kalshi REST API on a schedule keyed to game schedules and market open windows.

NBAPrimary market

NCAABSecondary market

VPSLinux deployment

systemdProcess management

Execution Flow

How it works

01

Market Scan

Pulls active markets from the Kalshi API filtered by sport and time horizon. Filters out markets with insufficient liquidity or spread too wide to trade profitably. Caches market metadata to reduce API calls during the trading window.

02

Probability Evaluation

Each market price (expressed as cents per contract, where YES resolves to $1) represents the market's implied probability. The platform computes a model probability for each contract and compares it to the market price. Positive EV exists when model probability exceeds the ask price plus fees.

03

Order Placement

Qualifying opportunities are sized with a fractional Kelly criterion (a conservative fraction of full Kelly to limit variance). Orders are submitted via the Kalshi REST API. Limit orders are preferred over market orders to avoid crossing the spread on thin markets.

04

Position Monitoring

Open positions are checked against stop-loss floors based on current market price relative to entry. If a position moves significantly against the model, the platform closes it to limit exposure. Settlement is automatic on Kalshi — resolved contracts credit the account without intervention.

Deployment

Production infrastructure

Deployed on a Linux VPS. The platform runs as a systemd service under a dedicated non-root service user, automatically restarting on crash and starting on boot. The dashboard and API server run as companion services under the same unit file group.

Primary service

trading-bot

systemd unit. Auto-restart on failure, starts on boot. Logs to journald, queryable via journalctl.

Dashboard

operator-dashboard

Lightweight Flask API serving position state, P&L history, and system health metrics. Reachable over an authenticated tunnel for remote monitoring.

Monitoring

journalctl + alerts

Structured JSON logs for easy filtering. Critical errors trigger a notification to a private operations channel.

Backup strategy

Nightly SQLite dump

Position database and trade history exported nightly and synced off-box. Point-in-time recovery for the full trade history is possible from any export.

# /etc/systemd/system/trading-bot.service
[Unit]
Description=Event-Market Trading Bot
After=network.target

[Service]
Type=simple
User=trader
WorkingDirectory=/opt/trading-bot
ExecStart=/opt/trading-bot/.venv/bin/python main.py
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Risk Management

Capital protection

Trading real capital requires explicit, tested risk controls. The platform has three independent protection layers. Any one of them can halt trading without requiring the others.

Control	Mechanism	Behaviour on trigger
Position limit	Maximum capital allocated per market. Hard limit enforced before any order submission, not after.	Order rejected. Logged. Platform continues scanning other markets.
Stop-loss floor	If a position's mark-to-market value falls below a configurable percentage of entry cost, it is closed immediately.	Market sell order placed. Position removed from active tracking.
Daily circuit breaker	If daily realised P&L crosses a configured negative threshold, all new order placement is halted for the remainder of the session.	New orders blocked. Open positions held to settlement. Operator notified.
API error guard	Consecutive API errors beyond threshold (rate limiting, 5xx responses) pause order placement and escalate to notification.	Exponential backoff. After max retries, platform enters safe mode and waits for manual restart.

Stack

Technology

Python 3.11 Kalshi REST API PostgreSQL Linux (Ubuntu) systemd FastAPI httpx pytest