ZEIT FINANCE · BUILDING A POLYMARKET BOT

Part 1 Microstructure Before Math

��Docs: https://zeit-1.gitbook.io/zeit ☎️Telegram: https://t.me/zeitfi ** X**: https://x.com/ZEITFinance ** X2**: https://x.com/autonomous_af

Market Selection**:** Next (Part 2): coming soon

If you can code and you trade Polymarket, you’ve likely had this exact thought:

“In a multi-outcome market (like the US Election), one candidate must win. If I sum up the prices of all the candidates and they only add up to $0.98, that is free money. I just need to buy every outcome and wait for the $1 payout.”

That instinct is right in spirit: this is the classic NegRisk (Negative Risk) arbitrage.

But it fails in practice more often than it succeeds.

The first thing you learn when you try to automate is that Polymarket is not a continuous probability calculator. It is a trading venue with hard constraints.

Why most paper edge dies during execution

The idea is simple:

• “Sum(prices) < $1.00 looks like free money”

But the real world forces this path:

1. Filter 1: Auto-Arb mechanics Simple YES/NO arb is instantly crushed by the engine. Only multi-outcome NegRisk consistently survives this layer.

2. Filter 2: Tick grid Prices must be valid ticks. Rounding often goes against you. Thin margins disappear here.

3. Filter 3: Minimum sizes “Dust” legs force you to trade larger size, reaching deeper book levels. Edges vanish via slippage.

4. Filter 4: Execution risk FOK fails often. GTC gets legged and may require an unwind. This is where bots blow up.

Only after all of that do you have executable arb.

1) The Venue: A Hybrid CLOB

Polymarket is not an AMM like Uniswap. It operates as a Hybrid Central Limit Order Book (CLOB).

For a bot builder, that implies three things:

1. You trade against a distinct order book There are bids, asks, and discrete price levels for every single outcome.

2. Liquidity is specific, not pooled In a market with 10 outcomes, liquidity is split across 10 distinct order books (one per outcome). YES/NO for a single outcome is mirrored in one unified book (buying YES is functionally selling NO), but liquidity does not automatically flow between Outcome A and Outcome B.

3. Math is secondary The probability math doesn’t matter until you can reliably navigate the venue’s rules.

2) The Trap: The Myth of “Atomic” YES/NO Arb

Before building a NegRisk bot, you must understand why the simpler version (single outcome YES vs NO) is usually a trap.

You might think:

“I’ll find a market where YES is 0.40 and NO is 0.58, buy both instantly, and profit 0.02.”

This rarely exists because the system kills it automatically.

Polymarket’s matching engine and settlement system are designed to auto-arb this case. If you place a YES buy that crosses the implied NO, the system can effectively “mint” new complete sets to fill you.

What this means:

• Atomic arb is dead. The exchange (and sophisticated market makers) enforces the anchor YES + NO = $1 extremely quickly. You almost never find a static “free gap” sitting on the book.

• Legging is trading, not arb. You can buy YES at 0.40, then wait and buy NO later at 0.50. But that’s not arbitrage, it’s directional scalping. You’re exposed while you wait.

• The pivot: The real atomic opportunity lives where the system can’t easily auto-arb: Multi-outcome NegRisk (e.g., buying A, B, C, D, E because they sum to $0.95).

3) The Grid: Ticks and Quantization

The #1 reason “profitable” NegRisk bots lose money: they assume prices exist on a continuum.

They do not.

Prices live on a tick grid, exposed as tick_size.

If the tick size is 0.01, and your model sees an edge at 0.053, the exchange effectively says:

“That price does not exist.”

Quantization kills thin arbs

NegRisk means you’re buying N different legs (N outcomes).

• Cumulative error: you must quantize every single leg to a valid tick (often rounding up to the ask).

• Impact: if you have 10 candidates and lose even half a tick each, a 2% theoretical edge can become a 5% realized loss.

Rule: Quantize all N legs before deciding whether Sum(prices) < 1.

4) Sizing The Floor - Minimum Sizes

This is the constraint that surprises most first-time builders especially in NegRisk strategies with long shots.

