Can You Use Freqtrade for Prediction Markets?

Short answer: you can borrow Freqtrade's ideas, but you cannot point it at Polymarket or Kalshi and trade. Freqtrade is built around a specific market shape, spot and perp crypto pairs on CCXT-connected exchanges, and prediction markets break several assumptions baked into that shape. This post walks through what actually carries over, what breaks, and where the gaps are.

What Freqtrade actually is

Freqtrade is a mature, well-understood tool. It is a free and open source crypto trading bot written in Python, and it has been around since 2017 with a large contributor base. The parts people value are concrete and worth keeping in mind as a design benchmark.

The framework gives you a full pipeline: you write strategies in Python, backtest against historical OHLCV data with reports covering profit, drawdown, trade count, and win rate, and then deploy to live trading. For live execution, Freqtrade connects to exchanges via the CCXT library and handles order types, position sizing, and stop-losses. It also ships a dry-run mode so you can run a strategy without committing capital.

So the abstractions are: a strategy class, indicators computed over price candles, buy and sell signals, a risk layer, a backtester, and a live executor talking to a standardized exchange API. Hold those in mind.

What carries over to prediction markets

Plenty of the mental model survives. Prediction-market venues have order books that look familiar to anyone who has traded crypto. On Polymarket, each outcome is represented by a token traded on a central limit order book, and its price reflects what traders will pay for that outcome while the book shows resting bids and asks. Kalshi is similar in spirit: prices are expressed in cents from 1 to 99, representing the implied probability of the event.

That means several Freqtrade-style patterns transfer directly:

• Strategy-as-code. A Python class that reads market state and emits enter/exit decisions is the right abstraction here too.
• Signal logic on a time series. You can compute momentum, mean-reversion, or cross-venue spread signals on a price series that runs 0 to 1 (or 1 to 99 cents) instead of dollars.
• Paper trading before real money. Freqtrade's dry-run instinct is exactly right; both venues expose data and demo paths to test against.
• A risk layer. Position sizing, per-trade caps, and stop conditions are venue-agnostic ideas.

What breaks

The breakages are not cosmetic. They are structural, and they are why a straight port does not work.

Binary resolution instead of open-ended price. A crypto pair has no terminal value; it just keeps trading. A prediction-market contract resolves. A Kalshi contract settles to a fixed value per contract, yes or no, at expiration. Freqtrade has no concept of a position that expires to a known payoff on an external event. Your exit is not only 'sell when signal flips', it is also 'this market resolves on date X and I am holding the wrong side'. Backtesting has to model settlement, not just mark-to-market P&L, and stop-losses behave differently when the instrument can gap straight to 0 or 1 on news.

No CCXT adapter. Freqtrade's exchange connectivity runs through CCXT. Polymarket and Kalshi are not CCXT venues, and their APIs are not interchangeable with each other. Polymarket's order book is served from its CLOB with public read endpoints and a WebSocket market channel for live book, price, and trade events, using token IDs per outcome. Kalshi exposes REST, WebSocket, and FIX 4.4, with its own auth (tokens that expire and RSA-based signing) and ticker scheme encoding series and expiration. You would be writing two bespoke adapters, not configuring one.

Different market identity and lifecycle. Freqtrade thinks in whitelisted pairs. Prediction markets are thousands of short-lived, event-specific contracts that appear, trade, and disappear. Discovery, mapping outcome tokens to a tradable instrument, and tracking a market's state through its lifecycle are first-class problems here, not a static config list.

OHLCV history is thin and sometimes absent. Freqtrade's backtester assumes years of candle data. Many event contracts live for days or weeks and have sparse, illiquid history. The FreqAI-style approach of training on long feature histories does not map cleanly onto a market that will not exist next month.

The regulatory layer Freqtrade never had to think about

Crypto bots rarely encode venue eligibility. Prediction markets force it. Kalshi operates as a CFTC-regulated designated contract market, and the regulatory landscape is actively contested across multiple states and circuits. As of August 2026, courts have reached conflicting conclusions: the Third Circuit affirmed a preliminary injunction in Kalshi's favor against New Jersey on April 6, 2026, in the first federal appellate ruling on whether sports event contracts qualify as swaps under the Commodity Exchange Act, while a federal judge in Utah granted summary judgment to the state on August 5, 2026, ruling that federal commodities law does not override Utah's anti-gambling authority. The CFTC has also intervened directly, exercising emergency authority in July 2026 to stay a Kalshi rule change and order the exchange to continue fulfilling trades involving Michigan residents despite a state court order directing otherwise. The point for an automation author: eligibility and venue status are moving targets you have to design around, not hardcode.

The gaps a prediction-market runtime fills

Add up the breakages and you get the spec for what a Freqtrade-equivalent needs to do differently: model resolution and settlement, speak the native Polymarket and Kalshi APIs instead of CCXT, handle short-lived event contracts and their discovery, and treat the risk envelope as a hard constraint rather than a suggestion.

This is the gap Banger is built for. You write a strategy as a Python class (banger.Strategy) or clone one from a marketplace, paper-trade it against the live order book, then run it under a declarative risk envelope: per-trade cap, daily loss stop, max open positions, and a kill switch. It targets Polymarket and Kalshi directly, and it never custodies funds, you bring your own venue keys.

pip install bangertrades
banger run strategy.py --paper

The Freqtrade instincts you already have, strategy-as-code, paper first, an explicit risk layer, are the right ones. They just need to sit on top of an engine that understands binary settlement and the two venues' actual APIs instead of a crypto exchange abstraction.

Bottom line

Use Freqtrade as a source of good patterns, not as a drop-in tool for prediction markets. The strategy structure, backtest discipline, and dry-run-before-live workflow all transfer. The exchange layer, the P&L model, and the market lifecycle do not. If you want those patterns applied to Polymarket and Kalshi without hand-rolling two API clients and a settlement-aware backtester, that is exactly the layer a purpose-built runtime provides. Whatever you use, verify current venue eligibility yourself before trading, because the legal picture is shifting month to month.