ADR 001: Connectivity Check Strategy

Status

Accepted

Context

The user requested a mechanism to verify connectivity to the exchanges (Polymarket and Kalshi) via a switch or command-line flag. This is crucial for pre-flight verification in CI/CD pipelines and manual troubleshooting without initiating a full trading loop.

Decision

We implemented a --check-connectivity CLI flag for the arbiter-engine binary.

Design

1. CLI Flag: Added a boolean flag --check-connectivity to main.rs using clap.
2. Client Modification: Extended the ExchangeClient trait to include async fn check_connectivity(&self) -> Result<(), ExecutionError>.
3. Polymarket Implementation:
   • Performs an HTTP GET request to https://clob.polymarket.com/time.
   • Validates network reachability and basic API responsiveness.
4. Kalshi Implementation:
   • Performs an HTTP GET request to https://trading-api.kalshi.com/v2/exchange/status.
   • Validates network reachability and exchange status.
5. Behavior:
   • If the flag is present, the application initializes the clients (loading keys from env), performs the checks, prints authenticated/connection status to stdout, and exits with code 0 (if successful) or error status.

Decision Drivers

• Council Recommendation: The LLM Council synthesized from multiple models (Gemini, Claude, Grok, GPT) that a connectivity switch is a sound pattern for "Healthbeat" diagnostics.
• Safety: Allows verifying credentials and network paths without risking unintended order execution.
• Observability: Provides clear, immediate feedback on system health.

Consequences

• Positive:
  • "Fail fast" mechanism for deployment pipelines.
  • Improved developer experience for troubleshooting.
• Negative:
  • Slight increase in binary size due to CLI parsing logic (negligible).
  • Requires maintenance of "probing" endpoints (e.g., if /time endpoint changes).

Verification

• Validated by running cargo run -- --check-connectivity locally.
• Reviewed and approved by LLM Council (Synthesis ID: 1173).