Polymarket Arbitrage Bible: The True Gap Lies in Mathematical Infrastructure

The Math Needed for Trading on Polymarket (Complete Roadmap)

By Roan

Reprint: Mars Finance

During the development of @insidersdotbot, I had in-depth conversations with many high-frequency market-making and arbitrage teams. The biggest need they expressed was: how to develop arbitrage strategies.

Our users, friends, and partners are all exploring the complex, multi-dimensional trading route of arbitrage on Polymarket. If you’re an active Twitter user, I believe you’ve seen tweets like “I made $X using XX arbitrage strategy on prediction markets.”

However, most articles oversimplify the underlying logic of arbitrage, turning it into “I can do it too” or “Clawdbot can solve it,” without explaining how to systematically understand and develop your own arbitrage system.

If you want to understand how arbitrage tools on Polymarket make money, this article is the most comprehensive explanation I’ve seen so far.

Because the original English text contains many technical parts requiring further research, I have reconstructed and supplemented them to make it easier for everyone to understand all key points without stopping to look up information.

Arbitrage on Polymarket is not just a simple math problem

Suppose you see a market on Polymarket:

YES price $0.62, NO price $0.33.

You think: 0.62 + 0.33 = 0.95, less than $1.00, so there’s arbitrage opportunity! Buy YES and NO for $0.95 total, and regardless of the outcome, you can get back $1.00, netting $0.05 profit.

You are correct.

But the problem is—while you’re still manually doing this addition, the quantitative system is doing something entirely different.

It’s scanning 17,218 conditions across 2^63 possible outcome combinations, finding all pricing contradictions within milliseconds. By the time you place two orders, the price discrepancy has disappeared. The system has already found similar loopholes in dozens of related markets, calculated the optimal position size considering order book depth and fees, executed all trades in parallel, and moved funds to the next opportunity.[1]

The gap isn’t just speed. It’s the mathematical infrastructure.

Chapter 1: Why Addition Isn’t Enough—The Marginal Polytope Problem

Single Market Fallacy

Let’s look at a simple example.

Market A: “Will Trump win the Pennsylvania election?”

YES price $0.48, NO price $0.52. Total: exactly $1.00.

Looks perfect, no arbitrage, right?

Wrong.

Add another market, and the problem arises.

Market B: “Will the Republican Party lead by more than 5 percentage points in Pennsylvania?”

YES price $0.32, NO price $0.68. Total: also $1.00.

Each market appears “normal” individually. But there’s a logical dependency:

The U.S. presidential election isn’t counted state-by-state in total; it’s by electoral votes. Each state is an independent “battlefield,” and whoever gets more votes in that state wins all its electoral votes (winner-takes-all). Trump is the Republican candidate. So, “Republican wins Pennsylvania” and “Trump wins Pennsylvania”—are the same thing. If the Republican wins by more than 5 points, it means Trump won Pennsylvania and won big.

In other words, the YES in Market B (“Republican victory by a large margin”) is a subset of YES in Market A (“Trump wins”). A big victory implies a win, but a win doesn’t necessarily mean a big victory.

This logical dependency creates arbitrage opportunities.

It’s like betting on two things—“Will it rain tomorrow?” and “Will there be thunderstorms tomorrow?”

If there’s a thunderstorm, it must rain (thunderstorm is a subset of rain). So, the price of “Thunderstorm YES” can’t be higher than “Rain YES.” If market prices violate this logic, you can buy low and sell high simultaneously for riskless profit—that’s arbitrage.

Explosion of complexity: Why brute-force search doesn’t work

For any market with n conditions, there are theoretically 2^n possible price combinations.

Sounds manageable? Let’s look at a real case.

2010 NCAA Tournament markets [2]: 63 games, each with two outcomes. Total possible outcome combinations: 2^63 = 9,223,372,036,854,775,808—over 9 quintillion. The market has over 5,000 odds.

How big is 2^63? Checking 1 billion combinations per second would take about 292 years to exhaustively check all. That’s why brute-force search is impossible here.

Checking each combination one by one? Computationally infeasible.

Similarly, for the 2024 US election, researchers found 1,576 pairs of markets with potential dependencies. If each pair has 10 conditions, that’s 2^20 = 1,048,576 combinations per pair. Multiplying by 1,576 pairs, your laptop would finish long before the election results are out.

Integer Programming: Replacing Enumeration with Constraints

The solution for quant systems isn’t “faster enumeration,” but rather no enumeration at all.

They use Integer Programming to describe “which outcomes are valid.”

Here’s a real example: Duke vs. Cornell match market: each team has 7 possible win counts (0 to 6), total 14 conditions, so 2^14 = 16,384 possible combinations.

