I Analyzed 10M Polymarket Bot Trades with Claude: How Bots Make $1,000+ Daily

To the average trader, a short-term Polymarket market looks simple:

Will Bitcoin be higher or lower five minutes from now?

A trading bot sees a completely different problem.

It’s tracking the underlying price, time to expiry, liquidity on both sides, related markets, and its own live inventory - all at once:

• Subscribe to my Telegram channel for more✍️🤫: https://t.me/+VDXq5wkZ2AIxMDBi

Wallet link: https://polymarket.com/@bonereaper?via=dan-kwpx

While a human is still deciding whether to buy Up or Down, the bot may have already:

**> ingested a new price signal > repriced the outcome > compared it with the contract price > checked neighboring markets > posted multiple limit orders > reshaped its entire position**

That’s how some of these systems turn tiny pricing gaps into more than $1,000 in daily profit

I ran the activity of 1,000+ bots and more than 10 million executions across Polymarket’s short-duration crypto Up/Down markets through Claude.

At first, the trading looks completely chaotic. The same wallet buys Up, adds Down seconds later, sells part of the first position, and finishes the market holding both outcomes.

But once you reconstruct the full trade lifecycle, the noise starts to make sense. There’s usually a very specific system underneath it.

Here’s how the whole machine works 👇

1. Why trading Bots are used on Polymarket

The main advantage of a bot is not perfect Bitcoin forecasting

Its advantage comes from speed, consistency, and the ability to process more information than a human can realistically monitor at once:

Wallet link: https://polymarket.com/@0xb55fa1296e6ec55d0ce53d93b9237389f11764d4-1777575277609?via=dan-kwpx

A short-duration contract is not priced only by whether Bitcoin is currently moving Up or Down

The algorithm also needs to account for:

**> distance from the opening price > speed of the latest move > time remaining > current volatility > order-book depth > the prices of Up and Down > behavior across related markets > the exact feed used for resolution**

In a five-minute market, a real opportunity may exist for only a few seconds

A human may still be switching between charts while another algorithm is already taking available liquidity and replacing its orders

Most trading bots are built around five core components:

1. Data Layer - streams external prices and order-book updates
2. Signal Engine - detects changes that may affect the outcome
3. Probability Model - calculates an independent fair probability
4. Execution Engine - places, cancels, and adjusts orders
5. Risk Manager - controls position size and blocks trades that exceed predefined limits

One signal the Bot can calculate directly from the order book is the imbalance between buyer and seller volume:

1def orderbook_imbalance(bids, asks):
2    bid_volume = sum(size for price, size in bids)
3    ask_volume = sum(size for price, size in asks)
4
5    total_volume = bid_volume + ask_volume
6
7    if total_volume == 0:
8        return 0.0
9
10    return (
11        bid_volume - ask_volume
12    ) / total_volume
13
14bids = [
15    (0.48, 1_250),
16    (0.47, 920),
17    (0.46, 680)
18]
19
20asks = [
21    (0.49, 640),
22    (0.50, 510),
23    (0.51, 430)
24]
25
26imbalance = orderbook_imbalance(bids, asks)
27
28print(f"Order-book imbalance: {imbalance:.2%}")

A positive value means there is more buyer volume in the analyzed section of the book. A negative value means seller volume is larger. This signal alone does not prove that the price will move.

Large orders can be canceled, and liquidity located far from the best price may never affect execution.

But combined with Bitcoin’s movement, time remaining, and external price feeds, it becomes one part of a stronger signal.

A bot is not useful because it automatically trades every market movement. A strong system earns its edge by rejecting most setups before they ever become positions.

2. After receiving a signal, the Bot updates probability with Bayes 🧮

Suppose Up is trading at 41¢.

Bitcoin suddenly accelerates, volume increases, and the order book begins showing stronger buyer pressure.

A human may think:

This move looks strong.

Up

may be underpriced

The algorithm needs a more precise answer:

Exactly how much did this signal change the probability of

Up

?

This is where Bayes’ theorem comes in.

Wallet link: https://polymarket.com/@0xce25e214d5cfe4f459cf67f08df581885aae7fdc-1777575398144?via=dan-kwpx

Bayes allows the model to start with an existing probability and update it after receiving new evidence.

The formula is:

P(Up | Signal) = P(Signal | Up) × P(Up) / [P(Signal | Up) × P(Up) + P(Signal | Down) × P(Down)]

Where:

P(Up)

* is the probability before the new signal *

P(Signal | Up)

* is how often this signal appears before an Up result *

P(Signal | Down)

* is how often it appears before a Down result *

P(Up | Signal)

is the updated probability

Suppose:

