Polymarket Arbitrage Bot: Finding Cross-Platform Edge

What Is Prediction Market Arbitrage?

Arbitrage is one of the oldest ideas in finance: when the same asset trades at different prices on two separate venues, you can buy it at the lower price and simultaneously sell it at the higher price, locking in a risk-free profit equal to the spread. In theory, arbitrage opportunities are fleeting — the act of exploiting them narrows the gap until it disappears. In practice, frictions slow this convergence and create windows during which a fast, well-equipped trader can capture real edge.

In prediction markets, arbitrage takes on a specific and interesting shape. The asset being priced is not a stock or a commodity but a probability — the market's collective estimate of whether a given event will occur. When two separate prediction market platforms price the same event at meaningfully different probabilities, an arbitrage opportunity exists. If Polymarket has "Will the Federal Reserve cut rates at the next meeting?" trading at 0.60 and Kalshi has the identical contract trading at 0.68, those eight cents represent a structural mispricing that a fast system can exploit.

The mechanics are straightforward in principle. You buy the YES contract on Polymarket at 0.60 and simultaneously sell — or buy NO on — the equivalent Kalshi market at 0.68. If the event resolves YES, you collect $1.00 on your Polymarket position and pay $1.00 on your Kalshi position: net zero on resolution, but you entered the combined position for a net credit of approximately $0.08 per share. If the event resolves NO, you collect $0.00 on Polymarket and $0.00 on Kalshi, but your net entry credit remains. Either way, you profit by the spread at entry, minus transaction costs.

In reality, the strategy is more complex. The two contracts may not be perfectly identical. Liquidity may prevent you from filling the full desired size at the quoted price. Transaction costs on both legs eat into the spread. And the window during which the discrepancy exists may be measured in seconds rather than minutes. These complications are precisely why a Polymarket arbitrage bot — a purpose-built automated system — is the practical tool of choice for anyone pursuing this strategy seriously.

Pure Arb vs Statistical Arb

It is worth distinguishing two related strategies that often get grouped under the arbitrage label. Pure arbitrage — the textbook version — involves genuinely equivalent contracts on two platforms, simultaneously entered, with locked-in profit regardless of resolution. This is rare in prediction markets because true contract equivalence is unusual and execution constraints make simultaneous entry difficult.

Statistical arbitrage is the more common and more practical form. Here, you are not seeking guaranteed profit regardless of outcome. Instead, you are identifying systematic mispricings — situations where one platform's market consistently lags another in incorporating new information, or where liquidity conditions create temporary price dislocations that a faster, better-informed participant can exploit. The edge is probabilistic rather than certain, but it is real and persistent for traders with the right infrastructure.

How Polymarket Arbitrage Bots Work

A Polymarket arbitrage bot is a software system that continuously monitors price feeds across multiple prediction market platforms, detects pricing discrepancies above a minimum threshold, evaluates whether the discrepancy is large enough to be profitable after costs, and executes trades on one or both platforms before the gap closes. Each of these steps requires specific engineering decisions that determine how effective the bot ultimately is.

Continuous Price Feed Monitoring

The bot must maintain a real-time picture of prices across all markets it is tracking, on all platforms it covers. This means maintaining live connections to each platform's API, parsing incoming price updates, and storing the current best-bid and best-ask for every market of interest. The latency of this monitoring layer is critical — a price feed that is 500 milliseconds stale may already have missed the opportunity by the time detection logic runs.

For Polymarket specifically, prices can be pulled directly from the on-chain order book state or from Polymarket's own API endpoints, which aggregate order book data. On-chain monitoring is slower in raw terms but more reliable; API monitoring is faster but subject to rate limits and potential data quality issues. Most professional systems maintain both channels and cross-validate them in real time.

Discrepancy Detection and Filtering

Not every price difference between platforms is an actionable arbitrage opportunity. Some reflect genuine contract differences — different resolution criteria, different counterparty risk, different settlement timelines. Others are below the minimum threshold needed to cover transaction costs on both legs. And some are artefacts of stale data on one side of the comparison.

The detection layer must filter these noise signals out and flag only genuine, cost-justified discrepancies. This requires knowing the exact transaction cost structure for each platform — fee rates, gas costs for on-chain execution — the minimum spread needed to generate positive expected value after costs, and the historical pattern of price differences between specific platform pairs for specific market types.

Execution on Both Legs

Once a genuine opportunity is identified, the bot must execute on both sides — or at least on the more mispriced side — before the gap closes. The execution challenge is that the two platforms have very different technical architectures. Polymarket uses on-chain order books on Polygon, meaning every trade is a blockchain transaction. Kalshi operates through a traditional off-chain matching engine with a REST API. Executing simultaneously on both requires two entirely separate execution pipelines running in parallel, with coordination logic to prevent partial fills that leave the combined position unhedged.