But there’s a constraint: they can’t both win more than 4 games, because that would mean they meet in the semifinals (only one can advance).

How does Integer Programming handle this? With just three constraints:

· Constraint 1: Exactly one of Duke’s 7 win counts is true (Duke can only have one final win count).

· Constraint 2: Exactly one of Cornell’s 7 win counts is true.

· Constraint 3: Duke wins 5 + 6 games + Cornell wins 5 + 6 games ≤ 1 (they can’t both win many games simultaneously).

Three linear constraints replace 16,384 brute-force checks.

In other words, brute-force is like reading every word in a dictionary to find a match. Integer programming is like flipping directly to the page starting with that letter. You don’t need to check all possibilities—just describe what a valid answer looks like, then let the algorithm find violations.

Real data: 41% of markets have arbitrage [2]

The research team analyzed data from April 2024 to April 2025:

• Checked 17,218 conditions

• 7,051 conditions had single-market arbitrage (41%)

• Median pricing deviation: $0.60 (should be $1.00)

• 13 pairs of markets with confirmed exploitable cross-market arbitrage

A median deviation of $0.60 means markets often deviate by 40%. This isn’t “close to efficient”; it’s “large-scale exploitable.”

Chapter 2: Bregman Projection—Calculating the Optimal Arbitrage Trade

Finding arbitrage is one problem. Calculating the optimal arbitrage trade is another.

You can’t just “average” or “slightly adjust” prices. You need to project the current market state onto the space of no-arbitrage valid prices, preserving the information structure.

Why “straight-line distance” doesn’t work

The most intuitive idea: find the “closest valid price” to the current price, then trade the difference.

Mathematically, minimizing Euclidean distance: ||μ - θ||²

But this has a fatal flaw: it treats all price changes equally.

Rising from $0.50 to $0.60 and from $0.05 to $0.15 both are +10 cents. But their informational content differs vastly.

Why? Because prices imply probabilities. Moving from 50% to 60% is a mild belief shift. Moving from 5% to 15% is a huge belief flip—an event that was nearly impossible suddenly becomes “somewhat likely.”

Imagine weighing your body: going from 70kg to 80kg is “a bit heavier.” But going from 30kg to 40kg (if you’re an adult) is “from near death to severe malnutrition.” The same 10kg change means very different things. Prices are similar: as they approach 0 or 1, their informational significance increases.

Bregman Divergence: The Correct “Distance”

Market makers on Polymarket use LMSR (Logarithmic Market Scoring Rule)[4], where prices represent probability distributions.

In this structure, the correct distance measure isn’t Euclidean but Bregman divergence.[5]

For LMSR, Bregman divergence becomes KL divergence (Kullback-Leibler divergence)[6]—a measure of “information distance” between two probability distributions.

You don’t need to memorize formulas. Just understand:

KL divergence automatically weights “extreme price movements” more heavily. Moving from $0.05 to $0.15 is “farther” than from $0.50 to $0.60 under KL divergence. This aligns with intuition—extreme price shifts imply larger informational shocks.

A good example: In @zachxbt’s last prediction market, Axiom overtook Meteora at the last moment, driven by extreme price movements, which signaled all the change.

Arbitrage profit = Bregman projection distance

This is one of the core conclusions from the referenced paper:

The maximum guaranteed profit from any trade equals the Bregman projection distance from the current market state to the no-arbitrage space.

In other words: the further market prices deviate from the “valid space,” the more you can earn. The Bregman projection tells you:

1. What to buy or sell (projection direction)

2. How much to buy or sell (considering order book depth)

3. How much you can earn (projection distance = maximum profit)

The top arbitrageur earned $2,009,631.76 in a year.[2] Their strategy was to solve this optimization faster and more accurately than anyone else.

Imagine standing on a mountain, with a river at the foot representing the no-arbitrage boundary. Your current position (market prices) is some distance from the river.

Bregman projection finds the “shortest path” from your position to the river—not a straight line, but considering the terrain (market structure). The length of this path is your maximum profit.

Chapter 3: Frank-Wolfe Algorithm—Turning Theory into Executable Code

Now you know: to compute the optimal arbitrage, you need Bregman projection.

But directly calculating Bregman projection is infeasible.

Why? Because the no-arbitrage space (the marginal polytope M) has exponentially many vertices. Standard convex optimization methods require accessing the entire constraint set—i.e., enumerating all valid outcomes. As we said, this is impossible at scale.

Frank-Wolfe’s core idea

The genius of Frank-Wolfe [7] is: it doesn’t try to solve the entire problem at once. Instead, it iteratively approaches the solution.

Its process:

1. Start with a small known feasible set.

2. Optimize over this small set to find the current best solution.

3. Use integer programming to find a new feasible point, add it to the set.