the original probability of

Up

* is 41% this signal appears in 64% of historical *

Up

* scenarios the same signal appears in 35% of *

Down

scenarios

1def bayes_update(
2    prior_up,
3    signal_given_up,
4    signal_given_down
5):
6    numerator = signal_given_up * prior_up
7
8    denominator = (
9        numerator
10        + signal_given_down * (1 - prior_up)
11    )
12
13    return numerator / denominator
14
15prior = 0.41
16
17posterior = bayes_update(
18    prior_up=prior,
19    signal_given_up=0.64,
20    signal_given_down=0.35
21)
22
23print(f"Previous probability: {prior:.2%}")
24print(f"Updated probability: {posterior:.2%}")

The updated estimate is approximately 56%. If the contract is still trading at 41¢, the bot sees a measurable gap:

*internal fair value - 56% market price - 41¢ theoretical edge - 15 percentage points*

To a human, this may look like a strong trade idea. To a Bot, it is a specific difference between fair value and the current market price.

Bayes is not a prediction shortcut, however.

If the model gives too much weight to weak signals or counts the same information multiple times, the result will be consistently distorted.

A price move, a volume increase, and an order-book imbalance may look like three separate confirmations when they are actually three effects of the same event.

A strong model needs to account for that overlap.

3. A mispriced contract is not automatically a profitable trade

Even if the model values Up at 56%, buying it at 41¢ does not automatically create profit.

Real execution includes:

*> taker fees > bid-ask spread > slippage > partial fills > price deterioration > model uncertainty*

The bot therefore calculates net edge - the advantage that remains after the position is actually executed.

1def calculate_net_edge(
2    model_probability,
3    execution_price,
4    fee,
5    slippage,
6    safety_buffer
7):
8    gross_edge = (
9        model_probability - execution_price
10    )
11
12    net_edge = (
13        gross_edge
14        - fee
15        - slippage
16        - safety_buffer
17    )
18
19    return gross_edge, net_edge
20
21gross, net = calculate_net_edge(
22    model_probability=0.56,
23    execution_price=0.47,
24    fee=0.017,
25    slippage=0.005,
26    safety_buffer=0.010
27)
28
29print(f"Gross edge: {gross:.2%}")
30print(f"Net edge: {net:.2%}")

The original nine-point gap falls to roughly six points after costs.

If liquidity is limited, the bot may only fill a small portion of the position at 47¢. The remaining size may need to be purchased at a higher price.

The edge can disappear before the full position is built. The same logic applies to binary arbitrage.

If equal quantities of Up and Down can be acquired for less than $1 after all costs, one side will eventually pay $1.

But the system must use the real volume-weighted execution price, not simply the most attractive price visible at the top of the order book.

This is where a clean backtest and live execution often produce very different results. A human notices an unusual price. A Bot must prove that enough value remains after the market costs are included.

4. The best edge often exists between related markets 🕸

Short-duration contracts do not move in isolation.

One Bitcoin move can affect all of the following:

> the current

BTC

* 5m window > the next five-minute window > *

BTC

* 15m > *

BTC

* 1h > related *

ETH

and

SOL

markets

But these markets do not always update at the same speed.

Each contract has its own order book, liquidity, opening level, and participants.

For example:

>

BTC

* 5m may reprice immediately > *

BTC

* 15m may respond less than expected > a neighboring window may retain its previous book imbalance > one contract may become expensive > another may continue trading on outdated assumptions*

Wallet link: https://polymarket.com/@flippingsharks?via=dan-kwpx

The bot measures whether the gap between related markets has moved outside its normal range.

One simple tool is a z-score:

Z = (current spread − average spread) / standard deviation

1def spread_zscore(
2    current_spread,
3    average_spread,
4    spread_deviation
5):
6    return (
7        current_spread - average_spread
8    ) / spread_deviation
9
10z = spread_zscore(
11    current_spread=0.112,
12    average_spread=0.036,
13    spread_deviation=0.025
14)
15
16print(f"Spread z-score: {z:.2f}")

A reading above 3 means the current gap is far outside the range the model usually observes.

That does not automatically create a trade. One market may genuinely be lagging. Or the market that moved first may have already incorporated information that neighboring contracts have not processed yet.

A Bot also cannot compare BTC 5m and BTC 15m only by looking at their Up prices.

They have different opening levels and different amounts of time remaining.

A serious system compares how far each contract has moved away from its own fair-value model.

A human watches one market. A bot watches a network of connected probabilities and identifies the part that has temporarily moved away from the rest.

5. Five ways Bots turn edge into a position 🔄

