Common Mistakes When Automating Prediction-Market Trading

Automation makes a research rule repeatable, including its mistakes. A script that runs without an exception can still use the wrong outcome, charge fees twice or interpret missing data as a valid quote. The useful question is which assumptions the experiment has actually checked, rather than whether a bot looks busy.

Confusing a price with an executable opportunity

A last trade, midpoint, best bid and best ask are different observations. Use the quote relevant to the intended action and record its size and age. Matching an external probability estimate to a displayed number does not establish an available trade after spread, fees, information delay and uncertainty in the estimate.

Normalize prices and quantities from the actual endpoint schema. A cents field and a dollar string should not be fed into the same calculation unchanged. Different payouts also need different payoff models. A contract's name or ticker is not sufficient evidence that it resolves exactly like another market.

Using a universal fee shortcut

Fee rules can change and can depend on series, liquidity role and rounding. Do not assume every maker receives a rebate or every venue charges the same percentage. Record the dated policy and the role assumed in the simulation. Include fees once in the ledger, rather than deducting an entry fee from both cost basis and realized profit without reconciling the result.

Banger's public package has its own named fee-model behavior. That behavior is not a guarantee that every historical or current venue invoice is reproduced. A difference between model costs and observed costs should be visible in the research report rather than hidden by a profitable summary.

Assuming retries are harmless

A timed-out write can have succeeded. Repeating it may create duplicate effects. Design retries around the operation's documented idempotency and reconciliation behavior, retaining the relevant request identity and checking authoritative status where supported. A generic retry-every-error loop is not a safe order protocol.

For reads, use bounded attempts and timeouts and respect the current rate-limit contract. A WebSocket is another delivery mechanism with subscription, authentication and buffering requirements; it does not mean unlimited capacity. Preserve gaps and stale intervals rather than treating a reconnect as proof of continuous observation.

Mistaking a risk threshold for a complete shutdown

Banger's actual RiskEnvelope includes max_position_usd, max_daily_loss_usd, max_open_positions and max_orders_per_minute. The cumulative position-cost and UTC-day loss checks are admission controls. A daily-loss rejection does not automatically flatten a held position, guarantee the eventual loss ceiling or prove that a worker has stopped.

Application stop intent, key revocation, worker termination, cancellation completion and position accounting are separate observations. A stopped badge alone cannot establish all of them. Keep a bounded acceptance procedure with an explicit stop and verified resource cleanup. Do not improvise destructive failure tests against production to make a research checklist look complete.

Treating a selected backtest as independent evidence

Keep the candidate markets, parameter trials, exclusions and failed runs. Use information available at the simulated decision time. Event labels completed later cannot be smuggled into earlier features. Evaluate later windows with frozen choices and report shared event exposures that make many apparent observations dependent.

There is no universal trade-count or Sharpe-ratio threshold that proves every event-contract strategy valid or invalid. Sensitivity can reveal a fragile result, but a discontinuity can also arise from genuine market rules. Investigate the mechanism and data instead of turning a numerical rule of thumb into a verdict.

Overstating the paper result

The public Banger product supports paper research. The packaged forward simulator can assume fills for non-crossing limits and does not reproduce every real queue or data delay. A successful paper run therefore demonstrates behavior under the stated simulation and feed assumptions, not verified live execution.

Before interpreting an experiment, record the version, resolved instruments, accepted parameters, data path, fees and fill policy, actual observations, errors and cleanup result. Zero-order and incomplete runs can be useful evidence. The aim is a reproducible explanation of what happened, including what the experiment could not establish.