Building a Zero-Cost Geopolitical Trading Bot with Satellite Data and Claude AI

Hook

What if you could detect geopolitical conflicts before the news cycle catches up, using only free satellite data and an AI that reads fire patterns like tea leaves?

Context

Prediction markets like Polymarket have created a new frontier for information arbitrage: if you can predict geopolitical events before the crowd, you can profit from the spread. The problem? Traditional news sources are slow, and premium intelligence feeds cost thousands per month. Meanwhile, NASA, USGS, and other government agencies broadcast real-time earth observation data for free—fire hotspots from conflict zones, earthquake tremors, aircraft movements over restricted airspace. This data arrives hours before Reuters picks up the story, but it's raw, noisy, and scattered across incompatible APIs.

The geo-satellite-trader repository tackles this signal processing problem with an elegant architecture: poll 10 free data sources every 15 minutes, detect anomalies against rolling baselines, feed the observations to Claude AI for synthesis, then execute trades on Polymarket using dynamic position sizing. The entire system runs on free API tiers, making it a masterclass in resourceful engineering. Created during the 2023-2024 conflicts in Gaza, Syria, and Ukraine, it reportedly generated 1,456% returns across 16 trades—though as we'll see, those numbers come with significant asterisks attached.

Technical Insight

The system architecture is a polling loop with three distinct phases: data ingestion, anomaly detection, and AI-powered decision making. Let's dissect each layer.

The data ingestion phase queries 10 APIs every 15 minutes: NASA FIRMS for satellite fire detection (the crown jewel), OpenSky Network for aircraft positions, USGS for earthquakes, plus market fear indicators (VIX, gold prices), weather conditions, ACLED conflict events, exchange rates, and oil prices. Each source returns JSON that gets normalized into a common schema. Here's the critical insight: the system doesn't just grab current readings—it maintains a 14-day rolling window to establish baseline activity. A fire in Syria is only interesting if it's anomalous compared to the past two weeks of burn patterns in that region.

The anomaly detection logic is where things get sophisticated. For FIRMS fire data specifically, the code calculates deviation scores by comparing current fire radiative power (FRP) against the historical mean and standard deviation. If FRP exceeds the baseline by more than 2 standard deviations, it flags a potential conflict event. But here's the clever part: it requires multi-source confirmation. A fire spike alone isn't enough—the system looks for correlated signals like unusual aircraft activity in the same region, elevated VIX (market fear), or ACLED conflict reports. This cross-validation dramatically reduces false positives from agricultural burns or wildfires.

Once anomalies are detected, the system constructs a prompt for Claude AI that includes the raw data points, baseline comparisons, and asks for a structured analysis. The prompt engineering here is crucial—it requests specific assessments of conflict probability, market impact likelihood, and recommended positions. Claude returns JSON with fields like trade_signal (boolean), market_id (which Polymarket question to trade), direction (yes/no), and confidence (0-100). The AI acts as a semantic layer that can synthesize disparate signals ("rising gold prices + fire spike in Damascus + aircraft diverging from commercial routes = probable military escalation") in ways that rigid rule-based systems cannot.

Position sizing uses a dynamic Kelly criterion implementation that's worth examining in detail:

def calculate_position_size(confidence, anomaly_score, frp_deviation):
    """
    Dynamic Kelly criterion with multi-factor adjustments
    """
    base_kelly = 0.25  # Conservative 25% Kelly fraction
    
    # Confidence adjustment (Claude AI signal strength)
    confidence_factor = confidence / 100
    
    # Anomaly severity (deviation from baseline)
    anomaly_factor = min(anomaly_score / 5.0, 1.0)
    
    # Fire intensity (radiative power for FIRMS data)
    frp_factor = min(frp_deviation / 3.0, 1.0)
    
    # Combined multiplier with confirmation bonus
    if all([confidence > 70, anomaly_score > 3, frp_deviation > 2]):
        confirmation_bonus = 1.2  # 20% boost for multi-signal alignment
    else:
        confirmation_bonus = 1.0
    
    position_pct = (base_kelly * confidence_factor * 
                    anomaly_factor * frp_factor * 
                    confirmation_bonus)
    
    # Bounds: 2% minimum (signal present), 40% maximum (risk control)
    return max(0.02, min(position_pct, 0.40))

