How a Kalshi Bot Lost 369 Trades in a Row (And What We Learned)

In May 2026, we deployed a new strategy on our Kalshi bot — buy cheap contracts for asymmetric upside. The thesis was sound. The implementation was not. Over three days of paper trading, the strategy made 369 trades. Zero wins. Zero P&L movement. Every single contract expired worthless at the entry price.

Most bot teams would quietly archive a result like that and ship the next iteration. We're publishing the postmortem instead — because the failure mode is structural, the lessons transfer, and the kind of overnight-ruin numbers we caught in paper mode would have wiped out a real account in 72 hours. If you're building a Kalshi bot, what we learned is worth the read.

The Thesis (Why We Tried This)

Kalshi's Bitcoin daily-cycle market (KXBTCD) lists hourly contracts at strikes spanning the current spot price. Each contract is a binary YES/NO question: "Will BTC be above $X by [time]?" Prices range from $0.01 to $0.99, and they settle to either $0 or $1 based on what BTC does.

Cheap contracts — those trading at 1¢–10¢ — represent asymmetric bets. You risk a known small amount ($0.01 per contract). If you're right, you get a 99x return. The math is appealing: even if only a small fraction of cheap contracts settle in your favor, the winners can pay for many losers.

Our strategy, which we called Distressed, was a systematic implementation of that thesis. Every 30 seconds, the bot scanned ~200 active KXBTCD markets and filtered for:

• Contracts on the side our regime model favored
• Ask price between 1¢ and 10¢
• Time to close between 10 minutes and 5 hours
• Then it picked the cheapest qualifying candidate

It bought 5 contracts per entry, with up to 8 concurrent positions, and held until either the bid hit 90¢ (a 90x return) or the contract expired.

We deployed it in paper mode — simulated trades writing to a database, no real orders sent to Kalshi — to gather data before risking capital. We expected a low win rate but profitable winners. We expected something to happen. Nothing happened.

What Actually Happened

Three days later, here's what the database showed:

The line that matters: not a single contract ever traded above its 1¢ entry price. Not even briefly. Not on a 0.5% BTC move, not on a 2% BTC move, not when news broke. The bot bought 369 contracts, and 369 of them sat at 1¢ until they expired worthless.

This is worse than losing. Losing means the market moved against you. This means the market never had any reason to care about the contracts we bought.

Flaw 1: 1¢ Contracts Are Dead Money

The 1¢ floor exists for a reason. Kalshi's tick size is 1¢ (you can't bid below it), so contracts cluster at 1¢ when nobody believes they have any meaningful chance of settling YES. The order book is a market consensus: if everyone agreed the contract was worth 5¢ in expectation, someone would bid it up. Nobody does.

Looking at the specific contracts our bot bought:

• YES at $88,799 when BTC was at ~$83,000 — required a +$5,800 move (+7%) in 55 minutes
• NO at $79,799 when BTC was at ~$83,000 — required a −$3,200 move (−4%) in 55 minutes

BTC's typical hourly volatility is around 0.5% to 1%. A 7% move in an hour is a roughly 4-5σ event — the kind of thing that happens a few times per year, not per day. The market correctly priced these contracts as near-impossible. Our bot bought lottery tickets that everyone else had already declined to play.

The lesson is mechanical: contracts trading at the 1¢ floor on Kalshi have negligible liquidity above 1¢, and almost never move there even when the underlying does. Cheap-contract strategies need an entry floor of at least 5¢ — that's where you start to access contracts the market actually believes have a real chance.

Flaw 2: The Time Horizon Was Impossible

Even if 1¢ wasn't structurally dead money, the 55-minute hold window doesn't give BTC time to make the moves required for far-OTM strikes to come into play. We were essentially betting that within a 55-minute window, BTC would make a move large enough to:

1. Push the spot price toward our strike
2. Convince other traders the move was sustained
3. Move the order book up to our 90¢ exit target

All three things have to happen, in 55 minutes, on contracts that started 5–7% out of the money. The compound probability is essentially zero. The right horizon for this kind of strategy is hours to days, not minutes.

Flaw 3: The Exit Target Was Unreachable

A 1¢ → 90¢ trajectory in an hour is a 90x return. The price path required is roughly: BTC moves dramatically → market thinks the move is irreversible → order book rebuilds at the new price level → our resting offer fills. Each of those steps takes time. None of them happen for an OTM strike that briefly comes into play before retracing.

Real winning trajectories on cheap contracts look more like 5¢ → 25¢ → 60¢ — a multi-hop progression as the underlying continues to move and conviction builds. They almost never look like 1¢ → 90¢. Setting the exit target there is asking the market for a perfect storm; setting it at 2.5x or 5x lets you take real profits on real moves.

Two Contributing Causes

Beyond the three primary flaws, two design choices made the strategy worse than it had to be.

