Kalshi Prediction Market Analytics
A market-data pipeline that separates maker and taker economics, builds analytical marts, and connects calibration-focused model research to an API and dashboard.
What it is
The interface is for examining market behavior: how prices compare with outcomes, how maker and taker economics differ, and where category or time effects appear. The portfolio story is the analytical system and its contracts.
A reviewer can begin with one trade and follow it through transformation, aggregation, model inputs, and the dashboard rather than starting with an isolated model score.
The loop it has to make believable
- 01
Trace a resolved trade into maker and taker positions, then inspect how those positions contribute to analytical summaries.
- 02
Compare modeled probabilities with market-price baselines using calibration-oriented evaluation and a dashboard review path.
How it’s built
The dbt position model decomposes a resolved trade into two sides with explicit costs and payouts. A zero-sum test checks aggregate excess-return consistency. These contracts make the economic interpretation reviewable in SQL.
The trainer includes market-price and other baselines, time-series cross-validation, and MLflow logging. The architecture separates analytical storage, streaming features, model inference, and gateway policy instead of combining them in one endpoint.
Architecture
- Batch model
- Parquet inputs become DuckDB/dbt staging tables, position records, and analytical marts
- Accounting
- Resolved trades split into opposing positions with cost basis, payout, profit, and excess return
- Model research
- LightGBM training, time-series cross-validation, market-price baselines, and probability-quality metrics
- Serving
- FastAPI owns inference; Spring Boot supplies gateway concerns including keys, caching, and retries
- Exploration
- Streaming feature components feed Redis; Streamlit exposes calibration and category analysis
What has to hold up
- Test the accounting relationship between opposing positions rather than relying only on visually plausible charts.
- Keep timestamp splits, feature construction, inference behavior, and gateway behavior separately inspectable.
Evidence still to capture
The inspected reports directory contains only a placeholder, and MEASUREMENTS.md mainly describes how to collect results. No latency, throughput, model lift, trading return, or production reliability number is claimed here.
The code and configuration establish a local implementation to review. Fresh, saved end-to-end results are needed before asserting that the full stack runs together or that a model improves on the market baseline.
Proof
VerifyRepository, checks, stack, status
- 01
Start with the local README's verification paths and inspect int_positions.sql alongside assert_zero_sum.sql.
- 02
Review the training configuration, time-series splits, feature construction, and baseline evaluation.
- 03
Run the relevant dbt, ML, API, dashboard, and streaming checks using the documented environment.
- 04
Save the outputs requested by MEASUREMENTS.md before making model-lift or runtime claims.
- Role
- Trade modeling, analytical transformations, evaluation path, and service integration
- Scope
- Local batch/streaming analytics, probability-model research, serving, and dashboard
- Proof
- transform/models/intermediate/int_positions.sql; transform/tests/assert_zero_sum.sql; ml/src/training/trainer.py; MEASUREMENTS.md
- Stack
- Python, DuckDB, dbt, LightGBM, MLflow, FastAPI, Spring Boot, Kafka, Redis, Streamlit
- Modeling
- Maker / taker positions
- Contracts
- Zero-sum accounting check
- Evaluation
- Time-aware calibration
- Measurements
- Capture still required