Building a Polymarket Kalshi Arbitrage Bot: The Reality of Execution

If you’re looking to capture inefficiencies between prediction markets, you’ve likely noticed the price discrepancies between Polymarket and Kalshi. While the theory of Polymarket Kalshi arbitrage sounds like a license to print money, the actual implementation is a brutal exercise in latency management and state synchronization. Most people assume it’s just about comparing two API endpoints, but if you treat it that way, you’ll get eaten alive by slippage and gas fees.

The core of a successful bot isn't just the spread calculation; it’s the timing. You aren't just trading prices; you are trading the delta between two different order book architectures. Polymarket uses a CLOB (Central Limit Order Book) on Polygon, while Kalshi operates its own proprietary matching engine. Your bot needs to bridge these two worlds using a robust stack—typically Node.js with TypeScript for type safety, and ethers.js to handle the heavy lifting of interacting with the Polygon chain.

Here is how the logic actually breaks down for a functional system:

1. Real-time Price Normalization: You must fetch prices from both APIs simultaneously. Don't rely on sequential requests; use Promise.all to minimize the time gap between your data points.
2. The "Late Resolution" Edge Case: This is where the real alpha hides. Sometimes, Kalshi settles a market while Polymarket’s liquidity remains active. If you can detect this state change before the rest of the market, you’re essentially buying a known outcome.
3. Configurable Spread Rules: Never hardcode your thresholds. Market volatility changes, and your MIN_SPREAD_CENTS needs to be adjustable via environment variables to account for changing gas costs on Polygon.

Here’s where most people get tripped up: they ignore the cooldown period. If you fire off orders every time the spread hits your target, you’ll end up paying more in transaction fees than you make in profit. You need a strict POLYMARKET_BUY_COOLDOWN_SECONDS to ensure you aren't over-trading in a choppy market.

That said, there’s a catch. Even with a perfect bot, you are at the mercy of the underlying chain. If the Polygon network experiences congestion, your transaction might sit in the mempool while the price moves against you. This is why you should always use a proxy wallet or a Gnosis Safe setup to manage your funds, rather than exposing your primary private key directly in your .env file.

This next part matters more than it looks: monitoring. You need a health check endpoint that reports not just the status of your bot, but the actual latency of your API calls. If your POLL_INTERVAL_MS is set to 5000ms but your API response time is 2000ms, you’re operating on stale data. Always log your round-trip times and kill the process if the data becomes too old to be actionable.

If you want to see how these components fit together in a production-ready codebase, check out this open-source implementation to understand the boilerplate. It provides a solid foundation for handling the CLOB interactions and the basic spread logic.

Ultimately, the goal of Polymarket Kalshi arbitrage is to minimize your exposure to directional risk while maximizing your capture of market inefficiencies. Start by running the bot in a dry-run mode to verify your spread logic against historical data before you ever commit real capital. Try this today and share what you find in the comments, or read our breakdown of automated market making strategies next.