Original Title: The Math Needed for Trading on Polymarket (Complete Roadmap)

Original Author: Roan, Crypto Analyst

Translation & Annotations: MrRyanChi, insiders.bot

While establishing @insidersdotbot, I had in-depth discussions with many high-frequency market making teams and arbitrage teams, and the biggest need among them was how to implement arbitrage strategies.

Our users, friends, and partners are all exploring the complex and multi-dimensional trading route of Polymarket arbitrage. If you are an active Twitter user, then I believe you have also come across tweets like "I made money on the prediction market through XX arbitrage strategy".

However, most articles oversimplify the underlying logic of arbitrage, turning it into a trading mode of "if I can do it, so can you" and "use Clawdbot to solve it", without elaborating on 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 interpretation I have seen so far.

Since the original English text is overly technical and requires further research, I have restructured and supplemented it to help everyone grasp all the key points in one article without the need to pause and look up information.

Polymarket Arbitrage is Not a Simple Math Problem

You see a market on Polymarket:

YES price $0.62, NO price $0.33.

You think to yourself: 0.62 + 0.33 = 0.95, less than 1 dollar, there is arbitrage opportunity! Buy YES and NO at $0.95, and you can get back $1.00 regardless of the outcome, netting $0.05.

You are correct.

But the problem is—while you are still manually calculating this addition problem, quant systems are doing something completely different.

They are simultaneously scanning 17,218 conditions, spanning 2^63 possible outcome combinations, finding all pricing inconsistencies in milliseconds. By the time you place two orders, the price difference has disappeared. The system has long since found the same loophole in dozens of related markets, calculated the optimal position size considering order book depth and fees, executed all trades in parallel, and then moved funds to the next opportunity. [1]

The Gap is Not Just About Speed. It's About Mathematical Infrastructure.

Chapter 1: Why "Addition" Is Not Enough — The Marginal Polytope Problem

The Single Market Fallacy

Let's start with a simple example.

Market A: "Will Trump Win the Election in Pennsylvania?"

YES price $0.48, NO price $0.52. Adding up to exactly $1.00.

Seems perfect, no arbitrage opportunity, right?

Wrong.

Adding one more market changes the game

Now look at Market B: "Will the Republicans Outperform the Opponent by More Than 5 Percentage Points in Pennsylvania?"

YES price $0.32, NO price $0.68. Also adding up to $1.00.

Each market looks "normal" on its own. But there is a logical dependency here:

The U.S. presidential election is not a national popular vote but a state-by-state count. Each state is an independent "battleground," whoever gets more votes in that state takes all of that state's electoral votes (winner takes all). Trump is the Republican candidate. So, "Republicans winning in Pennsylvania" and "Trump winning in Pennsylvania" — it's the same thing. If the Republicans win by over 5 percentage points, it not only means Trump won Pennsylvania, but won by a large margin.

In other words, the YES in Market B (Republican blowout) is a subset of the YES in Market A (Trump victory) — a blowout always means a victory, but a victory does not always mean a blowout.

And this logical dependency creates arbitrage opportunities.

It's like you're betting on two things — "Will it rain tomorrow" and "Will there be a thunderstorm tomorrow."

If there's a thunderstorm, it will definitely rain (a thunderstorm is a subset of rain). So the price of "YES for thunderstorm" cannot be higher than the price of "YES for rain." If the market pricing violates this logic, you can buy low and sell high simultaneously, earning "risk-free profit," which is arbitrage.

Exponential Explosion: Why Brute Force Search Doesn't Work

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

Sound manageable? Let's look at a real-life example.

2010 NCAA Tournament Market [2]: 63 games, each with two possible outcomes. The number of possible outcome combinations is 2^63 = 9,223,372,036,854,775,808—over 9 quintillion possibilities. There are over 5000 markets available.

How big is 2^63? If you checked 1 billion combinations per second, it would take around 292 years to check them all. That's why "brute force search" is completely ineffective here.

Checking each combination one by one? Computationally infeasible.

