Arb Bot Feature Requirements

Overview

This lists features we need to build.

1. Market Identification (Phase 1 Priority: High)

a. Bot must identify and store all equivalent or identical market pairs across Polymarket and Kalshi (e.g., same event, similar strikes, same resolution time/oracle).
b. Bot must track active pairs (open for trading) and upcoming pairs (scheduled but not yet live).
c. Recommendation: Start with semi-automated matching (fuzzy string similarity + date parsing for BTC hourly/politics/sports). Manual validation/review for new categories to avoid false positives. Full automation possible but requires ongoing tuning.

2. Price Retrieval (Phase 1 Priority: High)

a. Bot must retrieve target/strike prices for all active pairs from both platforms.
b. Bot must retrieve current Yes/No (Up/Down) best ask prices and liquidity depth for active pairs.
c. Recommendation: Poll APIs every 10–30 seconds (configurable). Cache results to respect rate limits.

3. Arbitrage Checking (Phase 1 Priority: High)

a. Bot must check all permutations of an active pair for combinations where total cost < $1.00 (after estimated fees/gas).
b. Bot must enumerate all required trade data when an opportunity is found (platform, side, price, size, strike, estimated profit).
c. Bot must notify instantly when an arbitrage opportunity is found (Telegram preferred; configurable threshold, e.g., gross profit ≥ 3%).
d. Recommendation: Include liquidity filter (min depth $50–100 per leg) and deduplication (one alert per unique pair per hour).

4. Trade Placement (Phase 1 Priority: Medium — Start Manual)

a. Bot must be able to autonomously place trades when an opportunity meets criteria (initially optional/dry-run mode).
b. Bot must allow easy configuration of bet size per side (e.g., fixed $ amount, % of available cash, or per-opportunity cap) without code changes.
c. Bot must handle cases where opportunity changes/disappears before full execution (e.g., partial fill, cancel remaining).
d. Recommendation: Start with manual confirmation mode (alert + dashboard link). Add auto-execution later with strict limits (max $ per trade, daily cap). Human-in-the-loop for first 20–50 trades.

5. Prediction Account Management (Phase 2 Priority: Medium)

a. Bot must monitor cash balance on both platforms (USDC on Polymarket/Polygon, USD on Kalshi).
b. Bot must track money allocated to active/open trades on both platforms.
c. Bot must take configurable action if cash dips below preset threshold (e.g., pause trading, alert).
d. Recommendation: Integrate wallet/API balance checks. Add auto-top-up alerts if possible.

6. Overall Logging & Reporting (Phase 1 Priority: High)

a. Bot must log all arbitrage opportunities found (with full details: strikes, prices, total cost, profit, timestamp).
b. Bot must log all trades placed (manual or auto: amount, outcome, P&L at resolution).
c. Bot must track net money won/lost from all trades (daily/weekly summaries).
d. Recommendation: Add performance metrics (opportunities/day, execution rate, avg profit, win rate). Export to CSV or simple dashboard.

7. System Reliability & Safety (Phase 1 Priority: High)

a. Bot must handle API errors, rate limits, and network issues gracefully (retries, backoff).
b. Bot must have configurable dry-run mode (default on) for testing.
c. Bot must include kill switches (max daily loss, pause on errors).
d. Recommendation: Run on VPS for 24/7 uptime. Add health checks/monitoring.

Additional Recommendations

• Phase 1 MVP: Focus on BTC hourly markets (high overlap, frequent opportunities). Prove the loop (detect → alert → manual trade) before auto-execution or expansion.
• Thresholds: Configurable min gross profit (e.g., 3–5%) to filter noise after fees.
• Expansion: After MVP, add politics (elections) and sports (high volume on Kalshi).
• Risk Note: Even "risk-free" arb has execution/slippage risk — emphasize small sizes early.