Automated Arbitrage Execution: Do Bots Place Both Legs?

Search for whether any arbitrage bot places both legs and you will find a near-unanimous answer: no. The top-ranking guides tell you that fully automated arbitrage is a myth, that no bot works flawlessly, and that you will always end up placing at least one bet by hand. That answer is mostly right, and it is also incomplete. Placing both legs automatically is genuinely hard, but hard is not the same as impossible. This post explains exactly why automated arbitrage execution breaks, what a system needs to get it right, and which tools actually execute versus which only send you an alert.

The distinction matters because the whole value of an arb lives in the second leg. Detecting a price gap is trivial. Capturing it before it disappears is the entire job. A tool that finds a hundred arbs a day and leaves you to place two bets by hand on each one is selling you the easy half of the problem.

Does any software actually place both legs?

The honest answer: a few do, most do not. The tools with the biggest marketing budgets are detection products. OddsJam, BetBurger, and RebelBetting all find arbs and show them to you on a dashboard or push them to an alert channel. Not one of them places both bets for you. You click through to two bet slips and race the clock yourself. Our OddsJam vs Claw Arbs comparison breaks down that detection-versus-execution split in detail.

There is a smaller category of software that actually executes. Some of it is private and closed, built by trading teams who run it in-house and never sell it, so you will never see it on a review site. Some of it is public. Claw Arbs is built execution-first, which means it detects the edge and fires both legs automatically, then spends most of its engineering effort making sure the second leg lands. So the search results are right that automated arbitrage execution is rare. They are wrong that it does not exist. The reason it feels mythical is that the hard problem is not detection, it is the reliable second leg, and that is where most projects give up and ship an alert instead.

Why automated arbitrage execution is genuinely hard

Finding an arb is the easy part. Any decent scanner can compare prices across venues and flag when the combined implied probability drops below 100 percent. The hard part is turning that snapshot into two filled bets before the snapshot goes stale. Here is what goes wrong, and why an automated arb bot needs to plan for every one of these cases.

Odds move mid-execution

The arb you detected existed at one specific instant. The moment you start placing bets, you are in a race with every other participant and with the market itself. Sharp money moves lines. A goal, a red card, or a lineup change reprices everything at once. By the time your second leg reaches the venue, the price you needed may already be gone. On live in-play markets, the window between detection and expiry can be a few seconds or less, which is exactly why live in-play arbitrage is where execution speed matters most and where manual placing loses the edge every time.

A leg gets rejected or partially filled

You send an order for 500 contracts. The venue fills 300 and rejects the rest because the resting liquidity was thinner than the book showed, or because the order was fill-or-kill and could not complete at your price. Now your two legs are unbalanced: you are long more on one side than the other, and the "arb" is only partly hedged. Partial fills are one of the most common causes of a broken arb, and a naive bot that assumes every order fills completely will quietly build lopsided positions all day.

Rate limits and account limits

Every venue has limits. Prediction markets and exchanges enforce API rate limits: send too many orders too fast and you get throttled or briefly blocked, often right when you need to place the hedge. Soft sportsbooks add a second problem on top: they limit or close accounts that win. A consistent arber gets stake-factored down to a few dollars per bet, or gets bet acceptance delayed while a human trader reviews the wager. Either one can stop the second leg from landing at the size you need, which turns a clean arb into a half-filled position.

Liquidity can vanish between legs

The depth you saw when you detected the arb is not reserved for you. Another bot or a large trader can take it in the same millisecond you decide to act. You fire leg one, turn to leg two, and the price that made the arb work has been swept off the book. This is not a rare edge case. On the tightest, most profitable arbs the liquidity is thin precisely because everyone wants it, so the best opportunities are also the ones most likely to evaporate underneath you.

The naked leg: arbitrage's worst failure mode

Every one of the problems above leads to the same place. It is the failure mode that makes automated arbitrage genuinely dangerous rather than merely inconvenient, and it is the reason execution is a far harder problem than detection.

