Polymarket Kalshi Arbitrage Scanner (2026)

What is a Polymarket Kalshi arbitrage scanner?

It is a scanner built around one specific pair of venues. It continuously finds events listed on both Polymarket and Kalshi, aligns the outcomes and tests the two possible cross-venue combinations:

• Buy YES on Polymarket and buy NO on Kalshi.
• Buy YES on Kalshi and buy NO on Polymarket.

If the two contracts are equivalent, one side should settle at $1 per paired contract while the other settles at $0. A combined acquisition cost below $1 creates a gross difference. Whether that difference is usable depends on the live books, the size available, the fee schedules and the resolution match.

This is why a scanner needs more than a table of prices. The arithmetic takes one line. Establishing that the line describes a real pair takes most of the system.

Why can you not compare the displayed prices?

The number on a market card is often a midpoint or the last traded price. Neither is necessarily available now.

Suppose Polymarket displays 42 cents for YES and Kalshi displays 53 cents for NO. Adding those numbers gives 95 cents, which looks like a five-cent gross difference. But if the live asks are 45 cents and 56 cents, the two legs cost $1.01 before fees. The opportunity was created by the display, not the books.

A scanner therefore reads the asks directly and walks enough levels to fill the requested size. Ten contracts and one thousand contracts can receive different answers from the same pair because the larger order consumes more of the ladder.

How is the cross-venue calculation made?

For equivalent binary contracts, test both directions and keep the cheaper complete pair. Here is a hypothetical 100-contract example before fees.

The gross difference is $4.00, or four cents per pair. That is not the final result. The scanner still has to walk every required level, calculate both venues' applicable fees and confirm that the contract rules produce opposite outcomes in every relevant scenario.

How should the two markets be matched?

Similar wording is the starting point, not the verdict. The match needs four pieces of agreement.

Outcome. Both contracts must ask the same yes-or-no question. One cannot be a threshold while the other is a range or a different stage of the same event.

Cutoff. The deadlines must line up. A result known on Friday can differ from a result measured at month-end.

Settlement source. The official source used to resolve the contract should agree, or the rules must clearly lead to the same outcome.

Exceptional cases. Postponements, cancellations, recounts and replacement candidates can create different settlements even when the headlines look identical.

A scanner that cannot confirm the rule match should preserve the row as an indicative price difference. That keeps an interesting discrepancy visible without presenting it as a qualified trade.

What checks make an arbitrage row executable?

Predictefy applies every gate before its executable surface uses the arbitrage label.

Rows that miss a gate carry machine-readable reasons such as insufficient depth, a closed market, a synthetic book or unverified resolution equivalence. That makes the output useful for debugging and research without mixing it into the executable set.

How do you scan Polymarket and Kalshi with one API call?

Predictefy's router exposes the assessed cross-venue surface. The venue filter keeps rows touching Polymarket or Kalshi, while the contract count tells the engine how far to walk each book.

curl -s \
  "https://data.predictefy.com/api/router/fetchArbitrage?contracts=100&limit=100&executableOnly=true&venues=polymarket,kalshi&minEdge=0.02" \
  -H "Authorization: Bearer pk_live_YOUR_KEY"

For a continuously updating screen, the WebSocket uses the same filters:

{
  "op": "subscribeArbitrage",
  "executableOnly": true,
  "venues": ["polymarket", "kalshi"],
  "minEdge": 0.02
}

What does an empty scanner result mean?

It means no row passed the selected filters at that moment. That is a valid result, not a broken scanner.

There may be visible price differences whose books are too thin, whose fees consume the spread or whose rules are not equivalent. There may also be no difference above the chosen minimum edge. Lowering the threshold can expose more candidates, while removing executableOnly=true shows indicative rows with their rejection reasons.

The important distinction is between no candidate and no qualified result. A good scanner tells you which one occurred.

How should execution follow the scan?

Treat qualification and order placement as separate steps. Read the row, confirm the size and current timestamps, then build each venue leg against the exact market and outcome returned by the assessment.

Predictefy keeps signing client-side with your own venue credentials. Each venue order is explicit, and every write uses an idempotency key so retrying a request does not silently create a duplicate. Keeping the scan, build and submit steps distinct makes the state of both legs visible before funds move.

Frequently Asked Questions