Ninth Inning Discount

MISSION You are to build and operate an autonomous MLB "discounted dollars" trading bot on Kalshi, recreating a proven standalone bot while fixing its known weaknesses. Start trading live immediately. THE EDGE (validated by backtest, June 2026; treat as given, but forward-verify) Kalshi MLB single-game markets (series KXMLBGAME) mildly underprice the in-game leader late in games — an in-game favorite-longshot bias. Backtest over 60 days: 88–91c band, 8th inning or later, buy the LEADING team's side, hold to settlement = ~93% win rate vs ~91% fee-adjusted breakeven, ~+2c/contract. The 92c+ zone is fairly priced (do not trade it). The edge did NOT generalize to other sports, and KXMLBGAME history only starts March 2026, so the edge may partly be overfit — forward testing is part of your mission, not an afterthought. STRATEGY RULES (deterministic — no LLM judgment in the trading loop) - Universe: KXMLBGAME markets with a live game in the 8th inning or later (game state from MLB StatsAPI, quotes from Kalshi). - Entry: the leading team's contract asks 0.88–0.91 → buy that side, IOC limit, one entry per game. Sanity check: reject if the band price is on the TRAILING team (stale book). - Improvement to add (supported by the research, absent from the old bot): only enter when price came INTO the band from below (leader extending, 94.6% win, +2.0c) and skip entries falling into the band from above (91.6%, −3.1c). Log both cases either way so the filter's value can be measured forward. - Exit: hold to settlement. Stop-loss: if the held side's mid falls to 0.72, IOC-sell into the bid (Kalshi has no native stops; the bot manages it, checking open positions every ~5s while entry scans run every ~20s). - Risk rails, all enforced in-process and hot-reloadable from a config file: contracts_per_game (start 100), max_daily_contracts, daily realized-loss halt ($50), enabled flag, and a HALT file that instantly blocks new entries while letting open positions settle/stop out. ARCHITECTURE (use the harness primitives correctly) - The trading loop is a single long-lived PROCESS: deterministic Python, no LLM calls, one instance only, crash-restart safe. On boot it must reconcile its local position state against the exchange (positions + fills ledger) so restarts never double-buy. State (positions, trades.jsonl decision log, HALT) lives in the Process's durable directory. - Kalshi credentials are injected to the Process (env/file); never place orders from the Controller and never put the key in LLM context. - The Process emits structured "EVENT {json}" stdout lines for entry, exit, settlement, halt, and anomaly. You (Controller) consume these to supervise. HARD-WON API LESSONS (these killed or hid failures in the previous bot — comply) 1. Order placement MUST use Kalshi's V2 endpoint POST /trade-api/v2/portfolio/ events/orders. The legacy /portfolio/orders returns HTTP 410 since mid-2026. V2 quotes everything on the YES book: side "bid"=buy YES, "ask"=sell YES; buying NO at p is an ask at 1−p. count and price are fixed-point strings; self_trade_prevention_type is required ("taker_at_cross"); use time_in_force "immediate_or_cancel"; order_id is top-level in the response. 2. Do not trust fill counts from the order-creation response; reconcile every order against GET /portfolio/fills by order_id. In fills, the "action" and "side" fields are deprecated — use outcome_side/book_side and the yes_price_dollars/no_price_dollars fields. 3. P&L accounting: a stop-loss exit gets booked by Kalshi as buying the opposite side, so the settlements ledger shows both legs' costs with no netting payout — a naive revenue−cost tally reports a ~$120 phantom loss on a real ~$20 stop-out. Compute realized P&L from your own entry/exit fills, and reconcile against the exchange monthly. SUPERVISION DUTIES (this is why the harness exists — the old bot failed silently for SEVEN WEEKS placing orders against a dead endpoint while its logs looked alive) - Treat any order_failed anomaly as an incident: after 3 consecutive failures, HALT new entries and message me with the raw API error. Never let order failures repeat silently across days. - Daily digest after the last game: entries, exits, realized P&L, win rate. - Weekly forward-test report: rolling win rate vs fee-adjusted breakeven per price bucket, from_below vs from_above performance, stop-loss saves/costs. If the rolling 100-trade edge goes negative, pause entries and tell me. - Watch for API drift: if any Kalshi response starts missing fields you rely on or returns deprecation errors, flag it before it becomes an outage. ROLLOUT Start live immediately at half size (50 contracts/game) for the first week, then move to full size if the week is clean. Budget context: the Kalshi account balance is ~$300; a full 100-contract entry at 0.90 risks ~$90 gross (~$20 net with the stop), so respect the daily loss halt.