A naked leg is an open position on one side of an arbitrage with no matching hedge on the other side. Instead of a locked, market-neutral profit, you are left holding a one-directional bet you never intended to make.

Walk through a concrete $500 arb to see how a good system handles it. Suppose a two-way game, Team A versus Team B, throws off a cross-venue edge:

Kalshi: "Team A wins" is available to buy at $0.48 (48 cents), paying $1.00 if A wins.
Polymarket: "Team B wins" is available at $0.49, paying $1.00 if B wins.
Combined cost is $0.97 to lock a $1.00 payout, an edge of roughly 3 percent.

Size it at 500 contracts per side. Leg A costs 500 x $0.48 = $240. Leg B costs 500 x $0.49 = $245. Total staked is $485, and whichever team wins, exactly one side pays out $500. Locked profit before fees is about $15. That is the arb the scanner detected.

Now execute it. The bot fires leg A first on Kalshi and fills 500 contracts at $0.48. That is $240 committed. It turns to leg B on Polymarket, but in the roughly 30 milliseconds that elapsed, another taker swept the $0.49 offer. The best available price for "Team B wins" is now $0.53. Combined cost would be $0.48 + $0.53 = $1.01, more than the $1.00 payout. Firing leg B here locks a guaranteed loss of about a cent per contract, roughly $5, and worse if the price keeps sliding.

This is the decision point that separates a real execution system from a script. A naive bot fires the hedge anyway because it was told to complete the pair, and it books a certain loss. A slightly less naive bot skips the hedge and walks away, leaving 500 unhedged "Team A wins" contracts on the table: a $240 directional bet nobody asked for. Both outcomes are bad. Here is what a proper execution pipeline does instead:

The minimum-edge gate blocks the order. The bot will not knowingly place a hedge that turns the arb negative. The $0.53 price fails the check, so no order goes out at that price.
Because leg A already filled, the market is now flagged as carrying a naked leg. Naked-leg tracking marks the market and both engines halt every new trade on that game so the exposure cannot compound.
Retry logic keeps working the hedge for a short window, re-reading Polymarket depth. Prediction-market liquidity often refills within a second. Say "Team B wins" comes back to $0.50. Combined cost is now $0.98, still a locked profit of about $10. The bot completes the hedge, buying 500 at $0.50 for $250. Total staked $490, payout $500, profit $10. Smaller than the $15 you first detected, but a clean, fully hedged arb.
If no acceptable price appears inside the retry window, the bot does not chase a loss. It surfaces the naked position and applies the configured policy: flatten leg A to cap the downside, or hold it under strict risk limits. A per-market cooldown then stops the same game from firing again until conditions reset.

That single scenario is why automated arbitrage execution is a systems problem, not a scripting exercise. The edge math is arithmetic. Deciding what to do in the 30 milliseconds after one leg fills and the other slips is the actual product.

What real execution infrastructure needs

An automated arbitrage betting software that places both legs reliably needs a stack of components working together, each one guarding against one of the failure modes above. Miss any of them and you get naked legs.

Fast price feeds

You cannot act on a price you learned about a second too late. Real execution runs on streaming data, not polling a webpage every few seconds. Claw Arbs uses WebSocket feeds on Kalshi and Polymarket that surface book changes in around 25 milliseconds, and roughly 20-millisecond odds-change detection on bookmakers through DOM observation with community-shared configs. The whole point is to compress the gap between "the arb exists" and "the bot knows," because everything downstream inherits that latency.

Depth-aware sizing

An arb is only real up to the size the order book can absorb. If the best price only has 120 contracts behind it, sizing your leg at 500 guarantees a partial fill and a lopsided position. Depth-aware sizing reads the actual resting quantity at each price level and sizes both legs to what the thinner side can support, so the two legs stay balanced instead of assuming infinite liquidity.

Leg ordering