This approach is notably more sophisticated than naive fixed-size betting. When all signals align—Claude expresses high confidence, fire activity is 3+ standard deviations above baseline, and FRP indicates military-grade explosions rather than campfires—the system sizes up to 40% of capital. Weak signals get minimal 2% allocations. The confirmation bonus rewards cross-source validation, which is the secret sauce for filtering satellite data noise.

The execution layer uses Polymarket's CLOB (central limit order book) API with limit orders placed at current market price minus 1% for buys, plus 1% for sells. Stop losses are hardcoded at -30% per position, and the system sends Telegram alerts for all trades, allowing manual override. The polling architecture means there's no complex event streaming infrastructure—just a simple cron job or infinite loop with time.sleep(900) between cycles. For a zero-cost constraint, this is the right tradeoff; real-time WebSocket feeds would require paid hosting to maintain persistent connections.

One architectural detail worth noting: the system stores all historical data in local JSON files rather than a database. For 15-minute polling intervals, this is perfectly adequate and keeps dependencies minimal. The rolling 14-day window is recalculated on each cycle by filtering the JSON array, which is O(n) but fast enough when n < 1,500 data points per source. If you wanted to scale this to minute-level granularity or years of history, you'd need PostgreSQL with time-series extensions, but that would break the zero-cost constraint.

Gotcha

The 4-6 hour delay in NASA FIRMS satellite data is the system's Achilles heel. FIRMS doesn't broadcast real-time—satellites have orbital passes, data gets downlinked, processed, and published on a schedule. By the time your bot sees a fire spike in Gaza, journalists on the ground may have already tweeted about it, and Polymarket odds may have moved. The backtest assumes you trade at satellite observation time, but in reality, you're trading 4-6 hours later at worse prices. This latency gap likely inflates the reported 1,456% returns significantly.

The backtest methodology raises red flags. Polymarket doesn't provide historical price APIs, so the author estimated entry/exit prices from anecdotal observation and chart screenshots. The 16 trades across 7 events (Gaza escalations, Syria regime fall, Kursk offensive) conveniently occurred during 2023-2024—a period of unusually clear-cut geopolitical moves where satellite fires strongly correlated with market-moving events. The strategy may be severely overfit to Middle Eastern conflicts where fire = conflict is a reliable heuristic. It might fail spectacularly in contexts like Chinese saber-rattling (no fires, just naval movements) or cyber warfare (zero satellite signature). The 7.3% max drawdown seems suspiciously low for a strategy with 40% max position sizes; real trading with slippage and adverse selection would likely see deeper pain.

The free API constraints create operational brittleness. FIRMS has rate limits (1000 requests/day), OpenSky throttles unregistered users, and Claude's free tier caps at 50 messages per day. If you're polling every 15 minutes (96 times daily), you'll blow through limits fast once you add proper logging and testing. The system has no retry logic or backoff strategies—if an API returns 429 or times out, that polling cycle just misses data. For production use, you'd need error handling, exponential backoff, and probably paid API tiers, which defeats the zero-cost premise.

Verdict

Use if: you're a developer fascinated by alternative data strategies and want a hands-on learning project that costs nothing but teaches you about geospatial APIs, prompt engineering for financial decisions, and the practical challenges of satellite data latency. This is an excellent portfolio piece that demonstrates creative problem-solving and systems thinking. Also consider it if you have domain expertise in specific geopolitical regions and can add proprietary signal layers (social media sentiment, supply chain data) to compensate for the satellite delay. Skip if: you're looking for a production trading system or plan to deploy serious capital. The unverifiable backtest, tiny sample size, and 4-6 hour data lag make this unsuitable for real money without extensive paper trading first. Also skip if you're not prepared to monitor Telegram alerts and manually intervene—the system will make boneheaded trades during false alarms (forest fires triggering Gaza conflict bets) without human oversight. If you need auditable performance or regulatory compliance, the lack of proper backtesting infrastructure is disqualifying. Treat this as an educational scaffold for building your own geopolitical intelligence platform, not as a turnkey money printer.