Sub-Second Execution: Inside a Polymarket Trading Bot's Design
A deep look at a Polymarket bot's execution stack across 11,717 trades: signal generation, EIP-712 signing, CLOB API calls, and on-chain confirmation latency.
Building an automated trading bot for Polymarket, a blockchain-based prediction market, revealed that execution speed there is a fundamentally different problem than on centralized exchanges. Rather than chasing microsecond advantages, the developer of a bot with 11,717 executed trades breaks latency into four layers: signal generation (50-200ms), EIP-712 order signing (10-50ms), CLOB API submission (100-400ms), and on-chain confirmation on Polygon (1-3 seconds). The last layer is uncontrollable, so the design goal shifted to ensuring latency you can't eliminate doesn't cost you trades you should win.
A key design outcome is the 'T-90 rule' — halting new trades 90 seconds before market resolution. This isn't about signal decay but about buffering against worst-case cumulative latency across all four layers. The bot also relies almost exclusively on limit orders to avoid slippage in thin binary markets, cancels unfilled orders after 30 seconds without chasing, and uses Telegram trade alerts as a de facto latency monitoring tool by comparing entry and confirmation timestamps.
The reported numbers are instructive for engineers: average signal-to-confirmation time is around 280ms on good days and 600ms during network congestion, with roughly 4% of orders failing to fill within 30 seconds. The developer notes that chasing those unfilled orders with market orders would likely cost more in slippage than the missed winners were worth. Planned improvements include WebSocket-based order status updates, separating signal generation from execution to avoid event-loop contention, and regional failover for reliability — none critical at current volume, but increasingly relevant at scale.