Every five minutes, Polymarket lists a new question:
Will Bitcoin be higher at the end of this window than at the start?
You can buy Up or Down. One side pays $1. The other pays $0. The market resolves using Chainlink BTC/USD — not Coinbase, not Binance.
That last detail matters more than most people expect.
This post is a rough, developer-friendly overview of a spike bot we built to trade those windows. It explains the shape of the system — feeds, decision loop, risk, logging — without publishing the parts that actually make it work: momentum math, tuned parameters, hedge mechanics, or when we choose to run it.
Think of this as the architecture blog post, not the strategy leak.
Why these markets are interesting (and annoying)
Five-minute binary markets are a strange hybrid:
- They behave like options (probability priced between $0 and $1).
- They settle like oracles (Chainlink, on a schedule).
- They trade like retail sports books (fast repricing, thin books, emotional flow).
The friction creates opportunity — but only if your bot understands which price is authoritative and which price is merely early.
We run two price feeds in parallel:
| Feed | Role |
|---|---|
| Chainlink (via Polymarket RTDS) | Resolution price. Slow but official. |
| A fast exchange lead feed | Early warning. Moves before the oracle updates. |
The bot's thesis is simple to state and hard to execute:
When spot moves sharply, the prediction market sometimes lags. If you can detect the move early and buy the underpriced side before the book catches up, you have edge.
We call that a spike bot — not because it only trades violent moves, but because entries are triggered by short-term momentum events rather than a fixed countdown window.
System architecture (the boring, important part)
Most of the complexity lives in plumbing. The strategy is one module; the infrastructure is the product.
┌─────────────────┐ ┌──────────────────┐
│ Chainlink RTDS │ │ Lead exchange WS │
│ (oracle) │ │ (fast spot) │
└────────┬────────┘ └────────┬─────────┘
│ │
└───────────┬───────────┘
▼
┌─────────────┐
│ PriceSync │ gap, staleness, sync_ok
└──────┬──────┘
▼
┌─────────────┐
│FeatureEngine│ vol, model prob, book state
└──────┬──────┘
▼
┌─────────────┐
│ SpikeStrategy│ entries, optional hedge
└──────┬──────┘
▼
┌─────────────┐
│ Paper/Live │ simulated or real fills
│ Gateway │
└──────┬──────┘
▼
┌─────────────┐
│ SQLite + │ round trips, limit order
│ JSONL logs │ audit trail
└─────────────┘
Stack: Python 3.11+, asyncio, websockets, SQLite, FastAPI dashboard, Loguru.
Design choices we cared about:
-
Single-instance lock — one bot per machine; SQLite WAL +
fcntllock prevents double-trading. - Feed watchdogs — stale oracle, stale lead, stale Polymarket book → pause ticks, don't hallucinate signals.
- Gap awareness — Coinbase and Chainlink disagree constantly. The bot tracks gap size but treats extreme divergence differently from a genuine lead signal.
- Paper-first — same code path as live; fills simulated with latency and slippage models.
What the spike bot actually does (high level)
Active across the whole window
Older versions of our bot only traded a narrow slice of the five minutes (e.g. the last 30 seconds). The spike bot is active for the entire market lifecycle — from open to resolution.
That changes the game: you're not betting on "end-of-window chaos." You're watching for discrete momentum events whenever the book is still mispriced.
Underdog entries only
We only buy tokens trading below fair coin-flip territory (the underdog side). If Up is already priced at 80¢, we don't chase it — the asymmetry is gone.
Entries are limit orders capped at a maximum price. In paper mode we model this as: fill at the ask if it's below the cap; otherwise no fill.
No stop-loss, no take-profit
This surprises people.
The bot doesn't trail stops or scalp 10¢ moves. Positions are held to oracle resolution unless a separate protective mechanism triggers (more on that below, vaguely).
The bet is probabilistic: we believe the true win chance exceeds what we paid, given where spot just moved.
Gated entries (the part we won't document)
A raw momentum spike is not enough. Before any order, multiple internal gates must pass — things like:
- Is the spike statistically significant and economically meaningful?
- Is there enough time left for the order to fill and settle?
- Does a model-implied win probability exceed the ask plus friction?
- Is the strike price (window open BTC level) reliable?
- Is there enough liquidity on the ask side?
The exact formulas and thresholds are intentionally omitted from this post.
Momentum detection (public shape, private internals)
We detect momentum using the fast lead feed, not Chainlink.
At a high level:
- Sample spot price now vs spot price W milliseconds ago.
- Express the move in both absolute and volatility-normalized terms.
- If the move exceeds internal thresholds → classify as up-spike or down-spike.
What's private:
- The window length W
- How volatility is estimated
- The z-score / dollar thresholds
- How spike size is compared to distance from the market's strike price
Why keep it private? Because those four knobs are the entire frequency vs. precision tradeoff. Publish them and you publish the bot.
Win probability (what we can say)
Separate from spike detection, we maintain a model probability that Up resolves YES:
- Anchor: Chainlink vs strike (log-distance).
- Volatility scaled to time remaining.
- Optional adjustment when lead and oracle disagree (gap).
We only enter when p_win clears internal conviction and edge floors. Again: no numbers here.
Chainlink resolves the market. Coinbase tells you where Chainlink is probably heading. The model bridges the two.
Protective logic (hedge — details withheld)
Early tests showed that primary direction alone wasn't enough. Spot can spike, you buy Up, then spot reverses hard before resolution.
The bot includes a reversal response that attempts to neutralize risk when momentum flips against an open position. The economic idea:
In a binary market, Up + Down always pays exactly $1 combined. If you hold both sides cheaply enough, you can lock in a bounded outcome.
We do not publish:
- When the hedge arms
- What price cap we require for the opposite side
- How long we wait for a fill
- Share-matching rules
Suffice to say: it's not a classic stop-loss. It's a structural hedge tied to the binary payout math.
When the bot runs (schedule — details withheld)
Not all hours are equal. BTC volatility clusters. Polymarket liquidity varies. Hedge fills depend on the book staying two-sided.
We run an Eastern-time schedule that limits active trading to windows where backtests and paper sessions showed acceptable hit rate and hedge reliability. Outside those hours the process stays alive (feeds connected) but does not enter new markets.
The exact hours are proprietary. The pattern is not: don't burn edge in dead sessions.
Risk management (the non-sexy essentials)
Even a probability bot needs guardrails:
| Layer | What it does |
|---|---|
| Per-trade notional cap | Fixed dollar size per primary entry. |
| Per-market exposure cap | Limits total capital deployed in one 5-min window (primary + hedge room). |
| Equity floor | Stop entering if paper/live equity drops too far. |
| Feed kill | Manual KILL file + staleness recovery timers. |
| Gap halt (relaxed) | Extreme oracle-lead divergence can block entries — tuned so real lead spikes aren't accidentally filtered. |
Daily/hourly PnL halts were removed during paper calibration so we could observe true behavior over long sessions.
Observability: how we know what happened
If you can't audit orders, you can't tune a bot. We log:
-
bot.log— human-readable tick stream, feed health, entries/exits. -
limit_orders.jsonl— every limit push with timestamp, limit price, ask at push, fill outcome. -
limit_order_log(SQLite) — queryable order audit trail. -
paper_round_trips— full entry context frozen at signal time, closed at resolution. -
Dashboard API —
/api/limit_orders,/api/trades, livebot_status.json.
Paper trading isn't "hope and pray." It's a recording studio for strategy iteration.
What trading results taught me (results without cherry-picking)
- Hedge fill rate dominates outcomes. Sessions where every primary got hedged looked very different from sessions with unhedged -$10 resolution losses.
- Selectivity vs. activity. Tighter gates → fewer trades → higher average quality, but sample size shrinks fast on 5-min markets.
- Feed stability matters. RTDS reconnect churn and Coinbase staleness silently delete spikes you'd otherwise catch.
- Strike quality matters. Joining a market late with an approximate open price degrades distance-based gates.
What I'd tell another developer
If you're building something similar:
- Start with feeds, not signals. Spend a week just logging Chainlink, your lead feed, and Polymarket books in sync. You'll find bugs you didn't know existed.
- Treat resolution price as sacred. Every decision should know whether it's using oracle price or lead price — and why.
- Binary markets have binary arithmetic. Exploit the payout structure before reaching for stop-losses.
- Paper trade with audit logs. Not just PnL — log every limit push, blocked signal, and feed gap.
- Time-gate last. Schedule filters are optimization, not foundation. Get the core loop right first.
What's intentionally not in this post
To be explicit about what I am keeping private:
- Momentum calculation on the lead feed (window, normalization, thresholds)
- Exact parameter YAML values
- Hedge state machine and fill rules
- Optimal trading hours / timezone schedule
Closing thought
Polymarket's 5-minute BTC markets are a playground for latency-aware probability trading: oracle resolution, retail-priced tokens, and exchange spot that moves first.
A spike bot doesn't need to predict the next five minutes of Bitcoin. It needs to notice when the market hasn't yet priced in the last five seconds — and to survive when it's wrong.
If you're building in this space: respect the oracle, log everything, and paper trade until the logs bore you.
If you have more questions, please feel free to contact me at any time: https://t.me/FatherSon97
Tags: #python #trading #websocket #asyncio #fintech #polymarket #bot #polymarket trading bot #spikebot #polymarket trading
Top comments (13)
This is a new logic you implemented?
replied
plz check your TG 🙂
sure
new one but have been testing over 2 months
not paper or back test but real live test using real money
nowadays I can see that you are posting in multilanguages such as chinese and russian...
will you post a chinese version of this article kindly?
fasho
will do soon
thank you
what services are you using for machine to run bots?
which platforms are you using?
Please hit me up in dm via TG
how did you figure out latency issues?
tbh know-how 🙃
why you don't hit me up in telegram?
you are providing Polymarket trading bots?
if so, how can I test before purchase?
I can provide and set up with a call while sharing screens.
You can check PnL via my account and I can also share them while having a call.
I have read over 10s articles of yours
I send dm to your TG.
Hope to connect for your bot packs.
replied
plz check