For a thorough breakdown of what these execution pipelines look like under the hood, the article on automated trading bots for prediction markets covers the full technical architecture in detail.

Cross-Platform Arbitrage Opportunities

The prediction market landscape has matured substantially, with several platforms now carrying enough liquidity to support meaningful arbitrage activity. The most relevant pairing for most traders is Polymarket versus Kalshi, though Metaculus and other platforms create additional opportunities in specific market categories.

Polymarket vs Kalshi

Polymarket and Kalshi frequently price the same macro events — Federal Reserve decisions, election outcomes, economic data releases — with discrepancies that can reach three to eight cents on liquid markets and substantially more on thinner ones. The primary source of these discrepancies is the difference in participant composition between the two platforms. Polymarket has historically attracted a more internationally diverse, crypto-native user base. Kalshi, operating as a regulated US exchange, draws more traditional finance participants. When a piece of information is more quickly incorporated by one community than the other, a temporary pricing gap appears.

Liquidity differences between the platforms also create arbitrage-adjacent opportunities. A large order on Polymarket that moves the local price substantially may create a gap relative to Kalshi's more liquid book, which absorbs similar-sized orders with less price impact. A bot monitoring both sides can identify when Polymarket's price has moved away from Kalshi's fair value and take a position that profits when it reverts.

Polymarket vs Metaculus

Metaculus operates on a fundamentally different model — it is a forecasting platform rather than a financial exchange, and its "prices" are community probability estimates rather than traded market prices. This means direct financial arbitrage between Polymarket and Metaculus is not possible in the traditional sense. However, Metaculus community forecasts — which aggregate the views of a large, historically well-calibrated forecasting community — frequently diverge from Polymarket market prices in ways that create statistical edge rather than pure arbitrage.

When Metaculus community consensus is substantially different from the Polymarket price for the same event, this is a signal worth taking seriously. Metaculus forecasters have strong track records on geopolitical, scientific, and long-horizon events — categories where Polymarket prices are sometimes driven more by attention and liquidity than by genuine probability assessment. A bot that monitors this divergence and flags it as a trading signal is adding real analytical value.

Intra-Platform Correlated Markets

Even within Polymarket alone, correlated markets can create pseudo-arbitrage opportunities. If "Will Party A win the presidency?" is trading at 0.55 and "Will the incumbent be re-elected?" is trading at 0.62 — and these are logically equivalent questions about the same election — the gap represents a mispricing that a careful bot can exploit. These intra-platform mispricings tend to be smaller but require no multi-platform execution complexity, making them attractive for bots that are not yet set up for cross-platform operation.

Technical Requirements for Arb Bots

Building a production-quality arbitrage bot for prediction markets is a significant engineering undertaking. The requirements span infrastructure, software architecture, and ongoing operational maintenance.

API Access and Rate Limits

Each platform you want to monitor requires API access. Polymarket's public API provides order book data, trade history, and market metadata. Kalshi's API requires registration and provides similar data through authenticated endpoints. Both APIs impose rate limits that constrain how frequently you can poll for price updates. A bot polling every 100 milliseconds will hit these limits quickly; a bot that uses WebSocket streaming where available — and falls back to efficient polling where not — can maintain near-real-time data at sustainable API usage levels.

Managing rate limits across multiple platforms simultaneously, while ensuring that any individual limit breach does not cascade into a data blackout on a platform where you hold an open position, requires careful implementation of back-off logic, connection pooling, and monitoring.

Latency Optimisation

For pure arbitrage, latency is everything. The window between a pricing discrepancy appearing and other bots closing it can be under one second for actively traded markets. Co-locating your bot's compute infrastructure near the relevant API endpoints — or as close to the Polygon RPC nodes as possible for on-chain execution — meaningfully reduces end-to-end latency. Cloud providers with data centres near the key infrastructure hubs used by prediction market platforms are preferable to running the bot on consumer hardware at home.

For statistical arbitrage strategies with slower-moving signals, the latency requirement is less extreme but still matters. Even a strategy with a 30-second signal window benefits from execution that happens in the first few seconds rather than the last few. Every millisecond saved at the detection and routing layer is a millisecond more of the available spread that you can capture.

Position and Capital Management

