Common Mistakes When Automating Prediction-Market Trading

Automating a prediction-market strategy is easy to start and easy to blow up. The venues have clean APIs, contracts settle to a fixed $1, and a working bot is a weekend project. That simplicity hides the ways a strategy quietly bleeds out. Volume on Kalshi and Polymarket has grown sharply since mid-2025, which means more people are writing bots against these order books, and more of them are making the same handful of mistakes.

Here are the ones that actually cost money, roughly in order of how often they show up.

Ignoring fees, and misjudging where they bite

The single most common backtest error, across every asset class, is leaving out transaction costs and slippage. A strategy that clears a 1-cent edge on paper is a loss once you subtract the taker fee and the spread you cross to get filled.

Prediction-market fees are not flat, and that changes which trades are viable. Kalshi charges a taker fee that follows a probability-weighted formula: 0.07 times price times (1 minus price) per contract, so it peaks at 50-cent contracts and drops toward the extremes. In practice that is around 1.75 cents per contract at even odds and nearly nothing on longshots. Maker orders on Kalshi pay roughly 25% of the taker rate.

Polymarket expanded its taker fees broadly across categories starting March 30, 2026. Rates vary by category: at even odds the taker cost runs from about $1.00 per 100 shares on politics, finance, and tech markets up to $1.75 on crypto, with sports sitting at $1.25 (as of July 2026). Geopolitics and world-events markets remain fee-free. On Polymarket, makers pay no fees at all and earn a daily rebate out of collected taker fees.

The takeaway for a bot: model the exact fee curve for the specific market and side you trade, not a single blended number. A strategy that lives in 50-cent contested markets pays the most; one that scalps near the extremes or posts as a maker pays close to nothing. If your backtest uses a flat fee, it is wrong in both directions.

Underpricing slippage and liquidity

Large orders on thin markets move the price against you, and that hidden cost often exceeds the explicit fee on smaller platforms. Prediction-market depth is wildly uneven. A headline market during a big event is deep; the third leg of a parlay two weeks out is not.

Two concrete fixes. First, size orders against real book depth, not the top-of-book quote. Walk the ladder and compute your true fill price before you send. Second, treat reported volume with suspicion when you use it as a liquidity proxy. Kalshi and Polymarket even count volume differently: Kalshi multiplies contracts by their $1 face value, while Polymarket uses taker notional at the price paid, so the two numbers are not directly comparable. A Columbia University study also estimated that roughly 25% of Polymarket's historical volume reflected wash trading, running notably higher in sports markets, so raw volume can overstate how much you can actually move.

Oversizing and no account-level risk cap

A profitable edge sized too large is still a blown account after a normal losing streak. The failure mode is always the same: per-trade size set by gut, correlated positions treated as independent, and no ceiling on total exposure. In prediction markets, correlation bites harder than it looks. Ten "different" NFL markets on the same Sunday are one bet on a slate of games, not ten.

The discipline that survives contact with live markets is boring and explicit: a maximum per-trade size, a maximum number of open positions, a per-market and per-category exposure cap, and a hard daily loss limit that halts new orders. Give every bot those four numbers before it trades a dollar. This is exactly the risk envelope Banger makes you declare up front, per-trade cap, daily loss stop, max open positions, and a kill switch, so the limits live outside the strategy code and cannot be quietly edited away mid-session.

No kill switch and no graceful failure

Networks fail, orders get rejected, and connections go stale. A bot that assumes the happy path will, at the worst moment, resubmit a filled order or keep trading against a frozen order book. On Kalshi, a 429 rate-limit response carries no Retry-After header and no X-RateLimit headers, so you must apply exponential backoff with jitter yourself rather than retry in a tight loop.

• Wrap every API call in backoff with jitter, and never retry in a tight loop.
• Maintain a local order book from the WebSocket feed instead of polling the REST orderbook endpoint repeatedly. It cuts rate-limit risk and gives you fresher prices.
• Reconcile positions against the venue on startup and on reconnect, so a crash mid-order does not leave your internal state lying.
• Ship a real kill switch: one command or condition that cancels resting orders and stops new ones. Wire it to your daily loss limit.

This is the whole point of paper trading against the live book before going hot. Run the strategy end to end, kill the process at a random moment, and confirm it comes back sane. With Banger that is the default first step: banger run strategy.py --paper against the live order book, so you exercise the failure paths before real capital is exposed. Banger never custodies funds; you bring your own venue keys, which also means key hygiene, keys stored outside the repo and rotated if a machine is compromised, is on you.

Mishandling resolution

This is the mistake unique to event contracts, and the one backtests almost never catch. A prediction-market contract settles to $1 or $0 on a specific resolution rule, and the edge often lives in the wording, not the headline. Bots get burned three ways: assuming a market resolves the instant the real-world event happens (settlement can lag), misreading the exact resolution criteria (a market on what someone "will say" is not a market on what happened), and holding illiquid positions to expiry expecting a clean payout that arrives days later after capital is locked.

Kalshi splits data into live and historical tiers, moving settled markets and aged fills to dedicated historical endpoints. If your bot only reads the live endpoints, it can lose track of positions the moment they resolve. Handle settlement explicitly: know each market's resolution source, expect a lag between event and payout, and account for capital tied up until settlement clears.

Overfitting the backtest

The most seductive mistake. Overfitting is when a strategy is tuned so tightly to historical data that it captures noise rather than a persistent structure, so it looks brilliant in-sample and fails live. As von Neumann put it, with enough parameters you can fit an elephant. The warning signs are an unrealistically smooth equity curve and metrics that are too good to be true, a Sharpe above 3, for instance, is rare enough to be a red flag rather than a trophy.

The defenses are well established: hold out untouched out-of-sample data (reserve a meaningful chunk, not the last week), run walk-forward tests across rolling windows, keep the rule set simple with few parameters, and re-run with realistic fees and slippage baked in. If nudging a parameter slightly erases the edge, the edge was never there. Prediction markets add their own regime shifts, an election cycle, a sports season, a World Cup, so test across different event regimes, not just a calm stretch of one.

The short version

• Model the actual fee curve per market and side, not a flat number.
• Price slippage against real book depth, and distrust raw volume as a liquidity proxy.
• Set explicit per-trade, per-category, open-position, and daily-loss limits before trading.
• Build a kill switch and test the failure paths in paper mode.
• Handle resolution rules, settlement lag, and locked capital deliberately.
• Beat overfitting with out-of-sample data, walk-forward tests, simple rules, and honest costs.

None of this is exotic. Token buckets, backoff, position limits, and out-of-sample testing are standard patterns. The traders who last are the ones who wire them in before the first live order, not after the first bad week.