Now, consider the 2024 US election. A research team identified 1,576 pairs of potentially correlated markets. If each pair has 10 conditions, then each pair requires checking 2^20 = 1,048,576 combinations. Multiply that by 1,576 pairs. By the time your laptop finishes calculating, the election results will already be out.

Integer Programming: Using Constraints Instead of Enumeration

The solution for quantitative systems is not "enumerate faster," but rather not to enumerate at all.

They use Integer Programming to define "which outcomes are valid".

Consider a real example. Duke vs. Cornell game market: each team has 7 markets (0 to 6 wins), totaling 14 conditions, with 2^14 = 16,384 possible combinations.

But there's a constraint: they can't both win 5 games or more because they would meet in the semifinals (only one can advance).

How does Integer Programming handle this? Three constraints are enough:

· Constraint one: Of Duke's 7 markets, exactly one is true (Duke can only have one final win count).

· Constraint 2: Among Cornell's 7 spreads, exactly one is true.

· Constraint 3: Duke Wins 5 games + Duke Wins 6 games + Cornell Wins 5 games + Cornell Wins 6 games ≤ 1 (they cannot all win that many).

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

Brute Force Search vs Integer Programming

In other words, brute force search is like reading through every word in the dictionary to find a word. Integer programming is like flipping directly to the page starting with that letter. You don't need to check all possibilities; you just need to describe "what a valid answer looks like" and then let the algorithm find pricing that violates the rules.

Real Data: 41% of Market Exhibits Arbitrage [2]

The original text mentions that the research team analyzed data from April 2024 to April 2025:

• Checked 17,218 conditions

• Of which 7,051 conditions exhibited single-market arbitrage (41%)

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

• 13 confirmed cross-market exploitable arbitrage opportunities

A median deviation of $0.60 means markets frequently deviate by 40%. This is not "near efficient"; this is "massively exploitable."

Chapter 2: Bregman Projection - Calculating the Optimal Arbitrage Trade

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

You can't simply "take an average" or "adjust the price a bit." You need to project the current market state into the arbitrage-free feasible space while preserving the informational structure in prices.

Why "Euclidean Distance" Doesn't Work

The most intuitive idea is to find the nearest "valid price" to the current price and then trade the difference.

In mathematical terms, it is to minimize the Euclidean distance: ||μ - θ||²

However, this has a fatal flaw: it treats all price changes as equal.

Going from $0.50 to $0.60 and going from $0.05 to $0.15 are both a 10-cent increase. But their informational content is entirely different.

Why? Because prices represent implied probabilities. Going from 50% to 60% is a mild viewpoint adjustment. Going from 5% to 15% is a huge belief reversal — an almost impossible event suddenly becoming "somewhat possible."

Imagine you are weighing yourself. Going from 70 kg to 80 kg, you would say "I gained a bit of weight." But going from 30 kg to 40 kg (if you are an adult) would be "going from near death to severe malnutrition." Both are a 10 kg change, but the significance is entirely different. Prices are the same — price changes closer to 0 or 1 carry more information.

Bregman Divergence: The Right "Distance"

Polymarket's market makers use LMSR (Logarithmic Market Scoring Rule)[4], where prices fundamentally represent a probability distribution.

In this structure, the correct distance metric is not the Euclidean distance but the Bregman Divergence.[5]

For LMSR, the Bregman Divergence becomes the KL Divergence (Kullback-Leibler Divergence)[6] — a metric that measures the "information distance" between two probability distributions.

You don't need to remember the formula. You just need to understand one thing:

The KL Divergence automatically assigns higher weight to "changes near extreme prices." A change from $0.05 to $0.15 is "farther" under the KL Divergence than a change from $0.50 to $0.60. This aligns with our intuition — changes near extreme prices imply a larger information impact.

A good example is the last-minute turnaround of Axiom overtaking Meteora in @zachxbt's prediction market, also driven by extreme price movements.

Bregman Projection vs Euclidean Projection

Arbitrage Profit = Distance of Bregman Projection

This is one of the key conclusions the original author referred to throughout the paper:

The maximum guaranteed profit that any trade can achieve is equal to the distance from the current market state to the arbitrage-free space's Bregman projection.

