Your Polymarket Bot Found a 20-Point Edge. Why Might It Still Lose Money?

Your model estimates that a YES outcome has a 70% chance of winning.

Polymarket is offering shares at $0.50.

Your bot calculates the difference, identifies a 20-percentage-point edge and prepares to buy.

On paper, this looks like an excellent opportunity.

But what if the model is wrong? What if the price changes before the order fills? What if fees and execution costs consume part of the advantage?

The bot may have found a profitable-looking trade without finding a profitable one.

This is one of the most important distinctions in automated prediction-market trading: an estimated edge is not the same as a realised edge.

First, understand what the 20-point edge means

For a simplified binary market, a winning share pays $1 and a losing share pays $0.

Suppose your model estimates the probability of YES at 70%, while the price to buy a share is $0.50.

The estimated expected profit per share, before costs, is:

[EV = (p \times 1) - C]

Where:

• (p) is your estimated probability of winning.
• (C) is the purchase price.

For this example:

[EV = (0.70 \times 1) - 0.50 = $0.20]

The estimated expected profit is $0.20 per share before fees and other costs.

The difference between the estimated probability and the purchase price is 20 percentage points. That is the hypothetical edge in this example.

But notice the assumption hidden inside the calculation: the 70% probability estimate must be reasonably accurate.

If your model consistently overestimates the likelihood of an outcome, the calculation can look attractive while the strategy loses money over time.

1. Your model might be confidently wrong

A model can produce precise probabilities without producing accurate probabilities.

Imagine your bot assigns a 70% probability to hundreds of outcomes. If those estimates are well calibrated, outcomes assigned a 70% probability should occur approximately 70% of the time across a sufficiently large, representative sample.

If they occur only 55% of the time, the model is systematically too optimistic for that group of predictions.

Consider what happens to the example trade if the true probability is 55%, not 70%.

[EV = (0.55 \times 1) - 0.50 = $0.05]

The expected profit falls from $0.20 to $0.05 per share before costs.

If the true probability is 45%, the expected value becomes negative:

[EV = (0.45 \times 1) - 0.50 = -$0.05]

The bot's original calculation did not fail mathematically. Its probability estimate failed to describe reality accurately enough.

This is why strategy evaluation should examine probability calibration, not just whether the model generates impressive-looking opportunities.

1. The price may change before your order fills

A signal is calculated using information available at a particular moment. An order is executed later, under whatever market conditions exist when it reaches the order book.

Suppose your model estimates a 70% probability, but the executable price rises from $0.50 to $0.64 before your bot can buy.

Your expected profit per share becomes:

[EV = 0.70 - 0.64 = $0.06]

The estimated advantage has fallen from $0.20 to $0.06 per share before costs.

That is a substantial change.

The midpoint displayed by a market-data feed is not necessarily the price available for your intended order size. The spread, order-book depth and market movement can all affect the actual execution price.

A bot should therefore evaluate the price it can realistically obtain, rather than assume that the price observed when the signal was generated will still be available.

1. Costs can consume the remaining edge

Let's continue with the $0.64 entry price and 70% estimated probability.

The estimated expected profit is $0.06 per share before costs.

If the total expected cost is $0.02 per share, including applicable fees and estimated execution costs, the remaining expected profit is:

[EV_{\text{net}} = 0.70 - 0.64 - 0.02 = $0.04]

The expected profit is now $0.04 per share.

Those costs are hypothetical; actual fees and execution costs depend on the market and trading conditions. A production bot should calculate or estimate the relevant costs for its specific orders.

It should also avoid counting the same cost twice. For example, if the execution price already incorporates a particular component of price impact, that component should not be deducted again as a separate expense.

The point is not that every trade with a small edge is bad. It is that the edge must be large enough to justify the costs and uncertainty involved.

1. Turn the calculation into a decision rule

A bot should not merely calculate expected value. It should use the result to decide whether a trade meets the strategy's requirements.

Here is a small Python example:

def evaluate_trade(
estimated_probability,
entry_price,
estimated_cost_per_share=0.0,
minimum_net_edge=0.0,
):
if not 0 <= estimated_probability <= 1:
raise ValueError("Probability must be between 0 and 1")

if not 0 < entry_price < 1:
    raise ValueError("Entry price must be between 0 and 1")

if estimated_cost_per_share < 0:
    raise ValueError("Estimated costs cannot be negative")

if minimum_net_edge < 0:
    raise ValueError("Minimum edge cannot be negative")

gross_edge = estimated_probability - entry_price
net_edge = gross_edge - estimated_cost_per_share

return {
    "gross_edge": gross_edge,
    "net_edge": net_edge,
    "eligible": net_edge >= minimum_net_edge,
}

result = evaluate_trade(
estimated_probability=0.70,
entry_price=0.64,
estimated_cost_per_share=0.02,
minimum_net_edge=0.03,
)

print(result)

The result indicates a net estimated edge of $0.04 per share and marks the trade as eligible under the illustrative three-cent threshold.

This is a decision-rule demonstration, not a complete trading bot. It assumes a valid probability estimate, a realistic entry price and a reasonably accurate cost estimate. It does not account for position sizing, correlated exposures, model uncertainty or order execution failures.

Those requirements belong in the wider trading system.

1. Test whether the edge survives outside your development data

A strategy can look excellent on historical data because its parameters were selected to fit that particular period.

If you repeatedly adjust the model until its backtest looks profitable, you risk building a strategy that describes the past better than it predicts the future.

A more credible evaluation separates development data from later, unseen data.

Use the development period to build the strategy. Freeze its parameters before evaluating it on the holdout period. Account for realistic execution prices and costs, and avoid using information that would not have been available when each historical decision was made.

Then examine more than total profit.

Look at drawdowns, trade count, probability calibration, performance across market conditions and how sensitive results are to small changes in assumptions.

A strategy that remains plausible under reasonable variations is more convincing than one whose profitability disappears as soon as the assumptions become slightly less favourable.

Even then, a successful historical evaluation is not a guarantee of future returns.

The real objective is to measure the edge you can actually capture

A Polymarket bot can calculate probabilities, identify price differences and submit orders. None of those capabilities independently proves that the underlying strategy is profitable.

The useful question is whether the probability estimates are credible, the entry prices are achievable and the remaining advantage justifies the costs and risks.

That requires a system designed to measure its own decisions—not merely execute them.

At "Dexoryn Labs" (https://dexorynlabs.com), we build Polymarket trading bots and custom automation around specific strategy requirements.

If you're developing a trading bot, start by testing the assumptions behind its edge before increasing its trading activity or capital allocation.

Finding an edge is a hypothesis. Proving that you can capture it is the engineering problem.