Notes From zz/arb-bot (Adopted Practices)

What Works Well

• FastAPI + simple JSON endpoint: /arbitrage returns a single payload with timestamps, raw data, and computed opportunities.
• Polymarket read path: uses gamma-api.polymarket.com/events to fetch metadata and clob.polymarket.com/book to get top-of-book prices.
• Kalshi read path: uses api.elections.kalshi.com/trade-api/v2/markets with event_ticker filtering for public market data.
• Top-of-book focus: uses best ask prices for buy-side comparison (fast, low overhead).
• Selective comparison: narrows Kalshi markets to a local window around the closest strike (faster and reduces noise).
• Clear response format: returns checks, opportunities, and errors which is useful for UI.

What We Should Improve

• Avoid eval for Polymarket clobTokenIds and outcomes; parse JSON safely.
• Async HTTP: switch to httpx or aiohttp for concurrency in a single process.
• Normalization first: separate raw fetch from normalized model construction.
• Persistence: store market metadata and mappings in Postgres; stream high-frequency updates via RabbitMQ.
• Scalable matching: use canonical global_markets + market_links instead of hardcoding a single event family.

How We Will Use It

• Keep the simple “single endpoint” idea for UI (/signals or /arbitrage).
• Mirror the public endpoints used for read-only fetches.
• Maintain the “closest strikes” filtering concept for specific event families, but apply it after normalization.