Case Study · Algorithmic Trading
Polymarket Bot
Six concurrent trading strategies, one unified risk layer — built to trade prediction markets at the protocol level
A custom algorithmic trading engine for Polymarket, a decentralized prediction market on Polygon. Six independent strategies — copy trade, internal arbitrage, Binance correlation, momentum, mean-reversion, and thin-book mispricing — run concurrently in a single async Python process with per-strategy bankroll isolation.
Written by Ing. Hlib Yarovyi, Founder · Published
Type
Internal Tool
Platform
Polymarket (Polygon)
Strategies
6 concurrent
Stack
Python · asyncio · CLOB SDK · Docker
Signal-to-order
< 1 second
The Problem
Polymarket is a decentralized prediction market on Polygon. Traders buy and sell YES or NO shares on questions like elections, crypto price levels, and geopolitical events.
Prediction markets are often inefficient. They are thinly traded, dominated by retail participants, and prices can drift far from real probabilities. That gap creates an opportunity — but only for a limited time. As markets mature, pricing tightens and the edge disappears.
The system needed to do several things at once:
- Monitor external signals: on-chain Polygon activity and Binance price feeds - Detect mispricings inside Polymarket itself - Execute orders through the Polymarket CLOB API - Manage positions across many concurrent markets - Keep each strategy's capital isolated so one bad trade couldn't hurt the others
All of this had to run in a single Python process with sub-second latency. No off-the-shelf tool handled any of it. The entire stack was built from scratch.
The Challenges
CLOB Authentication: EIP-712 at the Protocol Level
Polymarket's CLOB uses two-layer auth: an API key (L1) plus wallet-signed messages (L2) using EIP-712. Getting the signature exactly right was critical — a single byte off produces a silent failure with no useful error. The implementation was validated against Polymarket's own SDK before a single order could be placed.
Concurrent Strategy Execution Without Interference
Six strategies running at once on overlapping markets can conflict. Two strategies might enter the same market simultaneously — doubling exposure or triggering rate limits. A shared state layer was needed to let strategies act independently while preventing them from stepping on each other's positions.
Copy Trade Latency on Polygon
Watching wallets for copy-trade signals means choosing: monitor the mempool (fast, but unconfirmed) or confirmed blocks (slower, but reliable). Most Polymarket markets move over hours — not seconds — so confirmed-block monitoring was the right tradeoff. The strategy was designed around actual latency, not ideal latency.
Thin-Book Mispricing: Signal vs. Liquidity
A wide bid-ask spread can mean two things: the market is mispriced, or it is correctly priced but illiquid. Telling these apart requires order book depth, historical spread data, and implied probability checks. That distinction was the core challenge of the thin-book strategy.
How It Works
Async Event Loop: One Process, Six Strategies
The engine runs in a single Python asyncio event loop. Each strategy is an async coroutine with its own lifecycle: startup, signal polling, order execution, and position monitoring. A shared state manager tracks open positions and capital across all strategies. Latency stays low because nothing blocks anything else.
Copy Trade: On-Chain Wallet Monitoring
The copy-trade strategy watches target wallet addresses on Polygon. It parses confirmed on-chain transactions to detect new Polymarket positions. When a target wallet enters a position, the system mirrors the trade within seconds. It focuses on markets where signals play out over hours — making confirmed-block latency an acceptable tradeoff.
Binance Correlation: Price Movement as Signal
Large moves on Binance — BTC or ETH price swings, liquidation cascades — correlate with resolution probabilities on price-level Polymarket questions. The strategy watches Binance feeds, detects qualifying moves, identifies affected Polymarket markets, and enters positions reflecting the updated probability. Size is adjusted for correlation strength and time to resolution.
Internal Arbitrage: YES + NO < $1.00
In any binary Polymarket, YES + NO prices must equal $1.00. When liquidity fragments, this can break — creating an arbitrage where buying both sides costs less than the guaranteed payout. The scanner monitors active markets, checks best ask prices for both outcomes, and enters both legs when the gap qualifies. The minimum spread accounts for the risk that prices shift between the first and second leg.
Order Book Microstructure Strategies
Four strategies target order book dynamics directly: - **Momentum** — enters markets with consistent directional price movement - **Mean-reversion** — enters against large temporary dislocations - **Volume spike** — uses abnormal order flow as a leading indicator - **Thin-book** — detects markets where the bid-ask spread implies a probability inconsistent with external data, then enters the accurately-priced side
Per-Strategy Risk Budgets
Each strategy has its own isolated capital allocation. A losing run on one strategy does not reduce what is available to others. Position sizing is calibrated to each strategy's historical reliability and market liquidity. A global cap limits total exposure per market — no matter how many strategies independently decide to enter it at the same time.
Build Phases
The system was built in three phases. Each phase shipped a working, deployed engine before the next layer was added — so the core architecture was validated live before scope expanded.
Phase 1
Core Engine & Auth
Async Python architecture, Polymarket CLOB integration, EIP-712 L1/L2 signature implementation, order execution pipeline, Docker deployment, and basic position state tracking
Phase 2
Signal Strategies
Copy-trade via Polygon on-chain wallet monitoring, Binance price correlation strategy, and internal YES+NO arbitrage scanner — all running concurrently with the shared state manager
Phase 3
Microstructure Layer
Momentum, mean-reversion, volume-spike, and thin-book strategies; per-strategy risk budgets and portfolio-level market exposure controls finalized
System Performance
Strategies running concurrently in a single async process, each with isolated capital and independent signal logic
Signal-to-order latency from event detection to CLOB order submission across all strategy types
Uptime over the production period — the engine ran continuously through API disruptions and Polygon network congestion without manual intervention
Common Questions
Why Polymarket and not a centralized exchange?
Polymarket is less efficient than established crypto exchanges. Markets are thinly traded, participants are mostly retail, and prices often diverge from real probabilities. That gap is the edge. Centralized exchanges are deeply liquid and heavily arbitraged — the window for systematic profit is narrower and requires far more capital.
How does copy-trade work without access to other traders' strategies?
Every Polymarket trade is an on-chain transaction on Polygon. Wallet addresses are public. By monitoring wallets with a strong historical track record — not just lucky ones — the system mirrors their entries within seconds of a confirmed transaction. No private information is needed. The blockchain is a public record of every position.
Is the YES+NO arbitrage actually risk-free?
In theory, yes — if both legs fill at quoted prices. In practice, the risk is execution. Polymarket does not support atomic multi-leg orders, so legs are submitted one at a time. If the first fills but the second does not, the position is no longer arbitrage. The strategy only enters when the gap is wide enough to remain profitable even if the second leg fills at a worse price.
Who benefits most from a custom trading system like this?
Any operation with proprietary trading signals but no reliable infrastructure to act on them. The system is not the strategy — it is the execution layer that lets strategies run, be tested, and be improved without rebuilding from scratch each time. If the bottleneck is execution reliability rather than ideas, a custom async engine is the right tool.
Can this be adapted for other markets?
Yes. The core architecture — async execution, shared state, risk budgets, order lifecycle management — is not Polymarket-specific. Adapting to another prediction market (Kalshi, Manifold, Limitless) means replacing the integration layer while keeping the strategy framework intact. Adapting to a different asset class requires a full API rebuild, but the structural patterns transfer directly.
Custom Automation for Complex, Data-Intensive Workflows
Off-the-shelf tools stop where generic ends. If your operation depends on custom signal logic, proprietary data sources, or multi-system orchestration that no existing product handles, we build the infrastructure that makes it reliable, auditable, and scalable.
Get in touch →