A Polymarket spike bot is a stopwatch with a wallet attached. It listens to a small set of news channels, decides in tens of milliseconds whether an event is the kind that moves a specific market, and submits a sized order before the human population of the platform has finished reading the headline. The strategy is intuitive on a whiteboard and brutal in practice. Edges are real for the first second or two, then crowd out as other bots arrive, and then partially fade as the initial reaction overshoots the eventual settlement price. This guide walks through what a Polymarket spike bot actually does, the signal sources that feed it, the latency budget from event to fill, the shape of a typical spike, the detector logic in code, position sizing and cooldown discipline, why the edge decays, and the failure modes that turn a profitable build into a slow bleed. The reader who finishes this piece will understand both why a spike bot can work and why most of them do not.
What a spike bot actually does
A spike bot is a single-purpose execution system. It does not predict anything that a human cannot also predict; it acts faster on a small set of conditional rules. The rules look something like: when a named news source reports that event X has happened, and event X is associated with market M, and the current ask on outcome A of market M is below a threshold the bot considers fair after the news, buy A in size S. There is no model, no Bayesian reasoning, no inference about the world that the market has not already done. The bot's only contribution is speed.
That sounds reductive, and it is. It is also exactly the reason spike bots exist as a category. The Polymarket order book is mostly maintained by humans and slower bots that react on the order of seconds. When a wire-service headline crosses, the half-second window between the headline landing and the first manual click is wide enough that a properly engineered spike bot can buy a thousand shares at the pre-news price. By the time the market makers have repriced and the copy-traders have woken up, the spike bot is already sitting on the position with an unrealised gain.
The general execution shape sits inside the broader bot stack covered in the Polymarket bot architecture overview, but the spike bot is a specialised top-of-stack module: a news listener, a fast classifier, a sized order builder, and a strict cooldown. It is not a market-making bot, not an arbitrage bot, and not a copy-trader. It is one tool in a wider portfolio, and a builder who tries to make it do anything else will end up with a worse spike bot and a worse general bot at the same time.
Signal sources
The single highest-leverage decision in building a spike bot is the choice of signal sources. Every other engineering choice is downstream. A bot with a fast, clean signal from a low-coverage source will beat a bot with a slow, noisy signal from a high-coverage source on the same hardware. Most retail spike bots are bottlenecked here rather than at the order-submission layer.
Five categories of source are realistic for a retail spike bot. Each trades latency, false-positive rate, coverage, and cost differently. The table below is calibrated to what a small operator can actually subscribe to and ingest; institutional feeds with single-millisecond latency are a different game.
| Source channel | Latency to bot | False-positive rate | Coverage | Cost per month | Recommended |
|---|---|---|---|---|---|
| AP / Reuters wire | 200–600 ms | very low | narrow (major events) | $400–$1500 | yes, if budget allows |
| Reuters / BBC RSS | 3–15 s | low | broad | free | baseline, never primary |
| Official press feeds (gov, court, central bank) | 0–3 s | very low | narrow per feed | free | yes, per market |
| Twitter / X firehose (filtered) | 100–800 ms | high | broad | $100–$5000 | only with strong filter |
| On-chain oracle update | 500–2000 ms | very low | narrow (specific markets) | RPC cost only | yes, where applicable |
The pragmatic stack for a retail builder is the free RSS feeds as a wide net, one or two official press feeds for the markets the bot specifically targets, and a tightly filtered Twitter listener for early signal on breaking events. The wire-service subscription is the upgrade that justifies itself once the bot is consistently profitable at smaller size; below that, the fixed cost eats the edge. A useful free reference for the breadth of RSS coverage is the Reuters newsroom, whose top-stories feed is one of the cleanest wide-coverage sources publicly available.
The latency budget from event to fill
The end-to-end latency budget for a spike bot is short but it is not zero. Time accumulates across six stages and a builder who has not measured each one will lose to a builder who has. The numbers below are from instrumenting a Python spike bot running on a small cloud instance in the same region as the Polymarket gateway.
- Event to source feed: 50–500 ms. The interval between the world event and the moment the headline is published on the chosen feed. This is outside the bot's control; the choice of source is the only lever.
- Feed to listener: 30–200 ms. Network latency from the feed origin to the bot's listener process. Co-location matters more here than most builders think.
- Listener to classifier: 5–30 ms. Parsing the headline, matching it against a market keyword index, and producing a candidate signal.
- Classifier to signed order: 20–60 ms. Building the EIP-712 order payload and signing it. Pre-warmed signers and cached nonces help here.
- Order submission: 80–250 ms. HTTPS round-trip to the CLOB endpoint, plus the gateway's internal queueing.
- Fill confirmation: 200–1500 ms. Time until the bot knows whether the order matched the book.
A well-engineered Python spike bot operates inside roughly 400 to 1200 milliseconds from feed event to submitted order, with confirmation arriving inside two seconds. That sounds fast but the relevant comparison is to the other bots scanning the same headlines: a Rust bot in the same region can be at 150 to 400 milliseconds. The retail Python build does not win the race against a serious institutional bot; it wins the race against humans and against other Python bots that have not done the latency homework. The same general timing logic applies to the trading bot covered in the how to build a Polymarket trading bot tutorial, but the budget here is much tighter because the edge decays over seconds rather than minutes.
The shape of a spike: overshoot then fade
Empirically, the price reaction to a clean news event on Polymarket follows a recognisable three-phase shape. Understanding that shape is what separates a profitable spike bot from one that buys late and holds through the fade.
Polymarket spike — price reaction phases for a news-driven move
The first-mover window is short, often under a second for a major headline. Inside that window the bot is mostly trading against stale resting orders left by humans and slow bots. The crowded zone is where other spike bots arrive; here the book gets aggressive, the spread widens, and several bots are buying simultaneously. The overshoot is the natural consequence of that crowd; the bots collectively pay more than the eventual fair value because each is willing to pay slightly above the previous tick. The fade then takes the price back toward whatever the consensus settlement implies, usually inside a few minutes.
Two practical conclusions follow. First, the bot should aim its fill at the first-mover window, not the crowded zone. A bot that consistently fills inside the overshoot is paying for the privilege of being late. Second, the bot should plan an exit before it ever fires the entry, because holding through the fade is a recipe for giving back the captured edge.
The detector logic
The detector is the function that turns a candidate headline into a trade signal. Its job is to be cheap, conservative, and consistent. Cheap because it runs on every event from every feed; conservative because a false positive costs real money; consistent because human-tweakable thresholds drift over time and degrade performance.
The core idea is a delta-over-rolling-window check with a cooldown and a size cap. The bot maintains a short rolling window of recent prices for each watched market. When a candidate headline arrives, the bot waits a configurable warm-up (typically 50 to 150 milliseconds) for the order book to start moving, then checks the delta. If the delta crosses a threshold and the bot is not in a cooldown for this market, it fires a sized order capped by a per-market and per-day budget.
# spike_detector.py — minimal Polymarket spike bot detector
import time
from collections import deque
from dataclasses import dataclass, field
@dataclass
class MarketState:
market_id: str
prices: deque = field(default_factory=lambda: deque(maxlen=64))
last_fire_ts: float = 0.0
day_spent: float = 0.0 # USDC notional fired today
DELTA_THRESHOLD = 0.04 # 4 cents move within window
WINDOW_SEC = 2.0 # rolling window length
COOLDOWN_SEC = 90.0 # one fire per market per cooldown
MAX_PER_MARKET = 500.0 # USDC per market per day
MAX_PER_FIRE = 250.0 # USDC per individual order
def consider_fire(state: MarketState, now: float, mid_price: float, signal_strength: float):
state.prices.append((now, mid_price))
# in cooldown?
if now - state.last_fire_ts < COOLDOWN_SEC:
return None
# rolling window delta
window_start = now - WINDOW_SEC
old = [p for (t, p) in state.prices if t >= window_start]
if len(old) < 2:
return None
delta = old[-1] - old[0]
if abs(delta) < DELTA_THRESHOLD:
return None
# size cap
remaining = MAX_PER_MARKET - state.day_spent
if remaining <= 0:
return None
size = min(MAX_PER_FIRE, remaining, MAX_PER_FIRE * signal_strength)
# record fire intent
state.last_fire_ts = now
state.day_spent += size
side = "BUY" if delta > 0 else "SELL"
return {"side": side, "size_usdc": size, "ref_price": mid_price}
Several things in that function are doing real work. The cooldown prevents the bot from firing repeatedly on the same news as the price oscillates inside the crowded zone; without it, the bot will rebuy at the overshoot peak and lose money. The per-market daily cap is the absolute limit on damage from a misclassified or stale news event. The signal-strength scaling lets the classifier express confidence by reducing size on ambiguous signals rather than abstaining entirely; in practice a 0.3 confidence on a wide news net often produces a small profitable order that a binary fire-or-skip rule would have missed.
The detector is intentionally not where the headline-to-market matching happens. That logic lives in a separate classifier that maintains an inverted index from keyword to market and produces a candidate signal with a confidence score. Keeping the two concerns separate makes both testable. The matching layer often shares structure with the order-book reading logic described in the Polymarket order book explained piece, because both ultimately depend on the same cached market metadata.
Position sizing and cooldown
Position sizing on a spike bot is a different exercise from sizing on a market-making or copy-trading bot. The bet is short-duration, the variance is high per fire, and the bot has limited control over fill price. The right framework is fraction-of-bankroll with an explicit per-day variance cap rather than the long-horizon Kelly logic used for slower strategies.
A workable retail sizing rule is one to three percent of trading bankroll per individual fire, with a daily ceiling of fifteen to twenty percent across all fires combined. The per-fire cap controls single-event blow-up risk; the daily cap controls the situation where a noisy news day produces a dozen fires in close succession. A bot that hits its daily cap should refuse to fire for the rest of the calendar day even if a textbook signal arrives.
The cooldown logic deserves its own paragraph because it is the single most common place where retail spike bots fail. Without a cooldown, the bot will fire on the initial spike, then re-fire on the overshoot peak, then re-fire on the small bounce inside the fade, accumulating a position that averages up into the worst part of the price action. With a generous cooldown (60 to 120 seconds per market is reasonable for a first build), the bot fires once on the initial move and then watches. The cost of being too conservative on cooldown is missing a few legitimate re-entries; the cost of being too aggressive is a slow bleed that is hard to attribute. Err on the side of conservative.
Exit logic is the often-skipped half of sizing. A spike bot should pre-plan its exit before sending the entry, either as a fixed-time exit (sell at market after 90 seconds), a fixed-target exit (sell when unrealised gain exceeds 2.5 cents per share), or a hybrid. The fade is the reason: a position held into the settlement crawl gives back most of the captured edge. A simple time-based exit usually beats nothing, and it is much easier to reason about during a debugging session than a moving-average rule.
Crowding: why the edge decays as more bots join
The honest section. Spike-bot edge is not a static resource; it decays as more bots compete for it. The mechanism is mechanical. When one bot is fast enough to fill at the pre-news price and three other bots are not, the one bot captures the entire pre-news spread. When five bots are fast enough, they bid each other up inside the first second, and the realised fill price is closer to the eventual settle than to the pre-news price. The edge is what is left of the spread after all the fast bots have eaten their share.
In practice the decay shows up two ways. Day to day, a market that nobody else is watching can yield several cents of edge per spike for weeks; once a couple of other operators discover it, the edge falls to half a cent or less inside a few sessions. Within a single event, the first bot to fire collects the most edge, the second collects a smaller share, and the fifth often collects nothing or a small loss. The bot whose latency budget puts it outside the first-mover window will reliably fill inside the crowded zone and accumulate small losses that look like noise until they aggregate to a real drawdown.
The implication for a retail build is unambiguous: pick markets that other bots are not yet running on, accept that successful markets will degrade, and rotate. A spike bot that runs the same five markets for a year will probably end the year worse than a bot that quietly rotates through twenty markets and exits each when the edge thins. The same crowding logic plays out across the broader bot ecosystem; the trading bots covered in the build tutorial face an analogous decay on the strategies they target, although on slower timescales.
Failure modes and honest expectations
A spike bot has a small set of recurring failure modes. Each is mechanical, each is fixable, and each has cost a builder real money the first time they encountered it.
False positives on headline keywords. A keyword match between a news headline and a market name does not guarantee the headline is about the market's resolution event. A market on whether a named politician will win an election will keyword-match every routine headline about that politician. The classifier has to filter on event type as well as entity, and the filter has to be conservative. A useful discipline is to log every fire with the matching headline and review weekly; obvious false positives produce visible patterns within a few days.
Stale rolling-window prices. If the websocket connection drops and reconnects, the rolling window may contain mixed pre- and post-event prices. The detector will then see a phantom delta on the next event and fire incorrectly. Tag every price in the window with a freshness flag and treat any discontinuity in the timestamp sequence as a reason to flush the window and wait.
Gas spikes during congestion. The same Polygon-gas pitfall that hurts arbitrage bots also hurts spike bots: when network congestion drives gas higher, the implicit cost per trade rises and small-edge fires turn into losses. The bot should check current gas before submitting and abort if it exceeds a per-market ceiling. The full treatment of gas economics is in the Polymarket gas-fees explainer.
Cooldown bypass on multi-market events. A single news event can move several related markets. A naive cooldown that is keyed on market identity will allow the bot to fire on every related market in sequence, racking up correlated risk that looks like five independent positions but is really one. Add a per-event cooldown that recognises related markets via a tag on the news classifier.
Resolution-time confusion. Some news events are decisive; others are ambiguous and only resolve the market days later. A bot that fires on the first kind and the second kind with the same sizing rule will overpay for variance on the ambiguous events. The classifier should carry a resolution-time estimate per signal, and the sizing layer should scale down on long-tail events. The general market-timing context is mapped in the resolution-time guide.
Honest expectations. A retail Python spike bot built carefully and run on a curated handful of markets can return a few percent monthly on deployed capital in the right markets, in months when the news flow contains the events the bot is tuned for. It will lose money in quiet weeks because the fixed costs (data feeds, hosting, idle gas) keep ticking. It will lose money on weeks when a news event was misclassified or the bot was caught inside the fade. Net of those, the realistic return for a competent retail build is roughly comparable to a well-run arbitrage bot at similar size, with higher variance and lower mean. It is not a get-rich-quick strategy and it is not a substitute for a diversified bot stack; it is one credible tool in that stack, and a satisfying engineering project in its own right.
About the author
Jamal Okafor is an execution engineer on the Poly Syncer team. He spends most of his time on low-latency order routing and cross-venue plumbing, and the rest of it patiently walking newer builders through the first ten percent of any new bot project, because that is where the costly habits get set.
Frequently asked questions
How fast does a Polymarket spike bot need to be?
A retail Python spike bot should aim for under 1.2 seconds from news event to submitted order, with under 2 seconds to fill confirmation. That is slow compared to institutional Rust bots in the same data centre as the gateway, but fast enough to beat human traders and most other Python builds. The binding metric is p99 latency on the slowest stage; a bot whose mean is 600 ms but whose p99 is 4 seconds will lose to a bot whose mean is 900 ms and p99 is 1.5 seconds.
Which news sources should a beginner spike bot use?
Start with free Reuters and BBC RSS feeds as a wide net, add one or two official press feeds for the specific markets the bot targets, and add a tightly filtered Twitter listener once the rest of the bot is working. A paid wire-service subscription becomes worthwhile only after the bot is consistently profitable at smaller size; the fixed monthly cost otherwise eats the edge.
Does the spike bot need a separate exit strategy?
Yes. The price reaction to a clean news event overshoots then partially fades, so a position held past the crowded zone usually gives back most of the captured edge. Plan the exit before sending the entry: either a fixed-time exit (sell at market after 60 to 120 seconds), a fixed-target exit (sell when the unrealised gain exceeds a threshold), or a hybrid. A bot with no exit logic is effectively betting that the news will continue moving the market in its favour, which is not the bet the entry signal expressed.
How does the edge change as more spike bots enter the same market?
It compresses, often by half within a few sessions and toward zero within weeks. The first fast bot in a market captures most of the available spread; later entrants split what is left and frequently fill inside the overshoot rather than the first-mover window. The practical response is to rotate markets, accept that successful markets will degrade, and avoid the assumption that an edge that was real last month is still real this month.
Can a spike bot be combined with an arbitrage or copy-trade bot?
Yes, and most production bot stacks do exactly that. The spike bot adds short-duration directional fires on news events; the arbitrage bot captures structural mispricings; the copy-trader follows leader wallets on slower timescales. The three strategies have largely independent return drivers and combining them reduces overall variance. The sizing logic should treat them as separate budgets so that a bad day in one does not starve capital from the others.