In other words, the further the market price is from the "valid space," the more money can be made. And the Bregman projection will tell you:

1. What to trade (the projection direction tells you the trading direction)

2. How much to trade (considering order book depth)

3. How much can be earned (the projection distance is the maximum profit)

The top-ranked arbitrager made $2,009,631.76 in a year. [2] His strategy is to solve this optimization problem faster and more accurately than anyone else.

Marginal Polytope and Arbitrage

For example, imagine you are standing on top of a mountain, and at the foot of the mountain, there is a river (arbitrage-free space). Your current position (current market price) is a certain distance from the river.

The Bregman projection helps you find the "shortest path from your position to the riverbank" — but not the straight-line distance, rather the shortest path considering the terrain (market structure). The length of this path is the maximum profit you can earn.

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

So, now you know: to calculate the optimal arbitrage, you need to perform the Bregman projection.

But here's the problem — computing the Bregman projection directly is infeasible.

Why? Because the arbitrage-free space (marginal polytope M) has an exponentially large number of vertices. Standard convex optimization methods require accessing the entire constraint set, meaning enumerating every valid outcome. As we mentioned earlier, this is impossible in a scalable scenario.

The Core Idea of Frank-Wolfe

The brilliance of the Frank-Wolfe algorithm [7] lies in: its approach of not trying to solve the whole problem at once, but progressively getting closer to the answer step by step.

Here is how it works:

Step 1: Start from a small known feasible solution set.

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

Step 3: Find a new feasible solution using integer programming and add it to the set.

Step 4: Check if close enough to the optimal solution. If not, go back to Step 2.

Each iteration, the set grows by only one vertex. Even after 100 rounds, you only need to track 100 vertices—instead of 2^63.

Frank-Wolfe Iteration Process

Imagine you are in a huge maze trying to find the exit.

The brute force approach would be to explore every path. The Frank-Wolfe method is: take a random path first, then at each junction, ask an "oracle" (integer programming solver): "From here, which direction is most likely to lead to the exit?" and take a step in that direction. You don't need to explore the entire maze, just make the right choice at each critical juncture.

Integer Programming Solver: The Oracle for Each Step

Each iteration of Frank-Wolfe requires solving an integer linear programming problem. This is theoretically NP-hard (meaning "no known fast general algorithm").

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

The research team used Gurobi 5.5. Actual solution times:

• Early iteration (few matches completed): Less than 1 second

• Mid-phase (30-40 matches completed): 10-30 seconds

• Endgame (50+ matches have concluded): Less than 5 seconds

Why is the endgame faster? Because as the match results become clear, the feasible solution space shrinks. There are fewer variables, tighter constraints, and faster solving.

Gradient Explosion Issue and Barrier Frank-Wolfe

The standard Frank-Wolfe has a technical issue: when prices approach 0, the gradient of the LMSR tends to negative infinity. This causes the algorithm to be unstable.

The solution is Barrier Frank-Wolfe: instead of optimizing over the full polytope M, it optimizes over a slightly "contracted" version of M. The contraction parameter ε adaptively decreases with iterations—starting further from the boundary (stable), then gradually moving closer to the true boundary (precise).

Research shows that in practice, 50 to 150 rounds of iteration are sufficient for convergence.

Real Performance

A key finding in the paper [2] was:

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

However, after 45 matches, the first successful 30-minute projection was completed.

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

The turning point is when the outcome space shrinks to where the integer programming can solve within the trading time window.

FWMM is like a student who warms up in the first half of the exam, but once in the zone, starts dominating. LCMM is the student who consistently performs but has a limited ceiling. The key difference is: FWMM has a stronger "weapon" (Bregman projection) but needs time to "reload" (wait for the solver to finish).

Chapter 4: Execution—Why Calculating the Optimal Trade May Still Lose Money

You detect arbitrage. You calculate the optimal trade with Bregman projection.

Now you need to perform.

This is where most strategies fail.

Non-Atomic Execution Issue

