Kalshi BTC 15-Minute Bot: Setup, Backtest & Paper Checks (2026)

A Kalshi BTC 15-minute bot trades KXBTC15M, Kalshi's rolling "BTC price up in next 15 mins?" series. Every 15 minutes a new market opens. Each one asks whether Bitcoin will finish its 15-minute window at or above the price it started at. The bot follows each new market, checks your entry rule on a fixed loop, and exits or flattens before the market closes.

What you need:

• A Kalshi account and API key for a Paper Run or live trading. A historical backtest needs neither.
• Written rules: which market, when to buy, when to sell, how many contracts, and a loss limit.
• A backtest of those exact rules, then a Paper Run on new data, before any live order.

Build a KXBTC15M Bot in Studio · Read the Example Strategy

Not investment advice. Prediction-market trading can lose money, and no bot guarantees returns.

Short answer: the documented example lost money

We ran the rolling BTC 15-minute example from our docs, unchanged, through Studio's default 30-day backtest on October 19, 2026. It lost $126.38 after modeled fees. This was a historical replay, not a Paper Run or live trading. No orders were sent to Kalshi.

The public run page lists the strategy as "One-Shot Discount Clock Exit". Every figure above is copied from the run manifest, and our build checks this page against it.

Read the result with its limits:

• Coverage was partial. The manifest's sampled reason for the 3,666 skipped events is beyond_settlement_frontier. A partial window is not a full 30-day test.
• The CSV is a snapshot. It stores 10,000 of the run's 14,408 order events, through October 8, 2026 at 17:13 UTC. Rows are order events, not round-trip trades.
• Fills are simulated. Orders fill against the next executable recorded quote, with no real queue position, latency or market impact.
• The loss limit differs from live. The replay applies max_loss: 5.00 to each market. A live deployment applies it across all markets and would have halted much earlier.

Fees were $61.51 of the $126.38 loss, nearly half. The example is a configuration reference, not a recommended strategy.

The reviewable setup: market, rules and sizing

The whole strategy fits on one screen. This is the documented example the run above replayed:

version: 1
platform: kalshi
strategy: custom
strategy_name: BTC 15-minute series, one entry per window
market:
  series_ticker: KXBTC15M
risk:
  max_position: 2
  price_floor: 0.10
  price_ceiling: 0.90
  max_entries_per_market: 1
  max_loss: 5.00
loop:
  interval: 10
rules:
  - name: flatten_before_close
    when:
      all:
        - {field: position_size, op: ">", value: 0}
        - {field: time_to_expiry, op: "<=", value: "2m"}
    action: sell_all
  - name: take_profit
    when:
      all:
        - {field: yes_position_size, op: ">", value: 0}
        - {field: yes_best_bid, op: ">=", value: 0.75}
    action: sell_yes
  - name: enter_cheap_yes
    when:
      all:
        - {field: position_size, op: "==", value: 0}
        - {field: time_to_expiry, op: ">", value: "8m"}
        - {field: yes_best_ask, op: "<=", value: 0.35}
    action: buy_yes
    size: 2

Check each part before you test it:

Rules run top to bottom, and the first one that matches acts. That is why the flatten rule sits above take-profit and both sit above the entry: exits come first. The custom rules reference explains the ordering, and why a guard placed above your exits can block them.

The entry cap resets for each new market, so this example can enter up to 96 times a day. Don't trade the series by hand while the Bot runs: a position the deployment can't explain also halts it.

Why a Kalshi BTC 15-minute bot may not trade

A quiet bot is usually following its rules. Most "it never traded" reports come from one of these:

• The entry condition was never true. A $0.35 ask with more than 8 minutes left may not happen in a given window. That is a skip, not a fault.
• The book was one-sided or stale. A buy needs a two-sided, uncrossed book, and every Kalshi order needs the market's last trade to be at most 120 seconds old. An empty side makes order-book fields read as unavailable, and a condition on an unavailable value is false.
• Entries were blocked. Max Daily Loss, a closed trading_schedule, or stale edge data blocks new buys. The matching buy rule is skipped, and the rules below it, exits included, still run.
• The market already had its entry. max_entries_per_market: 1 allows one entry per 15-minute market.
• The deployment halted. Once max_loss is reached, rules are no longer evaluated for that deployment.
• An order was refused. A buy larger than Max Contracts per Order, or above Max Open Contracts, is refused, not shrunk. For this example, set Max Contracts per Order to at least 2.

To read skips, open the running Bot's decision view in Studio. Each rule shows as Met, Not Met, Blocked or Error for each check, with the values it read. A rule marked Not Met is working as written. Blocked and Error name the limit or failure. The conditions reference lists every blocking case, and monitoring covers what to watch.

