Polymarket Arbitrage Bot

Polymarket is a prediction market platform where every trade is public - you can see exactly what any wallet bought, at what price, and when. Some of these markets ask a simple question: will Bitcoin be higher or lower five minutes from now? Most bots trading these markets look at one signal at a time - momentum on a short timeframe, or comparing the market price to a live Bitcoin price feed. Traders in other markets, like leveraged futures, often do something different: they check whether multiple timeframes agree before trusting a move. A longer timeframe tells you the overall trend, a medium one confirms the current move still has room, and a short one times the entry. I wanted to see if that same idea - checking several timeframes before acting - could work for Polymarket's short Bitcoin markets. It mostly does, but only once you strip out the parts built for a different kind of trading. Why the full version doesn't transfer The original version of this idea comes fro...

A prediction-market price is not a price. It's a probability the crowd agreed on a moment ago. The second real news arrives, that number is wrong - not forever, just for the few minutes it takes everyone else to finish the same math a Polymarket trading bot can run in milliseconds. When a market says an outcome trades at 38 cents, it's telling you the crowd's probability for that outcome is about 38%. On Polymarket, the price and the probability are the same object. Every price on the order book is a snapshot of a belief - and unlike a stock chart, the correct way to update that belief when new information arrives isn't a matter of opinion. It's a matter of math. That math is Bayes' theorem, written down in 1763: P(H|E) = P(E|H) × P(H) / P(E) Your prior P(H) is the current market price. The likelihood P(E|H) is how likely the news would be if the outcome were actually going to happen. P(E) is how likely the news was in general. The posterior P(H|E) is the up...

Polymarket is a prediction market platform where every trade is public - you can see exactly what any wallet bought, at what price, and when. I built a tool that takes that public history and works out what strategy a trader is actually using, then turns it into rules a bot can run on its own. Here's how it works, and the one finding that made this actually interesting instead of just a data-collection exercise. The pipeline collect → enrich → signals → analyse → report Collect pulls full trade history for a wallet from Polymarket's Data API (handles 100k+ fills via cursor pagination), plus market metadata for everything they traded. Enrich joins external context onto every single trade at the moment it happened: Binance and Coinbase OHLCV, the Chainlink ETH/USD oracle price on Polygon, order book spread and imbalance from the Polymarket CLOB, and how close the trade was to market close (I bucket this into early, mid, late, urgent phases). Signals computes candidate featur...

Originally published on Substack: casatrick.substack.com/p/polymarket-arbitrage-bot-execution-speed Ask someone to explain a Polymarket arbitrage bot and they will describe the detection logic. YES and NO prices should sum to one dollar, and when they do not, buying both sides and redeeming the pair locks in the gap as profit. That explanation is correct, and on its own it is almost useless, because detecting the mispricing was never the hard problem. Every arbitrage bot watching Polymarket's public order books sees the same gap at roughly the same moment. The real problem is what happens in the few seconds after that. A pricing inefficiency on Polymarket does not sit still waiting to be captured. The moment it appears, every bot polling that market can see it, and the first execution to actually hit the order book starts consuming the exact liquidity the gap depended on. Miss the window and you are no longer capturing arbitrage, you are providing exit liquidity for whoever got ...

A Polymarket arbitrage bot scans prediction markets for pricing inefficiencies and executes trades to capture the resulting spread. That's the concept in one sentence, but arbitrage on Polymarket isn't one strategy, it's several distinct mechanisms, each exploiting a different kind of mispricing. Here's a breakdown of how each one works, based on an open-source implementation. Intra-market arbitrage is the core mechanic. In a binary Polymarket market, YES and NO token prices should always sum to $1.00. When combined pricing falls below that after fees, buying both outcomes locks in a profit that doesn't depend on which outcome actually happens. Buy YES and NO, merge the tokens into a complete set, redeem for $1.00 per share. This is the closest thing to genuinely risk-free arbitrage available in prediction markets. Combinatorial arbitrage extends the same logic to multi-outcome markets, like price-range or bracket-style markets with three or more possible outcomes...