4. Check if close enough to optimal. If not, go back to step 2.

Each iteration adds only one vertex. Even after 100 iterations, you track only 100 vertices—not 2^63.

Imagine searching for an exit in a huge maze.

Brute-force: explore every path. Frank-Wolfe: take a random path, then at each junction ask a “guide” (integer programming solver): “From here, which direction is most likely to lead to the exit?” Then move one step in that direction. No need to explore the entire maze—just make the right choices at key points.

Integer programming solver: the “guide” at each step

Each Frank-Wolfe iteration requires solving an integer linear programming problem. In theory, NP-hard (no known polynomial-time algorithm).

But modern solvers like Gurobi[8] can handle well-structured problems efficiently.

The research team used Gurobi 5.5. Actual solve times:

• Early iterations (few markets finished): under 1 second

• Mid-stage (30-40 markets finished): 10-30 seconds

• Late-stage (50+ markets finished): under 5 seconds

Why faster later? Because as market outcomes become certain, the feasible solution space shrinks. Fewer variables, tighter constraints, faster solving.

Gradient explosion and Barrier Frank-Wolfe

Standard Frank-Wolfe has a technical issue: when prices approach 0, LMSR’s gradient tends to negative infinity, causing instability.

Solution: Barrier Frank-Wolfe—optimize over a slightly “shrunk” version of the polytope M. The shrinkage parameter ε adapts during iterations—initially stable away from boundaries, then gradually approaching the true boundary for precision.

Research shows that 50–150 iterations are enough for convergence.

Real-world performance

The paper’s key finding [2]:

In the first 16 NCAA tournament games, Frank-Wolfe market makers (FWMM) and simple linear constraint market makers (LCMM) performed similarly—because integer programming was still slow.

But after 45 games, the first successful 30-minute projection was completed.

Since then, FWMM outperformed LCMM by 38% in market pricing.

The turning point: when the outcome space shrinks enough for integer programming to solve within trading windows.

FWMM is like a student warming up early, then crushing the exam once in the zone. LCMM is the steady student with limited ceiling. The key difference: FWMM has a “better weapon” (Bregman projection), just needs time to “reload” (run the solver).

Chapter 4: Execution—Why You Might Still Lose Money After Calculating

You’ve detected arbitrage. You’ve computed the optimal trade via Bregman projection.

Now, you need to execute.

This is where most strategies fail.

Non-atomic execution problem

Polymarket uses CLOB (Central Limit Order Book)[9]. Unlike decentralized exchanges, trades are executed sequentially—you can’t guarantee all orders fill simultaneously.

Your arbitrage plan:

Buy YES at $0.30. Buy NO at $0.30. Total cost $0.60. Regardless of outcome, you can recover $1.00. Profit $0.40.

Reality:

· Submit YES order → fills at $0.30 ✓

· Your order shifts the market price.

· Submit NO order → fills at $0.78 ✗

· Total cost: $1.08. Recover: $1.00. Actual loss: $0.08.

One leg filled, the other not. You’ve exposed yourself.

That’s why the paper only counts opportunities with profit margins over $0.05. Smaller spreads are eaten up by execution risk.

VWAP: The Actual Transaction Price

Don’t assume you can buy at the quoted price. Calculate the volume-weighted average price (VWAP)[10].

The research team’s method: for each block on Polygon (about 2 seconds), compute VWAP of all YES trades and all NO trades. If |VWAP_yes + VWAP_no - 1.0| > 0.02, record as an arbitrage opportunity [2].

VWAP is “the average price you actually paid.” If you want to buy 10,000 tokens but only 2,000 are available at $0.30, 3,000 at $0.32, 5,000 at $0.35—your VWAP is (2000×0.30 + 3000×0.32 + 5000×0.35) / 10,000 = $0.326. Higher than the “best quote” of $0.30.

Liquidity constraints: How much you can profit depends on order book depth

Even if prices deviate, your profit is limited by available liquidity.

Real example [2]:

Market shows arbitrage: sum of YES prices = $0.85. Potential profit: $0.15 per dollar. But order book depth at these prices is only $234. Max extractable profit: $234 × $0.15 = $35.10.

For cross-market arbitrage, you need liquidity across all positions. The smallest available liquidity caps your maximum.

This is why, in current quant platforms, showing how order prices impact transaction prices is crucial.

Chapter 5: Complete System—What Is Actually Deployed

Theory is clean. Production is messy.

Here’s what a real arbitrage system looks like [2].

Data pipeline

Real-time data: WebSocket connection to Polymarket API[9], receiving order book updates (price/volume changes), trade pushes, market creation/settlement events.

Historical data: querying contract events via Alchemy Polygon node API—OrderFilled (trade executed), PositionSplit (new tokens minted), PositionsMerge (tokens burned).

