Overview
Why this project exists
This page condenses the Polymarket work into one readable arc without flattening the technical reality of the repo behind it.
What started as curiosity about prediction markets turned into a stack of systems: data collection, feature engineering, backtest realism, live execution, HFT recording, model evaluation, and operational safeguards.
What makes it portfolio-worthy is not a single trading result. It is the progression itself: each phase exposed a stronger bottleneck, and the repo shows the engineering response to that bottleneck in code, reports, and deployment-oriented tooling.
Phase 01
Long-horizon prediction
The first phase tried to predict binary market outcomes, but the real work quickly became building a dataset that did not already exist.
- Built a scraper pipeline around Gamma API, Data API, and optional CLOB enrichment rather than relying on one shallow source.
- Generated artifacts such as features, raw trades, top holders, trader metrics, and status outputs so research could be resumed and audited.
- Added resume offsets, ID normalization, minimum volume filters, and trader-level caching because collection stability mattered more than modeling novelty.
- Moved beyond generic price history with top-holder concentration, whale-style scoring, and market-lean features that better reflected who was actually trading.
Phase 02
15-minute execution research
The second phase shifted from long-horizon prediction into 15-minute Up and Down markets where the main question became execution quality, not just direction.
- Built a vectorized research stack with FADE, MOMENTUM, REVERSE, and DUAL_ENTRY modes, plus large parameter sweeps and walk-forward evaluation.
- Added volatility-by-slug analysis, lock pairs, and flip diagnostics so configuration choices were tied to market behavior instead of one lucky run.
- Implemented a live state machine on the CLOB using WebSockets for awareness, minimum size rules, proactive stop behavior, and baseline costs like 30 bps fees and 10 bps slippage.
- Packaged the work into a server and dashboard workflow, then used mismatch reports to diagnose where exported windows and backtests were diverging by slug universe.
Phase 03
HFT infrastructure and recorder design
The last phase focused on second-scale windows, recorder quality, and a sharper split between low-latency code and flexible research infrastructure.
- Moved hot-path WebSocket handling and feature helpers into Rust while keeping orchestration, ETL, and LightGBM training in Python.
- Recorded raw feeds to JSONL, converted them to Parquet, and prepared curated L1 and L2 datasets before trusting any downstream model numbers.
- Tracked local receipt time, Binance age, and Polymarket age so alignment used what the strategy could have known rather than future-friendly timestamps.
- Evaluated multiple target families including adverse selection and maker-style labels, then compared strong classifier metrics against the harder question of executable PnL.
Cross-cutting lessons
What held the whole project together
Across all three phases, the strongest technical theme was not prediction itself. It was realism under operational constraints.
- Data pipelines had to be treated like first-class research assets, not as a prelude to the real work.
- Backtests had to survive payout audits, order sequencing, latency, slippage, leakage checks, and final-minute distortions before they were worth reading.
- Execution systems had to separate inventory from open orders, keep blocking API work off the hot loop, and treat WebSockets as the live source of truth.
- Stopping when the evidence weakened was part of the engineering process, and the infra that survived that stop became the lasting asset.
Portfolio signal
Why this work belongs in the portfolio
This is one of the clearest examples of how I like to work: build the system, make the measurement honest, and keep the parts that remain valuable even when the first thesis weakens.
The repo shows technical range across API ingestion, market microstructure, state-machine execution, vectorized research, Rust and Python interoperability, ETL design, and failure analysis.
It also shows credibility. The story now maps back to real project artifacts such as scraper outputs, optimizer reports, HFT documentation, model evaluation files, and live-trading architecture notes instead of reading like a polished but generic summary.
Next move
Want the detailed notes behind it?
The article section keeps the deeper breakdowns, but this page is now the fastest faithful summary of the full arc from data collection to live architecture to honest stopping point.