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 built on Polygon where traders buy and sell shares in binary outcomes — YES or NO — on questions ranging from election results to cryptocurrency price targets to geopolitical events. Unlike traditional financial markets, prediction markets are structurally inefficient: they are often thinly traded, populated by retail participants who hold positions for narrative rather than probability reasons, and their prices can diverge significantly from implied probabilities derivable from external data sources.
Those inefficiencies are time-limited. As prediction markets mature and institutional participation increases, pricing converges and edge evaporates. The window to extract alpha from systematic strategies is narrow — which means the engineering question is not just "can we build strategies that work" but "can we build them fast enough, and run them reliably enough, to capture the edge that exists now."
The system had to do several things simultaneously: monitor external signals (on-chain Polygon activity and Binance price feeds), detect internal market mispricings, execute orders through the Polymarket CLOB API, manage positions across multiple concurrent open markets, and isolate each strategy's capital so a single bad trade couldn't affect the others. All of this in a single Python process with sub-second latency from signal to submitted order.
There was no off-the-shelf solution for any of it. Polymarket's CLOB API is relatively undocumented, the on-chain integration requires Polygon-specific wallet management and EIP-712 signature handling, and the strategy logic is proprietary by nature. The entire stack had to be built from scratch.
The Challenges
CLOB Authentication: EIP-712 at the Protocol Level
Polymarket's CLOB uses a two-layer authentication scheme: an API key (L1) combined with wallet-signed messages (L2) using EIP-712 typed data signatures. Getting the signature scheme exactly right — correct domain separator, correct field ordering, correct encoding — was non-trivial. A single byte off in the signature payload produces a silent auth failure with no useful error. The implementation had to match the protocol spec precisely, validated against Polymarket's own SDK source, before a single order could be placed.
Concurrent Strategy Execution Without Interference
Six strategies running simultaneously on overlapping markets creates a resource contention problem. Two strategies might independently decide to enter the same market at the same time — doubling intended exposure, triggering rate limits, or creating conflicting position signals. The async architecture needed a shared state layer that let strategies make independent decisions while preventing them from unknowingly stepping on each other's positions or exceeding market-level exposure limits.
Copy Trade Latency on Polygon Confirmed Blocks
Monitoring specific wallets on Polygon for copy-trade signals means choosing between two latency profiles: watch the mempool for pending transactions (faster, but the signal is unconfirmed and may never land), or watch confirmed blocks (slower, but reliable). For most Polymarket markets — which move on the timescale of hours or days, not seconds — post-confirmation monitoring was the correct tradeoff. The strategy was designed around the latency it actually had, not the latency it wished for.
Thin-Book Mispricing: Signal vs. Liquidity Constraint
A wide bid-ask spread on Polymarket can mean two very different things: the market is mispriced and represents a genuine edge, or the market is correctly priced but simply illiquid, and the spread reflects the cost of providing liquidity rather than a pricing error. Distinguishing between these two cases algorithmically — using order book depth, historical spread behavior, and implied probability consistency — was the core intellectual challenge of the thin-book strategy.
How It Works
Async Event Loop: One Process, Six Strategies
The entire engine runs in a single Python asyncio event loop. Each strategy is implemented as an async coroutine with its own lifecycle — startup, signal polling, order execution, and position monitoring — running concurrently without blocking the others. A shared state manager tracks open positions, pending orders, and per-strategy capital allocation across the full portfolio. This architecture keeps latency low and resource usage minimal while allowing strategies to coexist without coordination overhead.
Copy Trade: On-Chain Wallet Monitoring
The copy-trade strategy monitors a set of target wallet addresses on Polygon, tracking their Polymarket positions by parsing on-chain transaction data from confirmed blocks. When a target wallet enters a new position, the system mirrors that trade at the CLOB level — submitting a corresponding order within seconds of the confirmed transaction. The strategy targets markets where the relevant signal horizon is measured in hours, not seconds, making post-confirmation latency an acceptable tradeoff for signal reliability over mempool speculation.
Binance Correlation: Price Movement as Prediction Signal
Large directional moves on Binance — significant BTC or ETH price changes or liquidation cascades — are correlated with resolution probabilities on a subset of Polymarket questions (price-level markets, end-of-month targets). The Binance monitoring strategy subscribes to price feeds, detects qualifying moves above a configured threshold, identifies the set of affected Polymarket markets, and enters positions that reflect the updated implied probability. Position sizing accounts for correlation strength and time remaining to market resolution.
Internal Arbitrage: YES + NO < $1.00
Every Polymarket binary market has a theoretical constraint: the price of YES shares plus the price of NO shares must equal $1.00. When liquidity is fragmented or temporarily dislocated, this constraint can break down — creating an arbitrage opportunity where buying both YES and NO at their current prices produces a payout greater than the cost. The arbitrage scanner monitors active markets continuously, calculates the sum of best ask prices for both outcomes, and enters both legs when a qualifying gap appears. Execution risk — the gap closing between the first and second leg — is factored into the minimum qualifying spread.
Order Book Microstructure Strategies
Four strategies target order book dynamics directly. The momentum strategy identifies markets showing consistent directional price movement and enters in the direction of the trend. The mean-reversion strategy enters against large temporary dislocations from a market's recent price history. The volume-spike strategy uses abnormal order flow as a leading indicator of imminent price movement. The thin-book strategy detects markets where the bid-ask spread implies a probability distribution inconsistent with available external information — entering the more accurately-priced side and waiting for convergence.
Per-Strategy Risk Budgets
Each strategy operates with an isolated capital allocation. A losing run on one strategy does not reduce the capital available to others — there is no shared drawdown that degrades the entire system. Position sizing within each strategy is calibrated to its historical signal reliability and market liquidity profile. Global constraints cap total exposure per market regardless of how many strategies have independently decided to enter it, preventing concentration risk from correlated strategy decisions firing simultaneously.
Build Phases
The system was built in three sequential phases. Each phase delivered a working, deployed engine before the next strategy layer was added — allowing live validation of the core architecture before expanding scope.
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 specifically, and not a centralized exchange?
Polymarket is structurally less efficient than established crypto exchanges. Its participant base is largely retail, markets are thinly traded, and pricing can diverge meaningfully from implied probabilities derivable from external data. That inefficiency is the edge. Centralized exchanges are deeply liquid and heavily arbitraged — the systematic alpha window is narrower and requires much greater capital to access competitively.
How does copy-trade work without access to other traders' private strategies?
Every trade on Polymarket is an on-chain transaction on Polygon. Wallet addresses are public, and the assets they hold are visible in real time. By monitoring a set of wallets whose historical trading patterns suggest genuine informational edge — not just variance — the system mirrors their entries at the CLOB level within seconds of a confirmed transaction. No proprietary information is required; the blockchain is a public, auditable record of every position taken.
Is the internal YES+NO arbitrage actually risk-free?
In theory, yes — if both legs fill simultaneously at their quoted prices. In practice, the risk is execution: Polymarket's CLOB does not support atomic multi-leg orders, so the two legs are submitted sequentially. If the first leg fills but the second does not — because the market moved between submissions — the position is no longer arbitrage. The strategy only enters when the pricing gap is large enough to remain profitable even if the second leg fills at a degraded price.
What kind of operations benefit most from a custom trading system like this?
Any operation that has developed proprietary trading signals but lacks the infrastructure to execute on them reliably at scale. The system is not the strategy — it is the infrastructure that lets strategies run, be tested, and be iterated on without rebuilding the execution layer each time. For trading operations where the bottleneck is not ideas but execution reliability and operational overhead, a custom async engine with a proper risk layer is the right tool.
Can this be adapted for other prediction markets or asset classes?
Yes, with bounded engineering work. The core architecture — async strategy execution, shared state, risk budgets, order lifecycle management — is not Polymarket-specific. The CLOB integration and on-chain components are. Adapting to another prediction market (Kalshi, Manifold, Limitless) requires replacing the integration layer while keeping the strategy and risk framework intact. Adapting to a different asset class requires a full API and data integration rebuild, but the structural patterns transfer directly.
Custom Automation for Complex, Data-Intensive Workflows
Algorithmic trading is one example of a domain where off-the-shelf tools stop at the boundary of what's generic and the real value begins. If your operation depends on custom signal logic, proprietary data sources, or multi-system orchestration that no existing product handles, we design and build the infrastructure that makes it reliable, auditable, and scalable.
Get in touch →