Once the signal has been confirmed, probability has been updated, and the net edge remains positive, the most interesting stage begins.

The bot must decide how to build and manage the position.

After grouping individual executions into complete trading cycles, five recurring models appeared.

1️⃣ Dynamic Position Rotation

This system continuously updates its view and may change direction several times inside the same contract. Suppose the model considers Up underpriced at the beginning of a five-minute market.

It begins accumulating Up through limit orders.

Then the setup changes:

Bitcoin

* loses momentum price moves back toward the opening level buyers disappear from the order book the model’s *

Up

probability declines

The bot does not have to hold the original position until resolution. It can sell part of its Up, cancel the remaining orders, and begin accumulating Down.

If the market changes again, the position can be rebuilt once more. The objective is not to identify the final outcome perfectly on the first attempt.

The objective is to remain more exposed to whichever side is currently priced below the model’s updated estimate.

The strength of this approach is that the bot can abandon an outdated view immediately.

The main weakness is repeated false reversals.

During a noisy window, the system may:

buy

Up

* after a move higher reduce it after a pullback switch into *

Down

* reduce *

Down

after the next move higher

Execution costs and repeated position changes can gradually remove the original advantage.

A rotation bot should therefore change direction only when the new signal is strong enough to cover the cost of exiting, rebuilding the position, and potentially being wrong again:

Wallet link: https://polymarket.com/@trinity42?via=dan-kwpx

2️⃣ Temporal Arbitrage

Traditional arbitrage appears when Up and Down can be purchased at the same time for less than $1.

Temporal arbitrage builds the two sides at different moments. Imagine Bitcoin moving sharply higher shortly after the market opens.

Down falls to 26¢, and the bot gradually accumulates 750 contracts at an average price of 27.4¢. Two minutes later, Bitcoin gives back most of the move and trades closer to the opening level.

Now Up becomes cheaper, and the bot purchases 750 Up at an average price of 49.8¢.

The final structure is:

*750 Down at 27.4¢ 750 Up at 49.8¢ total cost per complete pair - 77.2¢*

Regardless of the final outcome, one contract in every pair pays $1. That creates a gross margin of 22.8¢ per pair before fees and execution costs. The key detail is that Down at 27.4¢ and Up at 49.8¢ were never available at the same time.

The bot created the arbitrage from two different market states. However, the first purchase is still exposed to directional risk.

If Bitcoin continues moving higher, the bot may never receive a sufficiently attractive Up price to complete the pair.

It would then remain with 750 Down contracts that continue losing value.

The system therefore tracks:

*quantity held on each side average cost of both outcomes cost of the already protected inventory size of the unpaired directional position maximum time allowed to wait for the second side*

Some bots build the structure in smaller blocks.

They may purchase 100 Down, wait until they can add 100 Up, complete the first protected pair, and only then continue increasing size.

This reduces maximum potential return but also limits the risk of being left with a large one-sided position.

Temporal arbitrage performs best in markets with several meaningful moves in both directions.

A prolonged one-directional move is its most difficult environment:

Wallet link: https://polymarket.com/@garvy?via=dan-kwpx

3️⃣ Inventory Market-Making Bot

This system does not manage a single position. It manages an entire inventory of contracts.

It may trade:

*BTC, ETH, and SOL 5m, 15m, 1h, and 4h markets both Up and Down across multiple windows*

The bot buys and sells in small amounts while continuously tracking the total cost of its inventory. Suppose it has accumulated both sides of one contract. Near expiry, Down becomes the clear favorite and moves to 98¢.

Instead of simply waiting for resolution, the bot may:

*sell part of the expensive Down inventory free up capital before settlement keep the remainder of the main position purchase a small amount of Up at 2¢ move the available capital into another market*

Purchasing the low-priced side may initially appear unusual.

But a small position at 1–2¢ can act as inexpensive protection against a sudden final move. If nothing changes, the cost is limited. If Bitcoin unexpectedly crosses the opening level, the small Up position can offset part of the loss elsewhere.

The inventory bot can also take advantage of differences between related markets.

One contract may offer a good entry price. Another may provide deeper liquidity for an exit. A third may offer the opposite side at an unusually low price.

The main challenge is the average cost of the complete inventory.

If the average Up cost is 56¢ and the average Down cost is 49¢, one protected pair costs $1.05.

Resolution only pays $1.

To recover that five-cent difference, the system needs additional gains from selling expensive inventory, maintaining a controlled directional imbalance, earning maker rebates, or moving capital more efficiently across markets:

Wallet link: https://polymarket.com/@polkadot-frog?via=dan-kwpx

4️⃣ Hedged Directional Bot

This structure sits between pure arbitrage and a fully directional position.

