Skip to main content
boxmining
Menu

When the Winning Bet Still Loses: Spread, Slippage and Partial Fills

Michael GuMichael Gu
9 min read
Trading
Teal outcome token losing fragments between widening order-book jaws before emerging as a smaller settlement token
Contents

Suppose you estimate that a Yes outcome has a 60% chance. The market screen appears to show 54%. The event resolves Yes. Your forecast was directionally correct—so the trade must have been profitable, right?

Not necessarily.

You may have paid 61 cents because 54 cents was a midpoint, consumed several levels of a thin order book, received only a partial fill, paid a taker fee, or exited at a poor bid before resolution. A strategy can be right about the event and wrong about the trade.

This distinction matters even more for AI agents. Language models are naturally drawn to the headline prediction. Execution is where a promising probability estimate meets actual orders, liquidity, rules, and time.

For the general market-mechanics foundation before this venue-specific example, read The Order Book Is Not the Market and Anatomy of a Crypto Trade.

Four prices that should never be confused

Polymarket uses a central limit order book. Its price documentation distinguishes the prices visible around a market:

  • Best bid: highest resting price a buyer currently offers.
  • Best ask: lowest resting price a seller currently accepts.
  • Midpoint: average of best bid and ask.
  • Last trade: price of the most recent execution.

The displayed price is normally the midpoint, although Polymarket says it displays the last trade when the bid-ask spread is wider than $0.10. Neither display rule guarantees an executable price.

Imagine a hypothetical Yes book:

LevelBid sizeBidAskAsk size
1300$0.51$0.5780
2500$0.50$0.59120
3900$0.48$0.62400

The midpoint is $0.54, but an immediate buyer can purchase only 80 shares at $0.57. A 200-share buy would consume the first 80 at $0.57 and the next 120 at $0.59, for a volume-weighted average of $0.582 before fees. Calling this “buying at 54%” would be false.

These numbers are an illustration, not a historical Polymarket market.

Spread is an immediate hurdle

The spread is best ask - best bid. In the example it is six cents. If you buy at $0.57 and immediately sell into the $0.51 bid, you lose six cents per share before fees. The midpoint did not move; your executable round trip crossed the spread twice.

A forecast edge should therefore be compared with the correct side of the book. If your model estimates 60% for Yes, comparing it to the $0.54 midpoint suggests six percentage points of edge. Comparing it with the $0.57 ask leaves three points before fees, model error, and further slippage.

This is why “AI probability minus displayed probability” is not a trading strategy.

Slippage grows with size

Slippage is the difference between a reference price and the average price actually obtained. The reference must be stated. Slippage from midpoint, from best ask, and from the agent’s decision-time expected fill are three different measurements.

The public CLOB order-book endpoint exposes aggregate bid and ask levels, including price and visible size. A simulator can walk those levels:

remaining = intended_shares
cost = 0

for ask in asks_sorted_low_to_high:
    filled = min(remaining, ask.visible_size)
    cost += filled * ask.price
    remaining -= filled
    if remaining == 0: break

vwap = cost / (intended_shares - remaining)

If remaining is positive, the snapshot does not support a complete immediate fill within its visible depth. A conservative simulator rejects the rest or caps it at a declared maximum price. It should not pretend invisible liquidity exists.

Visible size can also disappear. Other traders may fill or cancel it between observation and arrival. A proper stress test applies latency and adverse-book scenarios rather than treating a snapshot as a promise.

A partial fill changes both exposure and strategy

An order for 1,000 shares filled for 70 shares is not a small bookkeeping issue. It changes:

  • maximum possible payoff;
  • average entry price;
  • portfolio hedge ratios;
  • whether the trade clears a minimum economic size;
  • whether a follow-up order is needed;
  • the agent’s remaining risk budget.

A live order can remain open, fill in pieces, expire, or be cancelled depending on its type and market activity. Polymarket’s order documentation explains that orders are limit orders and are monitored for balance, allowance, and cancellation validity. A paper ledger should model status changes, not jump directly from “submitted” to “filled.”

At minimum, keep:

intended_size
filled_size
unfilled_size
fill_prices_and_times
average_fill_price
fees
order_status
simulation_assumption

If the agent changes its forecast while an order is partially filled, the remaining order requires a new explicit decision. It should not be left alive just because the original prompt once approved it.

The queue-position problem

An order-book snapshot tells you aggregate quantity resting at each price. It does not prove where a hypothetical passive order would have ranked in the matching queue. If 5,000 shares are already bid at $0.50 and your paper agent adds 100 more, a later trade of 1,000 shares at $0.50 does not show that your order filled.

Historical public data may not reveal every cancellation, hidden change, network delay, and exact arrival ordering needed to reconstruct your counterfactual queue position. Therefore:

  • Observable: published bids, asks, sizes, timestamps, hashes, and trade events available in your archive.
  • Modelled: when your hypothetical order arrives and how book changes are sequenced between observations.
  • Unobservable or uncertain: exact historical queue priority and whether the counterfactual order would alter other participants’ behaviour.

Do not hide those categories inside one P&L number.

