Polymarket Market-Making Bots: Quoting Both Sides of YES/NO
A technical breakdown of how market-making bots quote binary outcome shares on Polymarket's CLOB, manage inventory skew, and protect P&L through resolution.
Polymarket's Central Limit Order Book gives sophisticated participants something most prediction markets never offered: a real exchange-style venue where you can post resting limit orders on binary outcome tokens. That means a properly built polymarket market making bot can earn the bid-ask spread continuously — but the mechanics are genuinely different from perpetual futures or spot markets, and ignoring those differences is how bots bleed out quietly before resolution day.
How the CLOB Works for Binary Shares
Every Polymarket market resolves to $1.00 (YES wins) or $0.00 (NO wins). Each side is a fungible ERC-1155 token on Polygon; one YES share plus one NO share always equals exactly $1.00 USDC. This creates a hard constraint the market maker exploits: if YES is quoted at 0.62/0.64, then fair NO is implicitly 0.36/0.38. You can post both sides simultaneously and collect the spread on whichever leg gets hit.
The CLOB itself matches on price-time priority. Resting orders sit in the book; the bot's edge comes from quoting tighter than the natural spread while staying wide enough to cover:
- Gas and protocol fees — Polygon L2 keeps gas manageable, but order cancellations and replacements still cost gas. High-churn quoting eats margin fast.
- Adverse selection — informed traders hit your stale quote the moment news breaks. Latency matters; streaming book updates via Polymarket's WebSocket feed and reacting in under 100 ms is table stakes.
- Inventory accumulation — you will get lifted on one side. As your YES inventory grows, your fair-value estimate needs to skew.
Midpoint Quoting and Inventory Skew
The baseline logic is simple: observe the best bid and ask, compute a midpoint, then post bids some delta below and offers some delta above. A naive bot posts symmetrically. A real one adjusts that midpoint continuously based on inventory.
Define q as your current net long position (positive = long YES, negative = long NO, normalized to ±1 across your position limit). The skewed midpoint becomes:
mid_skewed = mid_fair - γ × q × σ²
Where γ is an inventory risk-aversion parameter and σ² approximates the variance of the outcome probability — which for binary markets is simply p × (1 − p). When probability is near 0.5 the market is maximally uncertain and you naturally widen quotes; near 95/5 splits the book is illiquid and you should either widen significantly or step back entirely.
Practically, your bot should:
- Pull the Gamma CLOB REST snapshot on startup and subscribe to the Level 2 WebSocket stream for real-time deltas.
- Maintain a local order book mirror to compute your own mid without depending on the API lag.
- On each fill event, recompute
q, recalculatemid_skewed, cancel stale orders via the REST cancel endpoint, and post new orders — all within a single event-loop tick where possible. - Implement a kill-switch that halts all quoting when
|q|exceeds your max inventory threshold, or when the raw market probability moves more than N basis points in a configurable window (a signal of breaking news).
See how we applied similar inventory-skew logic at the venue level in the Hyperliquid market maker case study — many of the same risk controls translate directly.
Resolution Risk and Pre-Resolution Wind-Down
Binary outcome tokens have a cliff at resolution: a 0.64 YES token either becomes $1.00 or $0.00. Within the final hours before a scheduled resolution, fair value is almost entirely event-driven, not liquidity-driven. A market-making bot must wind down inventory well before the resolution timestamp or accept the directional exposure knowingly.
Build a time-to-resolution decay function that reduces your max inventory limit linearly (or exponentially) as the market approaches its end time. At T-minus four hours, your position cap might drop to 25% of normal. At T-minus one hour, quoting stops entirely. This is not optional; it is what separates a profitable strategy from a bot that gets stuck holding a one-sided position into a coin flip.
Anti-rug simulation is equally important during setup: before any live quoting, run your bot against a full historical order stream in simulation mode, verify P&L attribution separates spread capture from directional inventory bets, and confirm the kill-switch fires correctly on synthetic adverse-selection events.
Infrastructure Considerations
Unlike on-chain DEX strategies where Jito bundles and priority fees are central to execution, Polymarket's CLOB is off-chain order matching with on-chain settlement. The latency game here is API latency, not block-inclusion latency. That said:
- Colocate or at least choose a cloud region that minimises round-trip to Polymarket's matching engine.
- Deduplicate WebSocket reconnections — a dropped connection during active quoting leaves stale orders in the book unhedged.
- USDC collateral sits on Polygon; monitor your wallet balance and margin utilisation separately from your P&L tracker.
Our trading-bot services cover the full stack: strategy design, infrastructure, monitoring dashboards, and kill-switch frameworks tuned to each venue's settlement model.
Getting to Profitable Quotes
The checklist for a production-ready Polymarket market-making bot comes down to: a calibrated mid with inventory skew, fast cancellation on adverse book moves, a time-aware position cap that winds down into resolution, and simulation testing before capital goes live. The spread on binary markets can be surprisingly wide on tail-probability events, which means well-calibrated quoting earns more than the equivalent vol surface on a perps venue — if the bot's risk engine keeps it out of trouble.
If you want a production market-making bot built to these specifications — with live monitoring, configurable risk parameters, and support across Polymarket, Hyperliquid, and Solana venues — start a project with TierZero and we will scope it out within 24 hours.
Need a bot like this built?
We design, build and run trading bots on Solana, Hyperliquid and Polymarket.
Start a projectMore from the blog
Public vs Paid RPC: How to Run a Fair Benchmark
A fair comparison of public and paid RPC endpoints must account for quotas, workload, freshness and support guarantees.
Read articleRPC Benchmark Percentiles Explained: p50, p95 and p99
Why averages hide the latency spikes that break trading bots, wallets and production blockchain applications.
Read articleHyperliquid REST vs WebSocket Benchmark: What to Measure
A benchmark plan for Hyperliquid market data that separates request latency from streaming freshness and recovery.
Read article