Order matters. You place the leg most likely to slip or reject first, then hedge into the more liquid, more reliable venue second. Fire the easy leg first and you are the one left exposed when the hard leg fails. Getting leg ordering right shrinks the naked-leg window before any other safety layer has to intervene.

Retry logic, cooldowns, and deduplication

When a hedge misses, the system should re-check depth and retry for a bounded window rather than either giving up instantly or chasing forever. Once a market has just fired, a per-market cooldown prevents it from re-triggering on the same stale signal and stacking positions. Deduplication makes sure the same opportunity, arriving twice through two feeds in the same instant, only ever fires once. Without dedup, a single arb can execute two or three times and blow past your intended size.

A kill switch and naked-leg tracking

Above every individual trade sits a safety layer. Exposure caps limit how much can be at risk on one market and across the book. Freshness checks reject stale sharp odds so you never hedge against a price that no longer exists. Naked-leg tracking marks any market where a leg is unhedged and halts new trades on it until the hedge completes. And a global kill switch stops all execution instantly when something looks wrong. Claw Arbs runs each candidate trade through a pre-trade safety pipeline built from exactly these checks: kill switch, exposure caps, minimum-depth checks, freshness checks, per-market cooldowns, deduplication, and naked-leg tracking with retry logic to complete the hedge. Every one of them exists to keep a broken leg from turning into a naked position.

You can test the entire chain before risking a dollar. A first-class paper trading mode runs the same detection and the same pipeline against live prices with simulated fills, so you can watch how the system behaves on real arbs, including the ones where a leg slips, before you ever turn on live execution.

Which arbitrage tools actually execute

Here is the honest split between detection-only tools and tools that place both legs, with current pricing so you can compare like for like.

Tool	Type	Arbitrage pricing	Places both legs?
OddsJam	Detection / alerts	Arb features in top Platinum tier, ~$400 to $500/mo	No
BetBurger	Detection / alerts	EUR 99.99 to 239.99/mo by plan	No
RebelBetting	Detection / alerts	GBP 89 to 169/mo by plan	No
Private / closed bots	Execution (in-house)	Not for sale	Yes, but you cannot buy them
Claw Arbs	Detection + execution	Free during testing period	Yes, both legs automatically

The pattern is clear. The mainstream commercial tools are all detection and alert products. They are good at what they do, and for a manual bettor they are worth the subscription, but none of them will place the second leg for you. That is not a knock on them so much as a statement about how hard reliable execution is: the companies with the most resources in this space still chose to ship alerts rather than an executor. For a wider breakdown of the paid options, see our guide to the best arbitrage betting software.

Private closed bots do exist. Trading teams and individual quants have built executors they run for their own accounts and never release. So it would be wrong to claim any single public tool is the only executing arb bot on earth. What is fair to say is that among software you can actually download and use, execution-first products are the exception, and Claw Arbs is one of them.

Why prediction markets are friendlier to automation

Not every venue is equally hard to automate, and this is the part most guides miss. The reason automated arbitrage betting struggles against classic bookmakers has less to do with the bot and more to do with the venue fighting back. Prediction markets are structurally friendlier to automation for a few concrete reasons.

Public APIs and readable order books. Kalshi and Polymarket both expose documented programmatic interfaces. Order placement is a supported, first-class feature, not something you reverse-engineer against a hostile site. Kalshi is a US-regulated venue under the CFTC, and Polymarket runs an on-chain central limit order book (a CLOB) where the full depth is visible. Because you can read the actual order book, depth-aware sizing is possible: the bot knows how much size a price can absorb before it commits.

No gubbing on peer-to-peer venues. Soft bookmakers make their money from recreational bettors and quietly restrict anyone who wins. Get flagged as an arber and your stakes get factored down or your account gets closed. On a prediction market you are trading against an order book and other participants, not against a bookmaker who dislikes losing to you, so a winning account does not get punished for winning. Longevity is the difference between a strategy that runs for years and one that gets limited in a month.

