Lucas Reymond

I built this project out of curiosity about the infrastructure behind automated trading on prediction markets. I wanted to understand the full stack, from raw real-world data to a live order on an exchange, and to learn it properly I picked a concrete, self-contained example: trading Polymarket markets on the number of large earthquakes occurring within a given week. Earthquakes are a good test case because they are driven by a genuinely external physical process, they have high-quality public data, and the markets resolve on a clear, countable outcome.

The markets I targeted ask how many earthquakes of magnitude 5.5 or above will occur worldwide during a fixed window, with a separate outcome for each possible count. To price those outcomes I implemented an earthquake forecasting model based on the ETAS (Epidemic-Type Aftershock Sequence) point process, which combines a Gutenberg–Richter magnitude law, an Omori–Utsu aftershock-decay kernel, and a background seismicity rate. I fit the model by maximum likelihood (Ogata’s formulation) on the global USGS catalog from 2010 onward, then turned the fitted process into a distribution over the number of events in the market window using two independent engines:

• an analytical engine that derives the expected count from the conditional intensity and models the count distribution as an overdispersed (Negative Binomial) variable, with the dispersion tied to the branching ratio of the process;
• a Monte Carlo engine that simulates hundreds of thousands of synthetic futures of the catalog forward in time as a branching process and estimates each probability empirically, together with a Monte Carlo confidence interval.

Around this model I built the operational layer that makes it a real bot rather than a notebook:

• a multi-source data poller that queries several seismic networks (USGS, EMSC, IRIS) through their FDSN web services every few seconds, with USGS kept as the authoritative source for resolution;
• a cross-source association and “early-signal” component that matches the same event reported by different networks (by time, location, magnitude, and depth), so the bot can react to a qualifying earthquake as soon as a fast network reports it, before the market fully reprices;
• an execution layer on the Polymarket CLOB that places limit and fill-or-kill orders, handles position sizing and chunked exits, and persists state across restarts, with Telegram alerts and full snapshot logging for later analysis.

The goal was never to get rich on earthquakes (the position sizes were deliberately tiny) but to learn, end to end, what it takes to connect a probabilistic model of a real-world process to a live market: data ingestion and reconciliation, statistical forecasting, latency, order execution, and the operational plumbing that keeps a bot running unattended.