How Much Money Can You Make from Prediction Market Arbitrage

The honest version of this question has two answers. The theoretical answer is that a two-leg pair costing 98¢ and paying 100¢ returns about 2% in the time it takes the market to resolve. The practical answer is that almost none of the gaps you see on a screen survive contact with a live order book.

How much money can you actually make from prediction market arbitrage?

About 2% net on a qualified pair, which is a few hundred dollars a month for most people and roughly 600 USD a month at the ceiling. The arithmetic is simple: you buy YES on one venue at 47¢ and NO on another at 51¢, the pair costs 98¢ and pays 100¢ at resolution provided both contracts resolve on identical criteria, and that 2.0% return on the 98¢ you committed is locked up until both markets settle.

Depth is what stops the number from growing. The books that carry a genuine gap are usually the ones that cannot absorb 500 USD without repricing, so extra bankroll does not raise the return, it sits idle.

Predictefy's execution service is sized to that reality: 100 USD per order and 1,000 USD per key per rolling 24 hours. Deploying the full 1,000 USD every day at a 2% net edge is 20 USD a day, roughly 600 USD a month. In a realistic week you will not find ten qualified pairs a day, so treat that as a ceiling and not a forecast.

Why does the arbitrage gap disappear when you try to trade it?

Because the gap was quoted between two midpoints and you have to pay two asks. A midpoint is the average of the best bid and the best ask, and nobody sells at it. Taking both sides of a pair means crossing half the spread on each leg, so a pair of median books costs you the full median spread.

A 4¢ gap on two typical books is not a small trade. It is a losing trade.

The 18.1% figure makes it worse. On nearly one in five live Kalshi markets there was no bid at all on 2026-09-03, so any scanner computing a midpoint on those books is computing a number from one side of an empty market. Those opportunities are artifacts, not trades.

Which prediction markets are actually worth scanning for arbitrage?

Liquid ones, and the volume data draws the line sharply. The figures below are Predictefy's Kalshi measurements from 2026-09-03, and the crossing column assumes a comparable book on the second venue. The residual on a 4¢ midpoint gap flips from deeply negative to workable somewhere around 1,000 USD of daily volume.

The share quoting inside 2¢ rises from 7% in the lowest bucket to 69% in the highest. The top bucket is where a gap can survive. The bottom bucket is where a scanner that trusts midpoints will send you.

Category matters too. The widest books were scalar economic markets, KXUSCPIYEAR at 57¢ and KXFEDFUNDSYEAR at 42¢, which show the richest apparent gaps on a midpoint-based screen and are the worst places to try. The tightest were sports, KXWC at 0.3¢.

How do you check an arbitrage gap against a live order book?

You price the trade off the ask side of both books at the size you intend to trade, not off the midpoint. That is the entire qualification step.

Install whichever client fits your stack, pinned to an exact version. All three are available in beta.

npm install @predictefy/sdk@1.0.0-beta.3
pip install predictefy==1.0.0b2
npx -y @predictefy/mcp    # MCP server, MIT licensed, npm 1.0.0-beta.3

The qualification itself is arithmetic on the two legs, and it is worth writing out so you can see exactly which candidates it throws away.

const FEES_CENTS = 1.5;   // your blended venue cost per pair
const SIZE_USD = 100;     // per-order cap on the execution service

// legA and legB hold the top of each book, read from
// https://data.predictefy.com under the /api/{venue}/{verb} path shape.
function qualify(legA, legB) {
  // No bid at all means the midpoint that produced this gap is fiction.
  if (!legA.hasBid || !legB.hasBid) return null;

  // Price the fill, not the quote: you pay both asks.
  const costCents = legA.askCents + legB.askCents;
  const netCents = 100 - costCents - FEES_CENTS;

  // Top of book only, so this is a floor on tradable size and not full
  // sweepable depth. A pair you could fill by walking two or three price
  // levels will fail this check even though it is real.
  const contracts = Math.min(legA.askSize, legB.askSize);
  const fillableUsd = (contracts * costCents) / 100;

  if (netCents <= 0 || fillableUsd < SIZE_USD) return null;
  return { netCents, fillableUsd };
}

How do you place both legs of the trade?

Separately, on each venue, because there is no cross-venue router in this stack and you should not trust one that claims to be. Execution runs as its own non-custodial service with a path per venue, orders are signed client side, and every write carries an Idempotency-Key.

# Building a payload is unmetered. Submitting charges credits.
POST /v1/exec/kalshi/orders/build
POST /v1/exec/kalshi/orders/submit        # Idempotency-Key required

POST /v1/exec/polymarket/orders/build
POST /v1/exec/polymarket/orders/submit    # Idempotency-Key required

# Reads live on a separate host, under /api/{venue}/{verb}:
curl -H "Authorization: Bearer $PREDICTEFY_API_KEY" \
  https://data.predictefy.com/api/kalshi/fetchOrderBook

The practical consequence is leg risk. Between the first submit and the second, the second book can move and leave you holding one side of a pair at a price that no longer works. Build both payloads first, then submit fast.

What eats the edge besides the spread?

Three things. Fees and transfer costs on each venue, which turn a 2¢ pair into a 0.5¢ pair. Capital lockup, since money committed to a market that resolves in four months earns nothing while it waits. And resolution equivalence, which is the one that loses money.

Two markets described with the same headline are not always the same contract. Different data sources, different cutoff times and different tie handling mean a pair you booked as offsetting can settle against you on both legs. Read both resolution criteria in full before you treat a pair as closed.

What is the best way to run prediction market arbitrage?

Automate the scanning, and pay nothing for it. The Predictefy arbitrage API is free, which changes the economics of the whole activity: when checking costs zero, you can afford to reject 99% of candidates and still come out ahead.

The rest of the case is coverage and schema. Predictefy aggregates 15+ venues, the widest coverage of any cross-venue scanner, and returns them in one normalized schema, so you write one integration instead of one per venue. Qualification runs against live order books rather than midpoints, which is exactly the difference the tables above are measuring.

Pricing does not gate the useful part. Free is 0 USD with 25,000 credits a month, 60 requests a minute, 1 API key and 2 WebSocket streams. Builder is 49 USD a month, Pro 249 USD, Scale 999 USD, Enterprise from 2,500 USD. The TypeScript SDK (@predictefy/sdk 1.0.0-beta.3), the Python package (predictefy 1.0.0b2) and the MCP server (@predictefy/mcp, MIT licensed) are all available in beta.

Two limits worth stating plainly. fetchBalance on the hosted API returns 501 NOT_SUPPORTED, so balances come from the venue. Stored history is proven for 11 venues rather than all of them. Neither blocks arbitrage work, and you should know both before you build on top.

Frequently Asked Questions