Inspiration

Coming into DataHacks, I knew I wanted to work on something that was on the economics track with data analytics. As a Data Science major, I found the field of finance the most interesting, and I joined my school's Introduction to Quantitative Finance class as part of the Triton Quantitative Trading club.

In the Summer of 2024, I stepped into the financial market for the first time by learning day trading concepts on Youtube on the Foreign Exchange Market. I learned Supply and Demand zones, Wyckoff's price theory that posed how financial markets move in predictable cycles, accumulation, markup, distribution, markdown driven by the supply and demand dynamics of "smart money" concepts. I applied these concepts to major currency pairs, journaled and backtested, and made it a little personal project of mine.

Though it was interesting, the only data science knowledge I implemented was using python to test win rate, risk of ruin, statistics from my hypothesis on the chart. The economics track requires me to put use of modelling skills that apply to numbers, which was different from the experiences I have. I wanted to find out whether the trading and quantitative concepts I had learned could actually create an edge in prediction markets like Polymarket, where prices are directly tied to real-world data and market efficiency is constantly tested, building this trading bot.

What I learned

If I can summarize my biggest lesson during this time of building my trading bot into one sentence, it would be don't predict the future if you can read the present. In the beginning, I started by directional models, where I tried to apply trading analysis concepts I learned from day trading. I used AI to help implement order book imbalance signals, predictions using exponential moving averages (EMA), support and resistance blocks, but after doing some trials on the testing data, it was evident nothing worked.

I then switched my focus to GARCH volatility models, Gaussian estimators, where although it worked on the testing data, it lost money on unseen validation data. Furthermore, the spread cost of the prediction markets also punished me with the guesses I was taking. This was an overfitting that I ran into multiple times.

Ultimately, the only strategy that consistently worked was not really predictive at all. The strategy exploited a structural latency between Chainlink oracle updates and prediction market pricing, where markets lag behind fresh on-chain price updates. Combined with disciplined Kelly-based position sizing, this allowed systematic capture of short-lived mispricing while controlling risk.

Challenges

The biggest challenged I faced building this project was overfitting my models. There were many instances where I would get really excited finding a signal that worked on training data, but fail on validation data with a negative PNL. This is a issue that many people face, and obviously with no many models in the world it just takes time to research the one that fits this project. I tested 10+ approaches before landing on this one that I submitted.

Futhermore, dealing with spread cost was also difficult. Prediction market spreads mean I would need to be right and right enough to the point spread doesn't eat all my PNL. I could have a 58% win rate with average return and still lose money is the losses are larger than the profit. I delt with this by always adjusting to a more decent win rate strategy.

Accomplishment

In the end, I was able to build a trading system that used structural inefficiencies in prediction markets by leveraging real-time Chainlink oracle updates. The final strategy achieved a +47.02% return with a 7.25 Sharpe ratio across 5,000+ trades, which I thought would be enough to present. I learned that timing-based market inefficiencies can be more reliable than traditional forecasting models in noisy financial environments. It is definitely not perfect, but I am happy with the result I put up to.

Next Steps

There are many next steps for this project, but one easy step is to simply test more models. There will never be a perfect model, but I can always improve it by increasing sharpe ratio, minimizing drawdown etc. I would also apply bootstrap permutation testing to further validate that my oracle lag edge is statistically significant and not a lucky sample.