Use scenarios instead. A conservative passive-fill scenario may require traded volume at the price to exceed all quantity seen ahead of the order plus your size. A base scenario can apply a declared cancellation assumption. An optimistic scenario can assume favourable queue advancement. Report all three, never only the best.

“Market order” does not mean unlimited execution

Polymarket’s current create-order guide says all orders are expressed as limit orders; marketable execution is achieved by submitting a limit order at a price that crosses available liquidity. That limit still matters. It bounds the worst acceptable price.

For paper trading, define the same protection. “Buy Yes now” is incomplete. “Buy up to 200 shares, but no higher than $0.59, based on a book captured no more than two seconds ago” is testable.

This article is not providing live-order instructions. The principle is simply that every simulated order needs side, size, price bound, time constraint, and handling for the unfilled remainder.

Fees can erase a small edge

Fee assumptions must come from the market, not folklore. Polymarket’s current fee guide says taker fees apply in specified categories, makers are not charged, and fee parameters are determined per market. The fee varies with the share price and fee schedule.

Therefore, archive the fee schedule alongside the order-book snapshot. If testing an older trade, use the schedule in force then—not today’s rate. If the historical fee field is missing, run a range and label the uncertainty.

Also separate platform trading fees from other costs you choose to model, such as funding, conversion, withdrawal, tax, or infrastructure. Do not silently bundle them into “slippage.”

Resolution risk is not execution risk—but both affect P&L

Holding to resolution avoids an exit spread, but introduces contract and resolution exposure. Polymarket’s resolution guide explains that the rules specify the deciding source and edge cases, and that proposals can be disputed. Winning tokens redeem for $1 and losing tokens become worthless after resolution; rare outcomes can be more complex, including a 50/50 result in specified unresolved cases.

An agent that predicted the real-world event but misunderstood what the contract measures may still lose. That is not slippage. Label it as contract-interpretation or resolution error so the execution model does not take the blame for a forecasting failure.

A three-scenario execution audit

For every proposed trade, publish three ledgers:

Optimistic

  • decision-time visible depth remains available;
  • no adverse price movement during latency;
  • passive queue advances favourably;
  • documented fees still apply.

Base

  • immediate orders walk archived visible depth;
  • a declared latency is applied;
  • passive orders require evidence of sufficient subsequent volume;
  • partial fills remain partial.

Stressed

  • top level disappears before arrival;
  • spread widens by a declared amount;
  • only a fraction of passive size fills;
  • exit uses a weaker bid or the position remains to resolution.

The point is not to guess one “correct” counterfactual. It is to see whether the claimed edge survives reasonable execution uncertainty. If profitability exists only in the optimistic scenario, the conclusion should be fragile—not profitable.

What an AI agent must log

Before a paper order, the agent should save its probability, evidence, resolution-rule summary, decision time, book timestamp, intended size, and minimum required edge. Deterministic code should calculate fills and fees. Afterward, save every status change without rewriting the original intent.

Our guide to building a paper-first Polymarket agent shows this architecture. The time-locked experiment explains how to test forecasts separately from execution.

For venue background, see the Polymarket exchange review and our broader Technical Analysis section.

Polymarket execution FAQ

Why can a correct Polymarket prediction lose money?

The purchase price, spread, slippage, fees and partial fills can exceed the forecast edge even when the underlying outcome resolves as predicted.

Which Polymarket prices should not be confused?

Best bid, best ask, midpoint and last trade answer different questions. Only available bids and asks show immediate executable prices for a given size.

What is the bid-ask spread on Polymarket?

It is the gap between the highest visible buy order and lowest visible sell order, creating an immediate hurdle for entering and exiting.

What is slippage on Polymarket?

Slippage is the difference between a reference price and the average achieved when an order consumes available depth or the book moves before arrival.

What is a partial fill?

It occurs when only some requested shares execute. The remaining quantity may stay open, expire or be cancelled depending on the order instruction.

Why is passive queue position uncertain?

Aggregate book data does not show where a hypothetical new order would have ranked among orders at the same price, so a later touch does not prove a fill.

Does Polymarket support price protection for immediate orders?

All orders are expressed as limits. A marketable limit crosses available liquidity only up to its chosen worst acceptable price.

Does every Polymarket market use the same fee?

No. Fee applicability and parameters can vary by market and over time, so simulations should archive the correct market-specific schedule.

How should paper execution uncertainty be reported?

Publish optimistic, base and stressed ledgers with declared latency, depth, passive-fill, spread and exit assumptions instead of one falsely precise result.

What should an AI agent log before a Polymarket paper order?

Log probability, evidence, rule summary, decision and book timestamps, intended size, price bound, minimum edge, fee data and every later status change.

Sources and further reading

Risk disclosure: Prediction-market trading can result in total loss. Spreads, thin liquidity, latency, fees, partial fills, contract wording, and resolution disputes can materially change results. The examples here are hypothetical and the execution scenarios are models, not evidence of historical fills. This article is educational, not investment or legal advice, and it does not recommend live automated trading.

Share

Found this useful?

Share it with someone who'd want to read it.

Related