No volatility gate. The bot entered regardless of market conditions. In low-volatility regimes (which is most of the time), all OTM contracts decay toward zero, and there's no chance of any winner. Even a 1¢ contract that's destined to expire worthless is paying an admission fee to participate in a game that can't be won that hour. The strategy should sit idle during calm periods. Ours didn't.

"Cheapest" pick rule. The bot picked the lowest-ask qualifying contract. That selection criterion systematically chose the furthest-OTM strikes available — exactly the contracts least likely to ever come into play. A "best value" rule (e.g., contracts closest to spot, or weighted by implied probability) would have selected entirely different contracts. We picked by price; we should have picked by relevance.

Five Transferable Lessons

If you're building a Kalshi bot — or any systematic trading strategy on a binary market — these lessons generalize beyond our specific failure.

1. Pre-register your hypothesis with stop criteria. The single biggest process gap in our run: we didn't write down what we expected, so we didn't have a stop. After 50 losing trades, we should have paused. Instead, the strategy ran to 369 because no rule fired. Before deploying any new strategy — paper or live — write down: what win rate counts as "working"? What sample size do you need to know? What rule triggers an automatic halt? Without these, even unambiguous failure runs longer than it should.

2. Cheap doesn't mean undervalued. The favorite-longshot bias is well-documented in prediction markets: longshots are systematically overpriced relative to their true probabilities. Buying YES at the cheap end means you're working against the bias, not with it. If you want to exploit favorite-longshot, sell NO on overpriced longshots. If you want to buy cheap, you need to find specific contracts where the market underestimates the probability — not a systematic strategy of buying whatever's cheapest.

3. Match horizon to required move size. Strategies that need rare moves to succeed need long enough horizons to see them. A strategy whose winners require 5σ events in 55 minutes is a strategy with no winners. Look at the price-path your trade requires and ask whether the time window is realistic. If not, widen the window or pick different markets.

4. Tiered exits beat moonshot exits. A single 90¢ target on a 1¢ entry assumes every winner reaches near-certainty before exit. That's not how prices move on prediction markets. Tier exits (sell 1 at 2.5x, sell 1 at 5x, ride the rest to settlement) capture real winners without requiring the perfect storm. Take partial profit on the way up.

5. Build measurement before strategy. Our 369-trade run had limited diagnostic logging. Reconstructing why specific candidates were picked required reading code rather than reading logs. The v2 build adds throttled diagnostic output so we can see, in real time, why the bot is and isn't trading. If you can't tell why a bot made the decisions it did, you can't fix it when it's wrong.

What v2 Looks Like

We rewrote the strategy with each problem addressed:

• Entry floor 5¢, ceiling 10¢ — accesses contracts with real price discovery
• Strike-distance filter: within 2% of spot — picks near-the-money contracts where small BTC moves move the price
• Time-to-close 55 min to 5 h — gives BTC enough runway to actually move
• Volatility gate: only enter when BTC moved >0.3% in last 30 min — sits idle in calm regimes
• "Best value" pick: smallest strike distance, tie-break on cheaper ask — prefers relevance over price
• Tiered exits: sell 1 at 2.5x, sell 1 at 5x, ride remainder to settlement — captures real winners
• Position size 3 (was 5), max concurrent 4 (was 8) — smaller exposure while learning
• Stays in paper mode until n ≥ 200 with positive P&L — pre-registered stop criteria

v2 is running now. We'll publish the next postmortem when there's enough data to evaluate it — confirming the thesis or refuting it again, but this time with a real signal to compare against.

Why We're Publishing This

Three reasons.

One: postmortems are how strategies get better. Most bot teams build in private and only share success stories. The result is a literature heavy on selection bias — every strategy that gets written about is one that worked. The actual failure modes go unwritten. Anyone trying to enter the space has to rediscover them. We'd rather contribute a real failure mode to the public record than pretend we had it figured out from the start.

Two: we caught this in paper trading. If you're considering writing your own bot, run it in paper mode for at least 30 days before sending real orders. Strategies that look brilliant on backtest data routinely fall apart in paper because backtests don't model spread, fade, or adverse selection. Paper trading catches what backtests don't. The 369-trade record cost us nothing but operator attention; if it had been live, it would have been a 72-hour bankroll-draining spiral.

Three: the alternative is that someone else builds the same strategy and ships it live without ever paper-testing. They lose real money discovering the same lessons. We'd rather they read this first and try something better.

If you're working on a Kalshi bot and want to talk through what you're seeing — or if you've built something that worked where ours failed — we'd love to hear from you.

Want to see the rest of the open-source Kalshi bot landscape? Read our companion post: The Open-Source Kalshi Bot Ecosystem (30+ Projects) — a catalog of what's out there, organized by strategy type, with honest notes on what each does well.