Polymarket uses a CLOB (Central Limit Order Book) [9]. Unlike decentralized exchanges, trades on a CLOB are executed sequentially — you cannot guarantee all orders will be filled at once.

Your Arbitrage Plan:

Buy YES at a price of $0.30. Buy NO at a price of $0.30. Total cost $0.60. Regardless of the outcome, receive $1.00. Profit $0.40.

Reality:

· Submit YES order → Fill price $0.30 ✓

· Your order shifted the market price.

· Submit NO order → Fill price $0.78 ✗

· Total cost: $1.08. Return: $1.00. Actual result: Loss of $0.08.

One leg filled, the other didn't. You've been exposed.

This is why the paper only accounts for opportunities with a profit spread greater than $0.05. Smaller spreads will be eaten up by execution risk.

Non-Atomic Execution Risk

VWAP: The Real Trade Price

Don't assume you'll transact at quote. Calculate the Volume Weighted Average Price (VWAP) [10].

The research team's approach is: for each block on the Polygon chain (about 2 seconds), calculate the VWAP of all YES trades and all NO trades within that block. If |VWAP_yes + VWAP_no - 1.0| > 0.02, it's recorded as an arbitrage opportunity [2].

VWAP is "the average price you actually paid." If you want to buy 10,000 tokens, but at $0.30 there are only 2,000, at $0.32 there are 3,000, at $0.35 there are 5,000 — your VWAP is (2000×0.30 + 3000×0.32 + 5000×0.35) / 10000 = $0.326. Much higher than the "best" price of $0.30 you saw.

Liquidity Constraint: How Much You Can Make Depends on Order Book Depth

Even if the price does have a discrepancy, the profit you can make is also limited by available liquidity.

Real-life example [2]:

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

For cross-market arbitrage, you need liquidity in all positions simultaneously. The smallest one determines your cap.

This is also why, in existing quant platforms, showing the impact of order price on execution price is crucial.

Chapter Five: The Whole System—What Was Actually Deployed

The theory is clean. The production environment is messy.

This is what a truly runnable arbitrage system looks like [2].

Data Pipeline

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

Historical data: Querying contract events via the Alchemy Polygon node API—OrderFilled (trade execution), PositionSplit (new token minting), PositionsMerge (token burning).

The research team analyzed 86 million trades [2]. Infrastructure is needed at this scale; it's not something a script can handle.

There are also plans to open-source a high-speed trading API. If you plan to use a similar trading model and would like to experience the API firsthand or have any questions, feel free to DM me at any time.

Dependency Detection Layer

For 305 US election markets, there are 46,360 possible combinations to check. Manual analysis is infeasible.

The research team employed a clever approach: using the DeepSeek-R1-Distill-Qwen-32B large language model for initial screening.

Input: Descriptions of conditions for two markets. Output: JSON of valid result combinations.

This was followed by a three-layer validation process: Does each market have exactly one true condition? Are the valid combination count fewer than n × m (dependency exists)? Do the dependency subsets satisfy arbitrage conditions?

Results: 40,057 pairs independent (no arbitrage) → 1,576 pairs dependent (potential arbitrage) → 374 pairs meeting strict criteria → 13 pairs exploitable upon manual verification [2].

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

Three-Layer Optimization Engine

· Layer 1: Linear Constraint Matching Method (LCMM). Quickly checks basic rules— "sum probability equals 1," "if A implies B, then P(A) cannot exceed P(B)." Completed in milliseconds, removing obvious pricing errors.

· Layer 2: Integer Programming Projection (Frank-Wolfe + Gurobi). This is the core. Parameters: Alpha = 0.9 (extract at least 90% of available arbitrage), initial ε = 0.1 (10% shrink), convergence threshold = 1e-6, time limit = 30 minutes. Typical iterations: 50-150 times. Solve time per iteration: 1-30 seconds.

· Layer 3: Execution validation. Before submitting orders, simulate trades on the current order book. Check: Is liquidity sufficient? What is the expected slippage? After deducting slippage, what is the guaranteed profit? Does the profit exceed the minimum threshold ($0.05)? Only proceed if all checks pass.

Position Sizing: Enhanced Kelly Formula