Suppose the bot holds:

*280 Up 257 Down*

The first 257 Up and 257 Down form a protected base. Regardless of the final outcome, one side of this block pays $257. The remaining 23 Up contracts create a directional lean.

If Up becomes the final result, those additional contracts increase the payout. If Down becomes the final result, the opposite position covers most of the exposure.

The system is effectively saying:

My model currently favors Up, but I do not want the entire position to depend on one outcome.

The size of the imbalance can change throughout the market. When confidence increases, the bot adds more Up. When the signal weakens, it reduces Up or purchases additional Down.

Holding both sides does not automatically make the structure efficient.

If the protected pairs were built above $1, they create a guaranteed negative margin.

Suppose the average pair cost is $1.04. The extra 23 Up contracts must first recover the loss on the protected base, along with fees and slippage.

Only after that does the complete position become profitable.

In some cases, an expensive hedge is less efficient than maintaining a smaller directional position:

Wallet link: https://polymarket.com/@uuddlrlr?via=dan-kwpx

5️⃣ Late-Resolution Capture Bot

The final model focuses almost entirely on the closing stage of the market.

When one outcome is close to being determined, the likely final side may still trade at 98–99¢. The bot purchases the remaining available volume and waits for the $1 payout.

For example:

*entry at 98.6¢ payout at $1 gross profit - 1.4¢ per contract*

The return from each operation is small, so the system scans a large number of markets and uses substantial volume.

The strategy may appear highly predictable, but its return profile is very uneven.

If 99 operations generate one cent each and one 99¢ position resolves incorrectly, the earlier gains can disappear.

That one incorrect execution may result from:

*a sharp final-second move a difference between price feeds an incorrect opening level a delayed resolution update a misunderstanding of the market rules an order remaining active for too long*

A late-resolution system therefore needs more than speed.

It must know exactly which feed determines the outcome and how far the current value is from the contract boundary.

The final position structure can be analyzed programmatically.

1def inspect_position(
2    up_quantity,
3    down_quantity,
4    up_average_price,
5    down_average_price
6):
7    protected_pairs = min(
8        up_quantity,
9        down_quantity
10    )
11
12    directional_up = max(
13        up_quantity - down_quantity,
14        0
15    )
16
17    directional_down = max(
18        down_quantity - up_quantity,
19        0
20    )
21
22    pair_cost = (
23        up_average_price
24        + down_average_price
25    )
26
27    return {
28        "protected_pairs": protected_pairs,
29        "extra_up": directional_up,
30        "extra_down": directional_down,
31        "average_pair_cost": pair_cost,
32        "pair_margin": 1 - pair_cost
33    }
34
35position = inspect_position(
36    up_quantity=280,
37    down_quantity=257,
38    up_average_price=0.51,
39    down_average_price=0.46
40)
41
42print(position)

But a final snapshot still does not reveal the complete strategy.

To understand the system, you need to know how the position was built, which parts were sold, and how the average cost changed over time.

6. Finding mispricing is not enough — the bot still has to capture it 🎯

Suppose the bot finds an opportunity to purchase Up and Down for a combined 94¢. It submits both orders. Up fills completely.

Before Down fills, the market moves, available liquidity disappears, and the second side becomes more expensive.

The arbitrage no longer exists.

The bot is now holding an open directional Up position.

This is inventory risk.

A strong system cannot simply identify unusual prices. It must manage the entire execution process.

It needs to decide:

*how long to wait for the second side when to adjust the limit order how much imbalance is acceptable when to remain a maker and when to execute as a taker whether to reduce the first side after the edge disappears*

One way to handle this is through logic inspired by the Avellaneda–Stoikov model.

The central idea is simple: the acceptable quote should change based on the inventory already held.

A simplified formula is:

Reservation price = Fair price − Inventory × Risk × Volatility² × Time

1def reservation_price(
2    fair_price,
3    inventory,
4    risk_aversion,
5    volatility,
6    time_remaining
7):
8    inventory_adjustment = (
9        inventory
10        * risk_aversion
11        * volatility ** 2
12        * time_remaining
13    )
14
15    return fair_price - inventory_adjustment
16
17quote = reservation_price(
18    fair_price=0.57,
19    inventory=0.40,
20    risk_aversion=0.80,
21    volatility=0.18,
22    time_remaining=0.25
23)
24
25print(f"Inventory-adjusted quote: {quote:.3f}")

If the bot already holds too much Up, it should become less willing to purchase additional Up.

At the same time, it can become more aggressive when acquiring Down to reduce the imbalance.

Order type also matters:

GTC

* remains active until filled or canceled *

GTD

