API Reference

The Dynamic Skellam Engine models NBA games as two competing Poisson processes (one per team's scoring rate). Instead of additive heuristics, it calculates P(Home Wins) from the physics of the game:

1. Layer 1 — Dynamic Intensities: Per-team scoring rates (λ) derived from Vegas O/U totals, adjusted for pace, lineup, and fatigue
2. Layer 2 — Hawkes Volatility: Self-exciting point process inflates/dampens λ based on unanswered scoring runs (momentum)
3. Layer 3 — Skellam CDF: Given remaining time and adjusted λs, computes the exact probability of home team winning
4. Layer 4 — Swarm Blending: Behavioral edge from LLM agent reaction surfaces (panic pricing during Flash Crashes)

The result is a first-principles probability recalculated on every play-by-play event, typically within 100ms.

edge_score tells you the size of your alpha. hawkes_flag tells you whether that alpha is expanding or contracting.

A +4.2% edge with SURGE_HOME means the home team is on an unanswered run AND the edge is still growing. The market hasn't caught up yet. This is the optimal entry window.

The same +4.2% edge with FADING means the run just ended and the market is about to correct. If you buy now, the line moves against you before your order fills.

Advanced bot logic: if hawkes_flag == "SURGE_HOME" and edge_velocity > 0: execute()

kalshi_implied is the mid-price: (bid + ask) / 2. It represents the market's consensus probability. But you can't trade at the mid.

To buy, you cross the spread and pay the ask. To sell, you hit the bid. The difference is your spread cost.

Example: Bid 0.63, Ask 0.67, Mid 0.65. Your our_prob is 0.72.

• Calculated on mid: edge = 0.72 - 0.65 = +7%
• Realized on ask: edge = 0.72 - 0.67 = +5%

Bots that size positions on mid-price edges will over-leverage by 40% in this example. Use kalshi_best_ask for buy-side sizing and kalshi_best_bid for sell-side sizing.

In sub-200ms sports trading, data rots instantly. computed_at_ms tells you exactly when the engine finalized the Skellam math.

age_ms = int(time.time() * 1000) - edge["computed_at_ms"]
if age_ms > 300:
    # Signal is 300ms+ old. Market makers have already moved.
    # ABORT the trade.
    return

if age_ms > 500:
    # Signal is half a second old. Definitely stale.
    # If you execute here, you are the liquidity, not the alpha.
    return

If your bot is consistently seeing age_ms > 500, your network path to our API is too slow. Consider colocating closer to our server (IONOS, US-East).

Recon Node ($49/mo) is for manual traders who want to watch our data:

• 100 API calls/day (check /v1/edges/live a few times per game)
• Edge signals + trade signals + Kelly sizing
• Live screener terminal access
• No WebSocket, no execution routing keys, no top-of-book

Alpha ($99/mo) gives you everything you need for profitable automated trading:

• 2,000 API calls/day (poll /v1/edges/live every 2 seconds for 8 hours of games)
• Full God Tier payload with execution routing, top-of-book, momentum physics
• WebSocket real-time stream (uncounted — no rate limit)
• Latency guard (computed_at_ms) for staleness detection

Terminal ($199/mo) adds institutional-grade data feeds:

• 10,000 API calls/day (multi-game parallel polling)
• L2 order book depth (Almgren-Chriss market impact data)
• Historical signal archive for backtesting
• Higher burst rate (50 req/sec vs 10 req/sec)

Manual trader? Recon. Single-game bot? Alpha. Multi-game portfolio with impact sizing? Terminal.

Our nightly accuracy report runs automatically after each game night. Season-to-date metrics as of the latest report:

• Directional hit rate: ~94.5% (when we say BUY, the home team wins)
• Brier score: Tracked per game-progress bucket (Pregame, Early, Mid, Late, Clutch) — our model is best-calibrated in Late/Clutch game states where momentum data is richest
• Edge capture: Varies by market liquidity. Higher on Polymarket (thinner books = more mispricing) than Kalshi

Full accuracy reports are available on the terminal dashboard under Analytics.

Yes — that's the primary use case. The target_kalshi_ticker field is the exact string Kalshi's order API requires. A minimal OpenClaw integration:

edge = get_latest_edge(game_id)
if edge["trade_signal"] == "BUY" and edge["hawkes_flag"] == "SURGE_HOME":
    kalshi_client.create_order(
        ticker=edge["target_kalshi_ticker"],
        side="yes",
        type="limit",
        yes_price=int(edge["kalshi_best_ask"] * 100),  # Kalshi wants cents
        count=calculate_position_size(edge["kelly"], bankroll)
    )

No ticker mapping. No team-to-contract lookup tables. One variable assignment from signal to order.

The system operates on multiple timing loops:

• Play-by-play events: ESPN polls every 60 seconds. Each new event triggers the Skellam engine within ~100ms
• Kalshi prices: WebSocket real-time + REST API polls every 60s (authoritative). Written to Redis with 120s TTL
• WebSocket delivery: Edge updates broadcast to connected clients within 2 seconds of computation
• REST API: Always returns the latest computed edge. Use computed_at_ms to verify freshness

End-to-end latency from a scoring play to your bot receiving the updated edge: ~60-120 seconds (dominated by ESPN's poll interval, not our compute).