In a backtest, check coverage before results. Compare requested and actual dates, the coverage status, and the skipped-event reasons. Unavailable history is not a passed test.

The BTC chart is not the settlement price

KXBTC15M does not settle on Coinbase, a chart, or Kalshi's own last trade. The series names CF Benchmarks as its settlement source (Kalshi API, KXBTC15M series, checked October 21, 2026). Each market's rules state the test. For the 4:15–4:30 PM EDT market on October 21:

If the simple average of the sixty seconds of CF Benchmarks' BRTI before 4:30 PM EDT on Oct 21, 2026 is at least the simple average of the sixty seconds of CF Benchmarks' BRTI before 4:15 PM EDT on October 21, 2026, then the market resolves to Yes.

The "Target Price" Kalshi shows on each market is that opening average. Kalshi adds: "While checking a source like Google or Coinbase may help guide your decision, the price used to determine this market is based on CF Benchmarks' corresponding Real Time Index (RTI)." The final value is rounded to two decimal places. See Kalshi's crypto contract terms for the full rules.

That matters in three ways:

1. Your signal is a proxy. Studio's Coinbase edge data reads Coinbase BTC-USD, not BRTI. A rule that compares Coinbase spot with the strike, through signed_distance_from_strike, compares two different prices.
2. The last minute is averaged. A move in the final seconds counts for only part of the 60-second average, so a chart's closing tick can disagree with the result.
3. Settlement pays $1 or $0. A YES contract held to settlement pays $1 if the market resolves Yes and nothing otherwise (Kalshi market settlement).

Fees versus win rate

Kalshi lists KXBTC15M with a quadratic fee type and a multiplier of 1 (Kalshi API). Under the Kalshi fee schedule, a taker fill costs 0.07 × contracts × P × (1 − P), where P is the price in dollars, rounded up under Kalshi's fee rounding rules. Simple yes/no settlement has no fee.

Per contract, before rounding, that formula gives:

Cheap contracts cost more per dollar spent. A strategy that buys at $0.35 and sells at $0.75 pays a fee on both fills.

Win rate alone can't tell you if a bot works. Compare it with the size of wins and losses. Take the example's rules and Kalshi's formula, and work through one entry:

• A take-profit buys 2 at $0.35 and sells 2 at $0.75: +$0.80 before fees, about $0.06 in fees.
• A loss held to $0 costs the $0.70 paid plus about $0.03 in entry fees.

With wins and losses that size, the take-profit has to hit on roughly half of all entries to break even. Fewer losses go all the way to zero, because the flatten rule sells at the bid before close, but that sale pays its own fee. The recorded run won 33.1% of its closed trades and lost money. Its $61.51 in fees was close to its −$64.87 gross loss.

For a contract held to settlement, the break-even probability is the price plus the fee. Buying YES at $0.35 needs the market to resolve Yes more than about 36.6% of the time.

What our research says

Our earlier BTC 15-minute studies tested many rule variants. Each one has its own window, execution model and limits, so read them on their own terms:

• 5,732 Kalshi Bitcoin 15-minute backtests: the current synthesis of our public research reports, and how the cohorts differ.
• 4,904-strategy study: a 30-day sweep ending April 29, 2026.
• 1,000-strategy April study: an early experiment with an older, simplified fill model.
• Coinbase spot edge on Kalshi BTC: 100 strategies that read Coinbase BTC-USD as an outside signal.

None of them is a live trading record. Use them for ideas to test, and test your own rules on a current window.

Paper Run first, then live

A backtest replays the past. A Paper Run applies the same saved rules to new market data with simulated orders and balance. Only a live Bot places real orders.

1. Backtest the exact rules. Run the backtest from Studio and read coverage, fees, drawdown and the trade log, using the backtest results guide.
2. Start a Paper Run. Choose Start Paper Run and connect your Kalshi keys. They supply live market data; orders and balance are simulated, and no funds are used. Let it cover enough 15-minute windows to see entries, skips and exits. A Paper Run uses your plan's concurrent Bot allowance, the same as a live Bot. See pricing.
3. Compare Paper with the backtest. Are skipped entries the ones you expected? Do exits fire before close? Paper fills are modeled too, so they show behavior, not live fill quality. The paper-testing guide has a checklist.
4. Go live small. Choose Deploy Bot and confirm the deploy limits. Max Contracts per Order must be at least your entry size. Set Max Daily Loss to a loss you accept.
5. Know what stopping does. Stopping a Bot, cancelling its orders and closing its positions are separate actions. Read running and stopping a Bot before you go live.

Build a KXBTC15M Bot in Studio

For choosing between bot products rather than setting one up, see our Kalshi trading bot comparison.