Most writeups on trading bots - including my own last piece - focus on getting the edge calculation right and executing before the price moves. Almost none of them cover what happens after: how much to actually bet once you’ve decided a trade is worth taking. Get this step wrong and a correctly identified edge can still lose you money over time. The naive approach: fixed sizing The simplest method is to size every position the same - a fixed dollar amount or a fixed percentage of your bankroll, regardless of how large the edge is. It’s easy to implement and easy to reason about. It’s also leaving money on the table on your best opportunities and overexposing you on your weakest ones, since a 2% edge and a 15% edge get treated identically. Kelly Criterion: sizing by edge and odds The Kelly Criterion sizes each bet as a function of your edge and the odds being offered, rather than treating every trade the same. The formula, adapted for a binary prediction market: def kelly_fraction(my_pr...

 I've spent the last several months building execution infrastructure for prediction market bots - mostly on Polymarket - alongside RNG and fairness systems for casino-style games. Two very different domains, but they share a failure mode most devs don't think about until it costs them money: the gap between deciding to trade and actually executing. Most tutorials on trading bots stop at the pricing model. Poll the orderbook, calculate implied probability, compare against your own model, fire an order when edge clears some threshold. That's the part everyone writes about. It's also the part that matters least once you're running on thin-liquidity markets. Where the standard approach breaks Here's the loop almost every intro-level bot uses: fetch the orderbook, calculate implied probability from it, compare that against your model's own probability estimate, and if the edge clears a threshold, place an order sized to that edge. This works fine on markets wit...

I didn't start this with a traffic plan. I started it because I was stuck building a Polymarket trading bot that kept losing money to slippage on thin markets, and posting about the problem was easier than staring at it alone. A few honest observations from doing this for a while now. The broken version travels further than the finished one. A post about my bot getting picked off by a better-informed trader outperformed every clean-architecture post I've written. People comment on the mistake because they've made it too. Copy-pasting the same post everywhere underperforms rewriting it per platform. It's more work, but Hacker News wants the technical argument with no self-promotion, dev.to wants the code, and Twitter wants one sharp claim rather than a summary. Identical copies did worse everywhere I tested it. The casino-versus-prediction-market comparison is a strong hook, used sparingly. It worked well the first time as an intuitive way to explain why naive bots l...

  Most first-attempt Polymarket bots place a market order and call it done. That works fine on liquid, high-volume markets, but Polymarket has thousands of long-tail markets with thin order books and wide bid-ask spreads, where a naive market order can fill at a price far from the quote seen just a moment earlier. Polymarket's API is split into two services. The Gamma API handles public, read-only market discovery. The CLOB API handles order books, prices, and actual trading. Reading market data requires no authentication, while placing orders does. A solid bot workflow starts by discovering a market and pulling its order book, then calculating edge by comparing a model's estimated probability against the market's implied probability. Position sizing should use a fractional-Kelly approach, capped by a hard maximum exposure per market, since that cap matters more for risk control than the Kelly fraction itself. Before filling an order, checking remaining order book depth ...

  Most people building a Polymarket trading bot copy risk logic straight from casino or RNG betting bots. That's a mistake, and here's why the risk models are fundamentally different. Casino RNG games run on fixed, exogenous odds. The wheel doesn't care what you bet. Risk management there is bankroll sizing and variance control using tools like the Kelly criterion and stop-losses. Polymarket runs on reflexive, endogenous odds. The price is the collective belief of every trader in that market, and it moves in response to your own trades. That is a completely different risk surface. Four risks casino-style bots never model on Polymarket: no stable probability distribution since beliefs update on new information, adverse selection from traders with better information, market impact and slippage since Polymarket has an actual order book, and correlated exposure across related real-world events. What actually works instead: dynamic re-pricing triggers tied to new informatio...

 I did not plan this. I noticed it in the data. When I started logging every trade my bot made I expected the activity to be spread out across the full market window. Buy a little here, sell a little there, collect the spread all day. That was the theory. The reality looked completely different. Almost everything was happening right at the end. At first I thought something was wrong with the bot. Maybe it was slow to start. Maybe the early market conditions were too wide to trade profitably. I dug into the logs and what I found actually made sense once I thought about it. Early in a market the probability is uncertain. On a BTC 5 minute market nobody really knows where price is going in the next 300 seconds. The spread is wide because nobody wants to commit. The order book is thin. My bot would post orders and nothing would fill because everyone else was doing the same thing - waiting. As the market gets closer to resolution something changes. The probability starts to collapse...

  How I Built the Hedge Logic for My Polymarket Straddle Bot The concept is simple. Buy YES and NO on the same market. Keep combined cost below $1.00. Collect at settlement. No directional bet required. The implementation is not simple. Here's exactly how I built the hedge logic step by step. Step 1: Track Two Legs Independently First thing the bot needs: separate state for each side of the same candle. Each leg tracks: shares held total cost paid VWAP (total cost / shares) Combined VWAP = Up VWAP + Down VWAP That combined number is the only number that actually matters. Below $1.00 means you have a locked spread. Above $1.00 means you're in the red on the hedge and need price to bail you out. I got this wrong in the first version. I was tracking a single position and trying to calculate the hedge after the fact. Doesn't work. You need two independent ledgers from the start. Step 2: Define What a Signal Actually Is The bot scans the CLOB every second. Each scan ru...

How I Built a Market Maker Bot on Polymarket (And What I Learned) I've been trading on Polymarket for a while now, and at some point I got tired of manually placing orders. So I did what any developer would do - I automated it. This post is about how I built a simple market maker bot on Polymarket, what went wrong, and what actually works. What is Market Making Anyway? Market making is simple. You place a buy order and a sell order at the same time. You buy at $0.45 and sell at $0.55. If both orders fill, you pocket the difference - the spread. You're not betting on the outcome. You're just providing liquidity and collecting the spread over and over again. On Polymarket, every market is a YES/NO token. So instead of price, you're working with probabilities. A YES token at 0.45 means the market thinks there's a 45% chance of YES. Why Polymarket is Good for Market Making A few reasons I chose Polymarket. They have a real order book (CLOB - Central Limit Order...