Clean settlement and defined edges. Contracts settle to $0 or $1 on a known event, so the edge math is exact once you account for costs. On prediction markets that means Kalshi's fee schedule and Polymarket's gas, plus a slippage buffer, all of which a bot can model precisely rather than guessing at a bookmaker's opaque margin.

This is why an automated arb bot aimed at prediction markets can genuinely place both legs at scale, while the same idea aimed at soft sportsbooks keeps running into account limits and manual review. It is also why a modern sports arbitrage bot tends to treat prediction markets and sharp exchanges as its core venues and treats soft books as a bonus rather than the foundation.

How Claw Arbs approaches automated execution

Claw Arbs was built execution-first, so the architecture starts from the second-leg problem rather than bolting execution onto a scanner. It ships with 12 venues pre-installed: the prediction markets Kalshi, Polymarket, Polymarket US, Predict.fun, and SX Bet, then the bookmakers Sportmarket, Stake.com, BC.Game, Cloudbet, Bet105, Pinnacle (PS3838), and BetInAsia. An 11-book sharp odds aggregator feeds the edge engine, and the goal across the whole stack is detection-to-execution in around 20 milliseconds.

When an edge appears, the bot fires both legs and runs every candidate through the pre-trade safety pipeline described above: kill switch, exposure caps, minimum-depth checks, freshness checks on the sharp odds, per-market cooldowns, deduplication, and naked-leg tracking with retry logic to finish the hedge. If a leg slips the way it did in the $500 example, the pipeline is what decides whether to complete the hedge at a still-profitable price, hold, or flatten, instead of blindly booking a loss. You can run all of it in paper trading mode first to confirm the behavior with zero risk. Watch real detected arbs stream in on the live arbitrage board to see the detection side in action.

None of this makes execution easy. It makes it handled. The market will still move against you mid-trade, legs will still occasionally reject, and liquidity will still vanish. The difference between a tool that alerts and a tool that executes is entirely in what happens in the milliseconds after that, and that is the problem worth solving.

FAQ

Does any software actually place both legs of an arbitrage automatically?

Yes, though it is rarer than the marketing suggests. Most mainstream tools (OddsJam, BetBurger, RebelBetting) are detection and alert products: they find the arb and you place both bets by hand. A smaller number of tools, including some private closed bots and execution-first platforms like Claw Arbs, actually fire both legs automatically. The reason full automation is uncommon is that placing the second leg reliably, before the price moves, is the hard engineering problem, not finding the arb in the first place.

What is a naked leg in automated arbitrage?

A naked leg is an open position on one side of an arbitrage with no matching hedge on the other side. It happens when the first leg fills but the second leg is rejected, partially filled, or moves to a losing price before it executes. Instead of a locked, market-neutral profit, you are left holding a one-directional bet. Preventing and unwinding naked legs is the single most important job of an automated execution system, which is why Claw Arbs marks the market as naked and halts all new trades on it until the hedge is completed.

Why is fully automated arbitrage execution so hard?

Because the market moves faster than most execution loops. Between detecting the arb and placing the second leg, the odds can move, the liquidity you saw can be taken by someone else, the venue can rate-limit or reject your order, or your account can hit a stake limit. Any one of those turns a locked arb into a naked leg. Real automated arbitrage execution needs fast price feeds, depth-aware sizing, sensible leg ordering, retry logic, cooldowns, and a kill switch, all working together in a few tens of milliseconds.

Are prediction markets easier to automate than sportsbooks?

Generally yes. Prediction markets like Kalshi and Polymarket expose public APIs and readable order books, so a bot can size to available depth and place orders programmatically as a first-class feature. They also do not limit or close winning accounts the way soft sportsbooks do, since you are trading against an order book rather than a bookmaker who dislikes losing to you. Classic bookmakers offer no official betting API and actively restrict winning accounts, which is why most automated tools stop at alerts on those venues.

Automated Arbitrage Execution: Does Any Software Actually Place Both Legs?