An arbitrage bot must track its open positions carefully across platforms to ensure the intended hedged structure is maintained. A partial fill on one leg that leaves the position unhedged is not an arbitrage — it is a directional bet. The capital management system must account for margin requirements on each platform, the cost of capital deployed in each open position, and the maximum total exposure across all open arbitrage pairs. Sophisticated systems also model the correlation between open positions — if you have fifteen positions on election-related markets that are all hedged across the same two platforms, a systemic issue affecting one platform affects all fifteen simultaneously.

Monitoring and Alerting

Automated systems fail in ways that manual traders do not. An API endpoint goes down. A WebSocket connection drops and reconnects silently. A transaction stalls in the mempool. A rate limit is hit and polling stops without notification. Each of these failure modes can leave positions in unexpected states. Production arbitrage bots require comprehensive monitoring — tracking the health of every data feed, the status of every pending transaction, and the consistency of the internal position state versus the actual on-chain state — with alerting that notifies operators of any anomaly within seconds.

Risks and Limitations of Arb Strategies

Prediction market arbitrage is not risk-free, and the risks it carries are different in character from the risks of directional trading. Understanding them is essential before deploying capital.

Slippage and Fill Risk

The price you see when you detect an opportunity is the last-traded price or the current best-offer. The price you actually fill at depends on the depth of the order book. If you want to buy 500 shares at 0.60 but the order book only has 100 shares available at that price, the remaining 400 shares fill at progressively worse prices — eroding or eliminating the theoretical profit from the spread. On thin markets, the effective fill price can be substantially worse than the quoted price, turning a nominally profitable opportunity into a loss.

Execution Leg Risk

In cross-platform arbitrage, you need to fill both legs of the trade — one on each platform — for the position to be properly hedged. If you fill the Polymarket leg but the Kalshi leg fails — due to rate limiting, API downtime, or insufficient liquidity — you are left with an unhedged directional position. This is the most dangerous failure mode in arbitrage, because you entered the trade expecting no directional risk and are now exposed to it. Robust bots handle this by monitoring fill confirmation on both legs and automatically unwinding the filled leg if the other fails to execute within a defined time window.

Resolution Differences

Perhaps the most underappreciated risk in prediction market arbitrage is resolution basis risk — the risk that two contracts that appear to be pricing the same event actually resolve differently due to differences in their resolution criteria. If Polymarket resolves a contract based on one data source and Kalshi resolves a nominally identical contract based on a different data source, the two contracts can have different outcomes on ambiguous events. An apparent arbitrage that locks in $0.07 of expected profit can turn into a $0.93 loss if one platform resolves YES and the other resolves NO for the same real-world event.

Mitigating this risk requires careful, manual review of the resolution criteria for every market pair before deploying capital. It cannot be automated away — it requires human judgment about the legal and procedural differences between platform resolution processes.

Liquidity Dry-Up Near Resolution

As a market approaches its resolution date, liquidity often declines sharply. The bid-ask spread widens, order book depth decreases, and the cost of entering or exiting positions increases. An arbitrage strategy that looked attractive based on current spreads may become difficult to unwind profitably if you need to exit before resolution. Planning position sizing with an eye to exit liquidity — not just entry liquidity — is an important discipline for arb traders.

Combining Arb with Conviction Scoring

Pure arbitrage and conviction-based copy trading might seem like entirely separate strategies, but they are more complementary than they first appear. Understanding how they interact opens up a more sophisticated approach to prediction market trading.

Conviction scoring — the systematic assessment of how strongly a high-quality wallet's entry signals a genuine probability edge — is primarily a tool for directional trading. When a wallet with a strong track record in political markets takes a large YES position on an election outcome, the Conviction Score measures how confident you should be that this represents informed, high-edge trading rather than noise.

The connection to arbitrage is this: when a high-conviction copy trading signal fires on Polymarket, it often represents information that has not yet been priced into other platforms. The wallet's entry moves the Polymarket price; Kalshi, Metaculus, and other platforms have not yet adjusted. The window between the Polymarket price moving and the other platforms catching up is a statistical arbitrage opportunity — and one with a stronger-than-usual edge because the signal behind the Polymarket price move has already been assessed as high-quality by the conviction scoring system.

In other words, conviction scoring can function as an early warning system for cross-platform mispricings, identifying opportunities before they are detectable through price comparison alone. A trader or bot that monitors both the copy trading signal feed and the cross-platform price differential can identify these opportunities at the moment of maximum edge — immediately after a high-conviction entry pushes the Polymarket price but before other platforms adjust.

For a detailed exploration of how conviction scoring and bot automation work together as a standalone strategy, the article on Polymarket trading bot automation vs manual trading covers the mechanics and performance data in depth.

Specula's Arb Scanner™ in Practice