The exchange enforces minimum order sizes, exposed as min_order_size.

Even if it looks like a simple “dust filter,” it creates major friction for low-probability outcomes.

Key effects:

• Dollar floor: $1 minimum notional. If a candidate is priced at $0.01, you can’t buy 1 share (1 cent). You must buy 100 shares to hit the $1 floor.

• Share floor: 5 shares minimum, regardless of price. You can’t buy 1 share of a $0.90 outcome “just to test the pipe.”

• You can’t just “buy $1 of everything.” You must buy equal payouts across outcomes.

The brutal implication: If the cheapest leg forces 100 shares (cost $1), you’re also forced to buy 100 shares of the favorite (cost $99).

So your minimum viable trade size is dictated by the cheapest leg.

On thin books, that minimum size can wipe available liquidity on the dust candidate, destroying the edge before you even begin.

5) Decide the Order Types

Once you’ve found a valid price and size, your next decision is crucial:

How do you submit the orders?

Your spreadsheet assumes you “buy.” The exchange forces you to choose between aggressive atomicity and passive liquidity.

The dilemma: FOK vs GTC

FOK (Fill-Or-Kill): the “atomic” choice “Execute the entire size at this price (or better), or do nothing.”

• Pro: Guarantees your math holds. You never get half a hedge.

• Con: High failure rate. If liquidity shifts by one share while you’re in flight, the entire trade fails.

GTC (Good-Til-Canceled): the “liquidity” choice “Post this order. Fill what you can now, keep the rest open.”

• Pro: Captures whatever liquidity exists.

• Con: Legging risk.

6) Execution: Legging Risk in N Dimensions

If you choose GTC (often necessary for larger sizes), you face the bot builder’s nightmare:

Non-atomic execution.

To lock NegRisk arb, you must buy all N outcomes.

If you buy N-1 and the Nth moves before filling, you’re no longer hedged you’re naked long the market.

The legging trap (example)

1. You identify a 5-candidate market summing to $0.98.

2. You send buys for Candidates 1–5.

3. Candidates 1–4 fill. Candidate 5 spikes from 0.10 → 0.15 because another bot hit it first.

4. Your total cost is now > $1.00. You have locked in a loss.

The emergency exit: Unwinding

Because you can’t execute all legs as one atomic on-chain transaction (you’re on an off-chain CLOB), eventually a leg will fail.

So your bot must include an unwind strategy (rollback):

• If legs_filled < total_legs after a short timeout (e.g., 500ms), immediately unwind filled legs by selling back to the bid.

• You’ll lose the spread on each unwound leg.

• If you’re lucky, you scratch (near break-even). Usually it’s a small controlled loss.

• That loss is the “insurance premium” you pay to avoid catastrophic directional exposure.

Summary: The Only Real Arb is "Executable Arb"

By now, the distinction should be clear: Probability math is the easy part; microstructure is the hard part.

The most common mistake new bot builders make is treating Polymarket like a spreadsheet. In reality, you are fighting a friction war.

• Atomic YES/NO arb is a mirage.

• NegRisk is the real prize, but it demands N-dimensional execution.

• Every constraint compounds (ticks + minimums + spreads) to erode your edge.

The Developer's Mandate

Your bot's primary job is not to find edge, but to validate execution.

Before committing capital, it must prove the profit survives the friction. Snap every price to the tick grid, force every size to the minimum, and assume the worst on slippage. If the math still holds after that stress test, you trade. If not, you pass.

Everything else builds on this foundation.

Next Steps

Part 2 will cover Market Selection: how to efficiently filter thousands of markets to find NegRisk candidates that are actually liquid enough to trade.

After that:

• L2 Depth

• The Two-Price Model (Profitability Price vs Execution Price)

• Optimizing your async execution loop to minimize legging risk

Follow on X: https://x.com/ZEITFinance Follow on X2: https://x.com/autonomous_af Join Telegram: https://t.me/zeitfi Read the Docs: https://zeit-1.gitbook.io/zeit

Continue the series:

• Part 1 - Microstructure Before Math → (this post)

• Part 2 - Market Selection → coming soon