The team analyzed 86 million trades [2]. This scale requires infrastructure, not scripts.

Plans are underway to open-source high-speed trading APIs. If you plan to use similar trading models, DM me for early access.

Dependency detection layer

For 305 US election markets, there are 46,360 pairs of potential dependencies to check. Manual analysis is impossible.

The team used a clever approach: a large language model (DeepSeek-R1-Distill-Qwen-32B) for initial screening.

Input: descriptions of conditions for two markets. Output: JSON of valid outcome combinations.

Then three verification layers: does each market have exactly one true condition? Is the number of valid combinations less than n×m (dependency exists)? Does the dependency subset satisfy arbitrage conditions?

Results: 40,057 independent (no arbitrage) pairs → 1,576 dependent (potential arbitrage) pairs → 374 meet strict conditions → 13 verified manually as exploitable [2].

LLM accuracy on complex multi-condition markets is 81.45%. Sufficient for initial screening, but manual validation needed before execution.

Three-layer optimization engine

· Layer 1: Simple linear constraints (LCMM). Fast check of basic rules—“probabilities sum to 1,” “if A implies B, then P(A) ≤ P(B).” Millisecond speed, removing obvious pricing errors.

· Layer 2: Integer programming projection (Frank-Wolfe + Gurobi). Core step. Parameters: Alpha=0.9 (extract at least 90% of available arbitrage), initial ε=0.1 (10% shrinkage), convergence threshold=1e-6, time limit=30 min. Typical iterations: 50–150. Each solve: 1–30 seconds.

· Layer 3: Execution validation. Before submitting orders, simulate current order book fills. Check: is liquidity sufficient? Expected slippage? Guaranteed profit after slippage? Is profit above $0.05? Only execute if all pass.

Position management: Improved Kelly formula

Standard Kelly [11] tells you what proportion of capital to invest. In arbitrage, adjustments for execution risk are needed:

f = (b×p - q) / b × √p

where b is profit percentage, p is probability of full execution (estimated from order book), q=1−p.

Cap at 50% of order book depth. Beyond that, your order itself will move the market significantly.

Final results

From April 2024 to April 2025, total extracted profit:

Single-condition arbitrage: buy low on both sides $5,899,287 + sell high on both sides $4,682,075 = $10,581,362

Market rebalancing: buy all YES $11,092,286 + sell all YES $612,189 + buy all NO $17,307,114 = $29,011,589

Cross-market arbitrage: $95,634

Total: $39,688,585

Top 10 arbitrageurs took $8,127,849 (20.5% of total). The top arbitrageur made $2,009,632 from 4,049 trades, averaging $496 per trade [2].

It’s not luck. Not gambling. It’s systematic execution based on precise mathematics.

Final reality

While traders are reading “10 Tips for Prediction Markets,” the quant systems are doing what?

They’re using integer programming to analyze 17,218 conditions for dependencies. Using Bregman projection to compute optimal arbitrage trades. Running Frank-Wolfe to handle gradient explosion. Estimating slippage with VWAP and executing orders in parallel. Systematically extracting guaranteed profits of over $40 million.

The gap isn’t luck. It’s the mathematical infrastructure.

The paper is public [1]. The algorithms are known. The profits are real.

The question is: before the next $40 million is extracted, can you build it?

Quick Concept Reference

• Marginal Polytope → The space of all “legal prices.” Prices must lie within this space to be arbitrage-free. Think of it as “the legal region of prices.”

• Integer Programming → Describes valid outcomes with linear constraints, avoiding brute-force enumeration. Compresses 2^63 checks into a few constraints [3].

• Bregman / KL Divergence → Measures “distance” between probability distributions, more suitable than Euclidean distance for prices/probabilities. Heavier weight near extremes [5][6].

• LMSR (Logarithmic Market Scoring Rule) → The market maker’s pricing mechanism, where prices represent implied probabilities [4].

• Frank-Wolfe Algorithm → An iterative optimization method that adds only one vertex per step, avoiding enumeration of exponentially many feasible solutions [7].

• Gurobi → Leading commercial integer programming solver, used as the “guide” in each Frank-Wolfe iteration [8].

• CLOB (Central Limit Order Book) → The Polymarket trading mechanism, where orders are matched sequentially, not atomically [9].

• VWAP (Volume-Weighted Average Price) → The actual average price paid, considering order book depth. More realistic than the “best quote” [10].

• Kelly Formula → Tells you what proportion of capital to allocate, balancing reward and risk [11].

• Non-Atomic Execution → The problem that multiple orders may not fill simultaneously, exposing risk if one leg fills and the other doesn’t.

• DeepSeek → Large language model used for initial screening of market dependencies, with 81.45% accuracy.