Specula's Arb Scanner™ is a dedicated module within the platform that automates the cross-platform price monitoring and discrepancy detection process. Rather than requiring you to build and maintain your own API integrations and comparison logic, the Arb Scanner™ runs continuously across a curated set of market pairs and surfaces opportunities in a standardised, actionable format.

How the Arb Scanner™ Works

The scanner maintains live connections to Polymarket and Kalshi price feeds, normalising the market data into a common format that allows direct probability comparison. For every market pair in its watchlist — markets on both platforms that Specula has determined to be sufficiently similar for comparison — the scanner computes the current spread and flags any discrepancy above the minimum threshold needed to generate positive expected value after transaction costs.

Flagged opportunities appear in the Specula dashboard with the key parameters: the current price on each platform, the theoretical spread, the estimated cost of executing both legs, the expected net profit per share, the current order book depth on each side, and a risk assessment that highlights any resolution criteria differences between the two contracts. This information is structured to support a rapid go/no-go decision — or, for traders who have enabled automated execution, to trigger the bot's execution pipeline directly.

Integration with Conviction Scoring

When the Arb Scanner™ detects a discrepancy on a market where a high-conviction copy trading signal has recently fired, the opportunity is flagged with an enhanced signal indicator. This contextual overlay helps traders distinguish between discrepancies that are likely to close quickly — because they were created by a significant informed entry — and those that may persist longer because they reflect structural liquidity differences between the two platforms.

The distinction matters for execution strategy. A discrepancy created by an informed entry is likely to close within seconds as other bots and traders respond. Executing it requires maximum speed and pre-approved automation. A structural discrepancy may persist for minutes or longer and can be evaluated more carefully before execution.

Resolution Criteria Review Tools

Specula's Arb Scanner™ includes built-in resolution criteria comparison for every monitored market pair. Before flagging a discrepancy as actionable, the system checks its database of known resolution differences between platforms and surfaces any that are relevant to the specific market. Pairs where resolution criteria differences create material basis risk are flagged with warnings, allowing traders to make an informed decision about whether to proceed.

This is not a complete substitute for manual review — novel markets and edge cases will always require human judgment — but it substantially reduces the operational burden of resolution risk management for the majority of standard market types.

Getting Started with Arbitrage on Polymarket

If you are new to prediction market arbitrage, a staged approach — starting with observation and analysis before deploying capital — is strongly advisable. The strategy involves real complexity and meaningful risks that are best understood before real money is at stake.

Stage One: Paper Trading and Signal Observation

Begin by enabling the Arb Scanner™ and observing the opportunities it surfaces over several weeks without trading them. Note how often discrepancies appear, how large they are, how quickly they close, and what proportion would have been profitable after transaction costs. This observation period gives you a realistic picture of the opportunity set and helps you calibrate realistic performance expectations.

Pay particular attention to resolution risk during this period. Review the resolution criteria for every market pair the scanner flags and develop your own intuition for which pairs are genuinely equivalent and which have meaningful basis risk. This qualitative assessment cannot be automated and is one of the most important skills an arb trader develops over time.

Stage Two: Small-Scale Live Trading

Once you have a good understanding of the opportunity set, begin deploying small amounts of capital — a few hundred dollars per position maximum — to gain live experience with the execution dynamics. Pay attention to fill quality: are you consistently getting fills close to the quoted price, or is slippage eating into the theoretical edge? Are both legs filling reliably, or are you experiencing one-sided fills that leave you directionally exposed?

This stage is also where you refine the minimum spread threshold that makes sense for your cost structure. Theoretical profit calculations assume perfect fills at quoted prices; real-world trading involves slippage on both legs. Finding the threshold above which the strategy is consistently profitable after all costs is an empirical question that small-scale live testing answers better than any model.

Stage Three: Scaling with Automation

Once you have validated the strategy with real capital and have a clear sense of your effective edge after costs, you can begin scaling position sizes and enabling automated execution for the opportunity types you are most comfortable with. A Polymarket arbitrage bot operating through Specula's infrastructure can execute on discrepancies faster than manual entry allows, capturing more of the theoretical edge on fast-closing opportunities.

Scaling should be gradual and monitored carefully. As position sizes grow, slippage increases and market impact becomes a more significant factor. The edge that exists at $500 per position may be meaningfully smaller at $5,000 per position because your own orders begin moving the market. Tracking performance metrics carefully as you scale allows you to identify the point at which position size starts to reduce per-share returns.

For traders looking to understand the full spectrum of bot strategies available on Polymarket — from copy trading to statistical arbitrage — our guide on what a prediction market bot is and whether you need one provides a structured overview of the decision-making framework.