* expires at a specified time *

FOK

* fills completely or is canceled *

FAK

* fills the available amount and cancels the remainder *

Post-only

ensures the order adds liquidity

In a five-minute market, execution quality can matter more than the initial forecast.

The model can estimate fair value correctly and still lose money if the position is built too slowly or at an inefficient average price.

7. The final layer is position sizing and capital protection 🛡

A strong edge does not justify allocating all available capital to one market.

There is always a possibility that:

*the model overestimated the signal the second side does not fill liquidity disappears the average execution is worse than expected several correlated positions lose value together*

A common starting point for position sizing is the Kelly criterion.

The formula is:

f = (b × p − q) ÷ b

\*

Where:

p

* is the probability of success *

q = 1 − p

* is the probability of failure *

b

* is the net payout relative to the amount at risk *

f

\ is the full-Kelly capital fraction*

In practice, many systems use only a fraction of the result.

1def fractional_kelly(
2    win_probability,
3    entry_price,
4    fraction=0.25
5):
6    lose_probability = 1 - win_probability
7
8    net_odds = (
9        1 - entry_price
10    ) / entry_price
11
12    full_kelly = (
13        net_odds * win_probability
14        - lose_probability
15    ) / net_odds
16
17    return max(
18        full_kelly * fraction,
19        0
20    )
21
22allocation = fractional_kelly(
23    win_probability=0.61,
24    entry_price=0.50,
25    fraction=0.25
26)
27
28print(f"Capital allocation: {allocation:.2%}")

Fractional Kelly lowers the chance that one inaccurate model estimate or poor execution causes major damage to the strategy.

The system then applies hard limits:

*maximum size per position maximum exposure per asset limit on unhedged inventory daily loss limit emergency shutdown when data becomes unreliable*

Correlation also matters.

BTC 5m, BTC 15m, ETH 5m, and SOL 5m may appear to be separate markets, but during a broad crypto move they can all lose value at the same time.

The risk manager’s role is not to maximize the size of every attractive opportunity.

Its role is to make sure one scenario cannot remove the system’s ability to continue operating.

8. What the complete bot stack looks like ⚙️

A modern Polymarket bot is not a single Python script comparing Binance with the Up price.

It usually operates across several layers.

Layer 1 - Market Data

External prices, the official resolution feed, live order books, recent executions, and the status of the bot’s own orders.

Layer 2 - Signals

Price movement, volume, volatility, book imbalance, and dislocations between related markets.

Layer 3 - Probability

The model updates fair probability whenever meaningful new information arrives.

Layer 4 - Position Logic

The system chooses between rotation, temporal arbitrage, inventory management, a directional hedge, or late-resolution execution.

Layer 5 - Execution and Risk

Orders are placed, canceled, and adjusted while inventory and position size remain within predefined limits.

Layer 6 - Research

Claude is used to analyze trading history, identify recurring structures, write backtests, and study unsuccessful trading cycles.

The high-level loop can look like this.

1async def run_bot():
2    while True:
3        state = await receive_market_update()
4
5        signal = build_signal(state)
6        probability = update_probability_model(
7            state,
8            signal
9        )
10
11        edge = scan_for_edge(
12            state,
13            probability
14        )
15
16        if not edge["tradable"]:
17            continue
18
19        position_plan = choose_position_model(
20            state,
21            edge
22        )
23
24        orders = build_execution_plan(
25            state,
26            position_plan
27        )
28
29        if risk_manager_approves(
30            orders,
31            state
32        ):
33            await send_orders(orders)

Claude can help identify which structures repeat across millions of historical executions.

But the low-latency trading loop itself should remain deterministic: receive the data, apply the rules, check the limits, and submit the order.

Conclusion: profitable bots do much more than choose Up or Down

Short-duration markets appear to be simple directional contracts.

A profitable system performs a much longer sequence:

*receives a new signal converts it into a probability checks net edge compares related markets selects a position structure manages execution limits risk*

Some Bots rotate between Up and Down several times inside the same window. Others accumulate both sides at different moments. Some manage a large inventory across several timeframes. Others maintain a protected base with a small directional lean.

A separate group focuses on capturing the remaining price difference shortly before resolution.

But the core formula is usually similar:

*reliable data an independent probability estimate edge after costs the right position structure precise execution controlled risk*

These Bots do not know where Bitcoin will be in five minutes.

They are simply faster at calculating what each possible outcome should be worth right now.

Thank you for viewing my article, I would be grateful for feedback!

Follow me on X✌️: https://x.com/Dan1ro0**

Join my Telegram for more**✍️: https://t.me/+VDXq5wkZ2AIxMDBi