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

Original Author: Roan, Crypto Analyst

Translation & Annotation: MrRyanChi, insiders.bot

During the establishment of @insidersdotbot, I had in-depth discussions with many high-frequency market making teams and arbitrage teams, among which the biggest need 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 earned money from the prediction market through XX arbitrage strategy."

However, most articles oversimplify the underlying logic of arbitrage, turning arbitrage into a "I can do it too" and "I can solve it with Clawdbot" trading pattern, rather than explaining in detail how to systematically understand and develop your own arbitrage system.

If you want to understand how arbitrage tools on Polymarket earn money, this article is the most comprehensive interpretation I have seen so far.

Since the original English text is too technical in many parts and requires further research, I have refactored and supplemented it for everyone, making it easy for you to understand all the key points in just this one article without the need to stop 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: 0.62 + 0.33 = 0.95, less than 1 dollar, there is arbitrage opportunity! Buy YES and NO at the same time, spend $0.95, and regardless of the result, you can get back $1.00, making a net profit of $0.05.

You are correct.

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

They are simultaneously scanning 17,218 conditions, spanning 2^63 possible result combinations, and finding all pricing inconsistencies in milliseconds. By the time you place two orders, the price difference has disappeared. The system has already 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 Speed. It’s Math 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.

As soon as you add another market, issues arise.

Now consider Market B: "Will the Republicans Lead by More Than 5% in Pennsylvania?"

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

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

The U.S. presidential election is not a national popular vote; it is done on a state-by-state basis. Each state is an independent “battlefield,” where whoever gets more votes in that state takes all of that state’s electoral votes (winner takes all). Trump is the GOP candidate. So, “GOP winning in Pennsylvania” and “Trump winning in Pennsylvania” — it’s the same thing. If the GOP wins by over 5%, it not only means Trump wins Pennsylvania, but he wins big.

In other words, Market B’s YES (GOP blowout) is a subset of Market A’s YES (Trump victory) — a blowout definitely means victory, but victory does not necessarily mean a blowout.

And this logical dependency creates arbitrage opportunities.

It's like betting on two things — “Will it rain tomorrow?” and “Will there be a thunderstorm tomorrow?”

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

Exploding Kittens: Why Brute Force Search Fails

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

Sound manageable? Consider 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. There are over 5000 markets on offer.

How big is 2^63? If you were checking one billion combinations per second, it would take you about 292 years to check them all. That's why brute force search is completely impractical here.

Checking each combination one by one? Computationally infeasible.

Now look at the 2024 U.S. election. The research team identified 1,576 pairs of markets that could have dependencies. If each pair has 10 conditions, that's 2^20 = 1,048,576 combinations to check per pair. Multiply by 1,576 pairs. Your laptop would take so long to compute, the election results would already be out.

Integer Programming: Using Constraints Instead of Enumeration

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

They describe "which outcomes are valid" using Integer Programming.

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

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

How does Integer Programming handle this? Just three constraints:

· Constraint one: Exactly one of Duke's 7 markets 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 games).

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

Brute Force Search vs Integer Programming

In other words, brute-force search is like reading 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 violations of the rules.

Real data: 41% of market opportunities offer arbitrage [2]

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

• Checked 17,218 conditions

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

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

• 13 pairs of confirmed cross-market exploitable arbitrage

A median deviation of $0.60 means the market regularly deviates by 40%. This is not "close to efficient," this is "readily exploitable on a large scale."

Chapter 2: Bregman Projection—Calculating the Optimal Arbitrage Trade

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

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

Why "Euclidean Distance" Doesn't Work

The most intuitive idea is: find the closest "feasible price" to the current price and then trade the difference.

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

But there is a fatal problem: 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 completely different.

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

Imagine you are weighing yourself. Going from 70 kg to 80 kg, you might say, "I gained a bit of weight." But going from 30 kg to 40 kg (if you are an adult), that's "going from near death to severe malnutrition." Despite both being a 10 kg change, the meaning is entirely different. Prices work the same way—price changes closer to 0 or 1 carry more information.

Bregman Divergence: The Correct "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 measure is not Euclidean distance but Bregman Divergence.[5]

For LMSR, Bregman Divergence becomes KL Divergence (Kullback-Leibler Divergence)[6]—a metric of "informational distance" measuring between two probability distributions.

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

KL Divergence automatically gives more weight to "changes near extreme prices." A change from $0.05 to $0.15 is "farther" under KL Divergence than a change from $0.50 to $0.60. This aligns perfectly with our intuition—changes at extreme prices imply a greater informational impact.

A good example is the recent prediction market where, in the end, Axiom overtook Meteora, all driven by extreme price movements, as highlighted by @zachxbt.

Bregman Projection vs Euclidean Projection

Arbitrage Profit = Distance of Bregman Projection

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

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

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 arbitrageur made $2,009,631.76 in one year. [2] His strategy is to solve this optimization problem faster and more accurately than anyone else.

Convex Hull 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). The distance from your current position (current market price) to the river is a certain distance.

The Bregman projection helps you find the "shortest path from your location 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

All right, now you know: to calculate the optimal arbitrage, you need to perform a 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 full constraint set, meaning enumerating every valid result. 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 to not solving the entire problem at once, but gradually approximating the solution step by step.

Here's how it works:

Step 1: Start with a small known feasible set.

Step 2: Optimize on 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 it's close enough to the optimal solution. If not, go back to Step 2.

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