The standard Kelly formula [11] tells you what proportion of funds to put into a trade. But in an arbitrage scenario, adjustment for execution risk is needed:

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

Where b is the arbitrage profit percentage, p is the probability of full execution (estimated based on order book depth), q = 1 - p.

Upper Limit: 50% of order book depth. Above this proportion, your order itself will significantly move the market.

Final Result

From April 2024 to April 2025, total extracted profit:

Single Condition Arbitrage: Low Buy Both Sides $5,899,287 + High Sell Both Sides $4,682,075 = $10,581,362

Market Rebalance: Low Buy All YES $11,092,286 + High Sell All YES $612,189 + Buy All NO $17,307,114 = $29,011,589

Cross-Market Combination Arbitrage: $95,634

Total: $39,688,585

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

Not a lottery. Not luck. It's the systematic execution of mathematical precision.

The Ultimate Reality

While traders are still reading "10 Tips for Predicting Markets," what are quantitative systems doing?

They are detecting dependencies between 17,218 conditions using integer programming. They are calculating optimal arbitrage trades using Bregman projection. They are handling gradient explosions using the Frank-Wolfe algorithm. They are estimating slippage with VWAP and executing orders in parallel. They are systematically extracting $40 million in guaranteed profit.

The gap is not luck. It's a mathematical infrastructure.

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

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

Concept Quick Lookup

• Marginal Polytope → The space of all "valid prices." Prices must lie within this space to avoid arbitrage. Can be understood as the "valid region of prices."

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

• Bregman Divergence / KL Divergence → Method to measure the "distance" between two probability distributions, more suitable for pricing/probability scenarios than Euclidean distance. Weighted more towards changes near extreme prices [5][6]

• LMSR (Logarithmic Market Scoring Rule) → Pricing mechanism used by Polymarket market makers, where prices represent implied probabilities [4]

• Frank-Wolfe Algorithm → An iterative optimization algorithm that adds only one new vertex per round, avoiding exponential enumeration of valid outcomes [7]

• Gurobi → Industry-leading integer programming solver, the "guide" for each Frank-Wolfe iteration [8]

• CLOB (Central Limit Order Book) → Polymarket's trade matching mechanism, orders executed in sequence, atomicity not guaranteed [9]

• VWAP (Volume-Weighted Average Price) → The average price you actually pay, considering order book depth. More realistic than "best price" [10]

• Kelly Criterion → Tells you what proportion of funds to put into a trade to balance return and risk [11]

• Non-Atomic Execution → The issue where multiple orders cannot guarantee simultaneous execution. One leg executes while the other doesn't = exposure risk

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

References

[1] Original Tweet: https://x.com/RohOnChain/status/2017314080395296995

[2] Research Paper "Unravelling the Probabilistic Forest: Arbitrage in Prediction Markets": https://arxiv.org/abs/2508.03474

[3] Theoretical Foundation Paper "Arbitrage-Free Combinatorial Market Making via Integer Programming": https://arxiv.org/abs/1606.02825

[4] LMSR Logarithmic Market Scoring Rule Explanation: https://www.cultivatelabs.com/crowdsourced-forecasting-guide/how-does-logarithmic-market-scoring-rule-lmsr-work

[5] Intro to Bregman Divergence: https://mark.reid.name/blog/meet-the-bregman-divergences.html

[6] KL Divergence - Wikipedia: https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_divergence

[7] Frank-Wolfe Algorithm - Wikipedia: https://en.wikipedia.org/wiki/Frank%E2%80%93Wolfe_algorithm

[8] Gurobi Optimizer: https://www.gurobi.com/

[9] Polymarket CLOB API Documentation: https://docs.polymarket.com/

[10] VWAP Explanation - Investopedia: https://www.investopedia.com/terms/v/vwap.asp

[11] Kelly Criterion - Investopedia: https://www.investopedia.com/articles/trading/04/091504.asp

[12] Decrypt Article "The $40 Million Free Money Glitch": https://decrypt.co/339958/40-million-free-money-glitch-crypto-prediction-markets

Original Post Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia