Position Sizing for Polymarket Bots: Kelly vs. Fixed Fractional



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_prob, market_price): “”“ my_prob: your estimated probability of YES market_price: current market price (implied probability) Returns the fraction of bankroll to allocate “”“ b = (1 - market_price) / market_price # odds received q = 1 - my_prob f = my_prob - (q / b) return max(f, 0) # never bet negative
In theory, full Kelly maximizes long-term bankroll growth. In practice, on prediction markets specifically, full Kelly is dangerous for a reason that doesn't show up in the textbook version of the formula: your probability estimate has its own error bars, and Kelly sizing amplifies whatever confidence you feed it. If your model is even slightly overconfident, full Kelly will oversize positions and the variance will hurt more than the formula suggests.
What I actually run: fractional Kelly In production, I size at roughly 25-50% of full Kelly, not full Kelly. This trades some theoretical growth rate for meaningfully lower variance - which matters more in practice than the math suggests, because your edge estimate is a model output, not a certainty. A half-Kelly position sized against a slightly wrong probability estimate is recoverable. A full-Kelly position sized against the same error can wipe out a disproportionate chunk of your bankroll on a single bad estimate. def sized_position(my_prob, market_price, bankroll, kelly_multiplier=0.4): full_kelly = kelly_fraction(my_prob, market_price) fraction = full_kelly * kelly_multiplier return bankroll * fraction Where this connects to execution This ties directly into the execution validation from my last post: your sizing calculation happens at decision time, using the book state at that moment. If the book drifts before your order lands, the sizing you calculated may no longer match the liquidity actually available at that price level. Worth checking that your position size doesn't exceed what's actually resting at your target price after your drift-tolerance check passes - otherwise you're sized correctly for a book that no longer exists, which is the same underlying problem as the execution timing issue, just showing up in the sizing layer instead. The practical takeaway If you’re running a bot with a working edge calculation and proper execution validation but still seeing inconsistent results, sizing is the next place to look. Fixed sizing wastes your best opportunities. Full Kelly overexposes you to model error. Fractional Kelly, tuned conservatively, tends to be the more durable choice once you’re running real capital instead of backtests. I build execution and risk infrastructure for prediction market bots and provably fair systems for casino platforms. If you're working through sizing or risk logic on something similar, happy to compare notes.

Comments

Post a Comment

Popular posts from this blog

How a Polymarket Arbitrage Bot Actually Works: 5 Strategies Explained

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...
Read more

Why Every Polymarket Trading Bot Needs to Adapt to TWAP

When building a Polymarket trading bot, it's easy to focus on prediction models, latency, and order execution. However, platform infrastructure changes can have an even greater impact on a trading system than a new strategy. With Polymarket introducing TWAP (Time-Weighted Average Price) settlement for crypto Up/Down markets, I spent the last few days reviewing how my bot behaves near market resolution. Supporting TWAP wasn't simply replacing one price calculation-it required rethinking assumptions around settlement, execution timing, and trade evaluation. This update reminded me that trading bots aren't static software. They're living systems that must evolve alongside the markets they interact with. Over the coming weeks, I'll share a detailed technical breakdown covering the architecture changes, implementation decisions, and lessons learned while updating my Polymarket trading bot for the new TWAP model.
Read more

Building a Polymarket Trading Bot: Order Book Monitoring, Slippage Handling, and Position Sizing

  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 ...
Read more