An event contract arbitrage bot needs to manage the period when a proposed combination is only partly real. A scanner can identify prices that appear attractive together, but an account receives individual orders and fills. One order may be accepted while another is rejected. A cancellation may arrive after an additional fill. A response can disappear even though the venue accepted the request. The bot must describe those states without pretending that the intended pair already exists.
The central design problem is coordination under uncertainty. Reserve the capacity needed for both legs, preserve their identities and measure the exposure that remains when they do not progress together. The fictional examples here use explicitly compatible one-dollar binary payoffs. They illustrate execution controls, not a claim that a real cross-venue trade can be completed atomically or that an apparent arbitrage has no risk.
Event Contract Arbitrage Bot Reservations Begin With an Approved Pair
The execution engine should receive a reviewed pair definition rather than two loosely related market names. That definition includes each venue context, contract identifier, outcome side, rule version and payoff relationship. It should also state which exceptional outcomes have been considered and which conditions invalidate the mapping. A contract pair whose meaning remains unresolved belongs in research, not in the executor's ready queue.
The candidate instruction adds current quantities, price ceilings, fee estimates and observation times. It names the maximum acceptable combined cost and the amount of unpaired exposure the account is prepared to tolerate. Those limits are distinct. A pair can be affordable if completed while its first leg creates too much temporary directional exposure for the account. Both questions need an answer before any order is submitted.
Use a durable case identifier to connect the definition, recommendation, authorization and eventual orders. Each leg should have its own stable instruction identity as well. The pair identifier explains why the orders belong together; the leg identifiers allow the system to investigate an individual submission. Neither should be replaced merely because a network request times out or a process restarts.
The older prediction market arbitrage bot article provides the broader relationship between a detected opportunity and a trading process. This design begins at the point where the payoff analysis has already been reviewed. Its job is to ensure that the account's actual combination remains visible as orders move through different states.
Reserve Local Funds and Shared Risk Capacity
Suppose a fictional pair calls for 500 units of A Yes at a maximum of $0.37 and 500 units of B No at a maximum of $0.60. Assume the rules make one unit of each a one-dollar combined payout in the modeled outcomes. Purchase amounts would total $185 and $300. With hypothetical fees of $3 and $4, total acquisition cost is $492, leaving $8 below the assumed $500 payout.
The bot needs $188 available for A and $304 for B under those assumptions. If the legs use separate accounts, the existence of $492 somewhere in the overall portfolio is insufficient. Each account needs its own usable capacity before execution. The reservation should include the appropriate charges and any additional recovery buffer chosen by the operator. The buffer is a control policy, not part of the projected profit unless it is actually spent.
At the portfolio level, reserve the relevant event exposure as well as cash. Several candidate pairs may all depend on the same event or the same second-leg venue. Allowing each case to reserve funds independently without checking shared limits can create an excessive accumulation of unfinished first legs. A common risk service or another consistent coordination method must prevent those cases from claiming the same remaining capacity.
Reservations should persist through uncertainty. An order rejected with authoritative confirmation can release its unused amount. An order whose response is missing cannot. A process restart should reload unresolved reservations before accepting new cases. Otherwise the program may appear to have a fresh budget while the accounts still contain commitments created during the previous session.
Choose an Execution Sequence Deliberately
Submitting both legs at nearly the same time reduces some sequencing delay but does not guarantee simultaneous acceptance or execution. Sending one leg first can simplify coordination but creates a period of known directional exposure. A system should choose its sequence based on observed liquidity, venue behavior and the account's permitted exposure, then evaluate the results of that choice rather than treating it as an implementation detail.
A common temptation is to execute the more difficult leg first. That may be reasonable for a tested workflow, but it still needs a defined response if the easier leg disappears. Another approach uses a resting order for one side and reacts to its fills. This can improve a quoted entry price while increasing the chance that the complementary price changes before the response. The relevant measure is the completed combination and its unfinished cases.
Single-order execution instructions do not create a cross-venue transaction. For example, an all-or-nothing instruction can constrain one leg on a venue that supports it, but it does not force another venue to fill its corresponding order. Polymarket's order lifecycle documentation describes several individual order behaviors. The bot must verify the actual supported behavior for each leg and avoid extending a local guarantee to the whole pair.
Document the chosen sequence in the case record. Record when each authorization was created, when each request was sent and what information was available before the second submission. This evidence allows later comparison of sequencing policies. Without it, a successful pair can obscure the same timing weakness that causes a costly partial execution in the next case.
Track Quantities at Every Stage
For each leg, distinguish requested, accepted, filled, cancelled and still-uncertain quantities. These numbers answer different questions. Requested quantity expresses intent. Filled quantity establishes a position. Open quantity can still increase that position. Uncertain quantity represents exposure the local system has not yet resolved. Combining them into a single completed percentage can hide the direction and size of the remaining risk.
A paired quantity is the amount for which the required positions have actually been acquired in compatible proportions. In the simple one-for-one example, if A has 500 filled and B has 300, the paired quantity is 300 and the unmatched A quantity is 200. If a more complex payoff requires a different ratio, the matching calculation must follow that reviewed ratio rather than assuming equality.
Keep the quantity calculation independent of cash balances. A balance change can include fees, transfers or unrelated trades, so it is a poor substitute for fill records. Store each fill's identifier, side, quantity and price, and deduplicate repeated delivery of the same fill. A replayed event should confirm existing information rather than create a second position entry.
The older Kalshi arbitrage bot guide can help frame account-side records for a venue-specific implementation. The general rule is that pair completion must be derived from actual leg quantities. A positive combined quote, a submitted batch or two acknowledged requests cannot establish the completed position on its own.
Event Contract Arbitrage Bot Partial Fills Create a New Decision
Continue the fictional example with all 500 A units filled at $0.37, but only 300 B units filled at $0.60. The purchase amounts are $185 and $180, totaling $365 before charges. Three hundred units form complete pairs, costing $291 before charges. The remaining 200 A units cost $74 and have directional exposure. The original projected $8 net result for 500 complete pairs no longer describes this account state.
The bot should stop evaluating the case solely by its original opportunity score. It now needs a recovery decision using current quotes and explicit limits. Can another 200 B units be acquired within an authorized total cost? Can the unmatched A units be sold within a permitted loss? Is temporary retention allowed, and for how long? Each option should use the actual existing position and live executable quantities.
Suppose the operator's written rule permits reducing unmatched A at a bid no lower than $0.34 after the remaining B order is confirmed cancelled. Selling 200 A units at that price produces $68. The account then holds 300 complete pairs, which pay $300 under the example's assumptions. Combined proceeds are $368 against the $365 purchase amount, leaving $3 before charges. If actual total charges for this path are $5, the final result is a $2 loss.
That loss is not evidence that the arithmetic for a fully completed $492 pair was wrong. It shows that the intended execution did not occur and recovery had a cost. The ledger should preserve both calculations. Evaluating only completed favorable pairs while excluding recovered partial cases would overstate the usefulness of the execution policy.
Refer & Earn USDC
Refer & Earn USDCOur affiliate program pays in real-time.
A Submission Timeout Must Retain Its Identity
When a request times out, the bot knows that the local communication failed. It does not necessarily know whether the venue accepted the order. Move the leg into an uncertain state, retain its reservation and query supported order and account records. Use the original client or venue identifiers where available. If those records cannot resolve the attempt immediately, the uncertainty remains part of the exposure calculation.
Do not create a new order simply because the desired quantity is not yet visible in the local position. The original order might be resting, partially filled or waiting in a venue-specific processing stage. A second instruction can duplicate the intended quantity. In a paired system, this can produce an overfilled leg even after the other side has completed, turning a nominally matched case back into directional exposure.
Event contract arbitrage bot recovery needs an escalation condition. After a defined period or a particular error, the system may disable new cases in the affected account and request operator review. This is a control response to missing evidence, not a declaration that the venue has lost the order. The record should state exactly what remains unknown and which queries or account snapshots have been inspected.
When the attempt is finally resolved, update the original case rather than hiding it behind a replacement record. If it was rejected, release the unused reservation. If it filled, incorporate the fills and recalculate the matched quantity. If it remains open, decide whether to retain or cancel it using the current case state. Every outcome should preserve the connection to the original authorization.
Cancellation and Replacement Need Their Own Boundary
Cancelling an order does not reverse fills that already happened. It also does not establish that no fill occurred while the cancellation request was in flight. The bot should keep monitoring the leg until it has enough authoritative evidence to determine the final executed quantity and the quantity no longer capable of execution. Releasing the full reservation immediately after sending a cancellation can understate the account's commitment.
A replacement order introduces a similar issue. If the old order might still be active, submitting the full intended quantity again can temporarily double the amount capable of filling. The executor needs a documented replacement policy consistent with the venue's actual behavior. That policy may require confirmation before replacement or reserve for any supported overlap. It should never rely on the local interface hiding the old order as proof that the venue removed it.
In the 500-versus-300 example, suppose another 40 B units fill during cancellation. The matched quantity becomes 340, and unmatched A falls to 160. A recovery sale of 200 A units based on the earlier snapshot would overcorrect the case, leaving excess B exposure. The recovery decision must therefore use a reconciled quantity state, or explicitly account for the uncertainty that remains.
The related event market trading bot article examines interruptions and scheduled changes more broadly. Paired execution adds a specific requirement: a control action on one leg can change what should happen on the other. The system must coordinate those updates through shared case state instead of letting each leg operate as an unrelated trading program.
Preserve a Recovery Budget Without Chasing Completion
A recovery budget defines how much additional cost or loss the system may accept to reduce an unfinished exposure. It should be distinct from the original entry threshold. The account may rationally accept a limited loss after a partial fill to avoid retaining a larger event risk, but that permission should be explicit. Otherwise a bot can justify almost any price by claiming it is completing an arbitrage.
Set the budget in terms the operator can review: maximum unmatched acquisition cost, maximum additional completion cost, maximum permitted reduction loss and the conditions requiring human judgment. A price ceiling for the second leg can be recalculated from the actual first-leg cost and the allowed outcome. The calculation should include actual charges already incurred and conservative estimates for the remaining action.
A budget is not an instruction to spend the full allowance. Compare available alternatives using current executable quantities. If cancellation and a small reduction restore an acceptable position, the system need not force completion of the original size. If no alternative fits the approved boundaries, pause and expose the unresolved position clearly. The account's remaining risk should be visible even when the bot cannot resolve it automatically.
The older Polymarket automated arbitrage bot discussion offers context for this separation between detection and controlled action. Recovery logic deserves its own evaluation dataset because it is invoked under conditions different from ordinary entry. The behavior that works in calm snapshots may fail when liquidity disappears precisely as the first leg fills.
Inventory Can Accumulate Across Several Cases
A bot may operate many pairs at once, but the account experiences their combined inventory. Two unfinished cases can leave exposure to the same outcome even when their pair identifiers differ. Aggregate positions and open commitments by event and by relevant adverse scenario. Do not assume that separate case records create independent risk limits.
An event contract market maker uses inventory to shape further quoting decisions. A paired bot benefits from the same awareness when unfinished legs remain in the account. New cases might reduce an existing imbalance, increase it or create a different exposure under exceptional outcomes. The risk gate should evaluate the resulting portfolio rather than treating every proposed pair as automatically neutral.
If the bot also participates in event contract market making, its resting quotes belong in the same exposure model. A quote created for liquidity provision can fill while the arbitrage engine is reserving capacity for a second leg. Separate budgets that ignore one another can both pass locally and fail at the account level. Shared reservations and consistent reconciliation are necessary even when the strategies have different goals.
Periodic reconciliation should compare the combined local model with authoritative positions, orders and charges. A case can be marked operationally closed only when its orders are resolved and its remaining position is correctly assigned. If a deliberate residual position is transferred to another strategy, record that transfer of responsibility. Removing the case from a screen should not remove its risk from the ledger.
Test the Cases That Would Change the Decision
Use incident replays that exercise coordination, not just successful order submission. One test should accept A and reject B. Another should partially fill B during a cancellation. A third should deliver the same fill twice. A fourth should restart the process after a submitted request but before its response is recorded. The expected result should specify quantities, reservations, permitted next actions and any required pause.
For the worked partial-fill case, verify the arithmetic independently: $365 spent, $68 recovered from reducing 200 unmatched A units, $300 received from the remaining compatible pairs and $5 in assumed actual charges produce a $2 loss. The test should not label the case a profitable 500-unit pair simply because that was the original recommendation. It should preserve the reason the result differs from the plan.
Also test the decision not to begin. Reject a pair with mismatched rules, insufficient local funding, stale depth or unresolved account state. These refusals are part of the bot's intended behavior. A system that passes only tests of active execution can still be unsafe because it has never demonstrated that it respects the conditions under which execution should be withheld.
The final review should be able to reconstruct every case from approved payoff relationship to reconciled account result. A paired-leg bot is useful when it makes incomplete combinations explicit, limits their consequences and preserves enough evidence to explain recovery. That is the practical standard for automation in a process where two attractive prices do not guarantee two completed trades.