Frank-Wolfe Iteration Process

Imagine you're in a massive maze trying to find the exit.

The brute force way is to explore every path. Frank-Wolfe's way is: take a random path first, then at each intersection, ask an "advisor" (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 choices at each critical junction.

Integer Programming Solver: The "Advisor" at Each Step

Every round 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 solving times:

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

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

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

Why is the endgame faster? Because as the match outcomes become certain, the feasible solution space shrinks. With fewer variables and tighter constraints, the solution is found more quickly.

The Gradient Explosion Issue and Barrier Frank-Wolfe

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

The solution is Barrier Frank-Wolfe: instead of optimizing over the full polytope M, the optimization is done over a slightly "contracted" version of M. The contraction parameter ε adaptively decreases during iterations—starting further away from the boundary (stable) and gradually moving closer to the true boundary (accurate).

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

Real-World Performance

A key finding in the paper [2] was:

For 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 spread pricing by 38%.

The turning point is: when the outcome space shrinks to a point where 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 they get into the zone, they start dominating. LCMM is the student who consistently performs but has a limited ceiling. The key difference is: FWMM has a stronger "weapon" (Bregman projection), it just needs time to "reload" (wait for the solver to finish).

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

You've detected an arbitrage opportunity. You've calculated the optimal trade using Bregman projection.

Now you need to execute.

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 execute simultaneously.

Your arbitrage plan:

Buy YES at $0.30. Buy NO at $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 moved the market price.

· Submit NO order → Fill price $0.78 ✗

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

One leg filled, the other didn't. You got front-run.

This is why the paper only counts opportunities with a profit margin greater than $0.05. A smaller spread would be eaten by execution risk.

Non-Atomic Execution Risk

VWAP: The Real Trading Price

Don't assume you will fill at the quoted price. Calculate the Volume-Weighted Average Price (VWAP) [10].

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

VWAP is "the average price you actually pay." If you want to buy 10,000 tokens, but there are only 2,000 at $0.30, 3,000 at $0.32, and 5,000 at $0.35 on the order book—your VWAP is (2000×0.30 + 3000×0.32 + 5000×0.35) / 10000 = $0.326. It's significantly higher than the "best price" you see at $0.30.

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

Even if the price has a discrepancy, the profit you can earn is limited by available liquidity.

Real 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 to have liquidity in all positions simultaneously. The smallest one determines your limit.

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

Chapter Five: Complete System—What Was Actually Deployed

The theory is clean. The production environment is chaotic.

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

Data Pipeline

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

Historical Data: Query contract events via the Alchemy Polygon node API—OrderFilled (trade execution), PositionSplit (new token mint), PositionsMerge (token burn).

The research team analyzed 86 million trades [2]. This order of magnitude requires infrastructure, 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 want to experience the API firsthand, feel free to DM me anytime.

Dependency Detection Layer

For 305 U.S. election markets, there are 46,360 possible combinations to check. Manual analysis is not feasible.

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

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

This was followed by three layers of validation: Does each market have exactly one true condition? Are the valid combination count fewer than n × m (due to dependencies)? Do the dependency subsets meet the arbitrage criteria?

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

The accuracy of the LLM on complex multi-condition markets is 81.45%. It is sufficient for pre-screening, but manual verification is required before execution.

Three-Layer Optimization Engine

· Layer 1: Linear Constraint Minimization (LCMM). Quickly checks basic rules—"sum of probabilities equals 1," "if A implies B, then P(A) cannot exceed P(B)." Completed in milliseconds, eliminating 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% shrinkage), convergence threshold = 1e-6, time limit = 30 minutes. Typical iterations: 50-150 times. Solution time per iteration: 1-30 seconds.

· Layer 3: Execution Verification. Before submitting orders, simulate trades on the current order book. Check: Is the liquidity sufficient? What is the expected slippage? What is the guaranteed profit after accounting for slippage? Does the profit exceed the minimum threshold ($0.05)? Only proceed if all criteria are met.

Position Sizing: Enhanced Kelly Criterion

The standard Kelly formula [11] tells you how much of your funds to put into a trade. But in an arbitrage scenario, adjustments for execution risk need to be incorporated:

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 substantially move the market.

Final Result

From April 2024 to April 2025, total extracted profits:

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 arbitrators took home $8,127,849 (20.5% of the total). Top-ranked arbitrator: $2,009,632, from 4,049 trades, averaging $496 per trade^[2].

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

The Harsh Reality

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

They are detecting dependencies between 17,218 conditions through integer programming. They are calculating optimal arbitrage trades using Bregman projection. They are dealing with gradient explosions through 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 is mathematical infrastructure.

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

The question is: Can you build 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 be arbitrage-free. Can be understood as the "valid region of prices."

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

• Bregman Divergence / KL Divergence → A method of measuring the "distance" between two probability distributions, more suitable for price/probability scenarios than Euclidean distance. Weighted more heavily 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 enumerating exponentially many valid outcomes [7]

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

• CLOB (Central Limit Order Book) → Polymarket's order matching mechanism, where orders are 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 your funds to put into a trade to balance return and risk [11]

• Non-Atomic Execution → The issue where multiple orders cannot be guaranteed to execute simultaneously. One leg executes, the other doesn't = exposure risk

• DeepSeek → A large language model used for initial screening of market dependencies, with an accuracy of 81.45%

References

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

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

[3] Foundational 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] Introduction 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 Article 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