I Built a Polymarket Weather Bot and Lost $80 — Here's Everything I Learned

Building a trading bot that bets on weather outcomes sounds like a cheat code. Polymarket runs daily temperature markets for cities worldwide — "Will NYC hit 36°F or higher tomorrow?" — and weather forecasts are pretty accurate. So what could go wrong?

Everything. I spent a week building an AI-powered weather trading bot, lost about $72, and learned more about prediction markets, crypto wallet hell, and market efficiency than any course could teach.

This is the full story — the tech stack, the wallet nightmare, the trades, and why the strategy was doomed from the start.

What Are Polymarket Temperature Markets?

Polymarket is a prediction market platform running on Polygon. Among its many markets, it offers daily temperature bets for 30+ cities worldwide. Each market is a simple binary question: "Will the high temperature in [City] be [X]°F or higher on [Date]?"

You buy shares between $0.01 and $0.99. If you're right, each share pays out $1. If you're wrong, you lose your stake. Prices reflect what the crowd thinks the probability is.

My thesis: Weather forecasts from NOAA and Open-Meteo are accurate enough to find mispricings. If the forecast says 38°F and the market only prices the "36°F+" outcome at $0.58, that gap is profit waiting to happen.

Spoiler: it wasn't.

The Tech Stack

I built the entire bot with OpenClaw (running Claude as my AI coding assistant) in about a week. Here's what it did:

• Market Discovery: Scanned Polymarket's Gamma API every 2 minutes for active temperature markets across 30+ cities
• Dual Forecast Engine: Pulled forecasts from both NOAA (US cities) and Open-Meteo (global), used consensus when both agreed
• Edge Detection: Compared forecast-derived probabilities against market prices, flagged opportunities with 10%+ theoretical edge
• Automated Trading: Placed limit orders through Polymarket's CLOB (Central Limit Order Book) API
• Dynamic Exit: Automatically sold positions early when the forecast shifted against us
• Position Management: Per-city budgets, maximum position limits, duplicate trade prevention

The code is open-source on GitHub if you want to see (or learn from) the wreckage.

The Wallet Setup Nightmare (2 Full Days)

Before losing money on trades, I spent two days just figuring out how to fund the bot. If you're building any Polymarket bot, this section will save you a weekend.

USDC vs USDC.e — They Look the Same, They're Not

Polymarket runs on Polygon, so you'd think regular USDC works. It doesn't. Polymarket's Conditional Token Framework uses USDC.e — the bridged version of USDC on Polygon. They look identical in your wallet. They have completely different contract addresses.

My first trade attempt silently failed. No error. Nothing happened. Two hours of debugging later: wrong USDC variant.

Fix: You need to swap native USDC to USDC.e on a Polygon DEX (I used QuickSwap V3).

You Need POL for Gas

On Polygon, gas is paid in POL (formerly MATIC — they rebranded in late 2024, so half the docs online are outdated). Your fresh wallet has zero POL.

The bootstrap sequence:

1. Send USDC to your Polygon wallet
2. Swap a small amount of USDC → POL on a DEX (to pay for future transactions)
3. Swap remaining native USDC → USDC.e

QuickSwap V3 Is Not Uniswap V3

QuickSwap V3 is an Algebra fork, not a standard Uniswap V3 fork. The swap function uses limitSqrtPrice instead of sqrtPriceLimitX96. Same math, different parameter name. Pass the wrong one and the transaction reverts with an unhelpful error.

Six Contract Approvals Required

To trade on Polymarket, your wallet needs to approve six separate contract interactions:

1. USDC.e allowance → Exchange contract
2. USDC.e allowance → NegRiskExchange contract
3. USDC.e allowance → NegRiskAdapter contract
4. CTF (ERC-1155) setApprovalForAll → Exchange
5. CTF setApprovalForAll → NegRiskExchange
6. CTF setApprovalForAll → NegRiskAdapter

Each one is a separate on-chain transaction requiring gas. Miss one and your trades fail silently. No error message. Just nothing.

API Keys Are Wallet-Derived

Polymarket's CLOB API doesn't use normal API keys. They're derived cryptographically from your wallet's private key using their SDK's deriveOrCreateApiKey() function. No dashboard, no copy-paste. You initialize the client and it figures it out.

Total setup time before placing a single trade: ~2 days.

The Cloudflare Block

With everything ready, I ran the bot from my home machine in Germany. First API call to clob.polymarket.com: 403 Forbidden.

My German residential IPv6 address was blocked by Cloudflare. The Gamma API (read-only market data) worked fine. The actual trading API? Blocked.

Solution: Spin up a $6/month DigitalOcean VPS in Amsterdam. Deploy the bot there. Another half day gone.

Version 1: The Crypto Arbitrage That Wasn't

Before the weather bot, I actually built a different Polymarket bot targeting 15-minute crypto markets ("Will BTC go up in the next 15 minutes?").

The theory: since one side always wins, UP + DOWN shares = $1 guaranteed. If you can buy both for less than $1, that's risk-free profit.

Results after 10 hours (39 rounds):

• 816 dip signals detected
• Dips up to -52% observed
• Zero trades executed

Why? Market makers maintain the spread at exactly $1.01 — always. When one side crashes, the other adjusts within the same 2-second window. Sub-second bots defending the price invariant. Riskless arbitrage on liquid Polymarket markets is impossible for retail traders.

$0 lost, but one important lesson: you need an informational edge, not a mechanical one. So I pivoted to weather.

The Weather Bot Goes Live

February 10, 2026. The bot launched and immediately found what looked like massive edges — Seoul at 789%, Miami at 627%, Ankara at 515%. The numbers looked incredible.

First five positions placed across NYC, London, and Seoul. $11.90 deployed.

Then NYC resolved.

Trade: NYC 36°F or higher, bought at $0.58. Forecast said 38°F. Actual high: 35°F. Result: Lost $2.96.

The forecast was off by 3°F. That's normal for weather forecasts. It's also enough to completely blow up a narrow temperature bucket bet.

Full Trading Results

8 trades. 50% win rate. Wins averaged +$3.84, losses averaged -$2.35. The edge was razor thin.

The Pivot to Warm Climates

Cold-climate cities in winter were unpredictable — temperature swings of 3-5°F are common. So we pivoted to warm, stable climates only: Miami, Atlanta, Dallas, Wellington.

We also added:

• Dynamic position sizing per city tier
• Consensus forecasting (NOAA + Open-Meteo must agree)
• Dynamic exit — sell early when the forecast shifts instead of riding to zero

Backtesting looked great. 58.7% win rate historically, +15.2% projected ROI.

Reality? Same story. The bot deployed almost the entire $50 budget across 26 trades in two days.

The Final Numbers

Why It Failed: 5 Hard Lessons

1. Weather Forecasts Aren't Precise Enough for Exact Buckets

Forecasts are great for "warm or cold?" They're terrible for "will the high be exactly 76-77°F?" A 2°F error — well within normal accuracy — completely blows your position. Polymarket's temperature markets use 1-2 degree buckets. That's tighter than forecast uncertainty.

2. The Market Already Prices in the Same Forecasts

This should have been obvious. Polymarket prices already reflect weather forecast data. My "edges" were illusory — I was comparing my forecast against prices set by people looking at the same data.

A real edge would require a forecast model better than what market participants use. Calling the free Open-Meteo API isn't that.

3. Aggressive Sizing Burns Capital Fast

The bot saw "massive edges" everywhere and deployed aggressively. Those edges were noise. The $50 budget was gone in days instead of weeks.

4. International Cities Are Flying Blind

NOAA only covers US weather stations. For international cities (Wellington, Seoul, London), we had single-source data from Open-Meteo — no consensus possible. These were coin flips with extra steps.

5. Operational Overhead Was Absurd

For a bot managing $50:

• 6 duplicate instances ran simultaneously at one point (bad restart procedure)
• NOAA returned 404s for non-US cities
• RPC provider rate limits required cycling through multiple endpoints
• ethers.js cached balanceOf results, requiring raw provider.call() for accurate balances
• Cloudflare blocks necessitated a VPS

What I'd Do Differently

Honestly? I wouldn't do it again. But if you're determined:

1. Paper trade first. Run the bot for 2+ weeks without real money. Track what it would have done.
2. Use ensemble forecasts — GFS, ECMWF, NAM, HRRR. If all four models agree, you might have a real edge.
3. Only trade when the entire forecast confidence interval falls within the winning bucket. Not just the point estimate.
4. $1 per trade, not $3-4. See if the strategy works over 100+ trades before scaling.
5. US cities only where NOAA provides hourly station data.

The Bottom Line

Building the bot was genuinely fun. My AI assistant (OpenClaw) helped me write, debug, and iterate the entire codebase in a week — from wallet setup scripts to the trading engine to position management. That part was impressive.

The strategy was the problem. Publicly available weather data can't give you an edge on a prediction market that's pricing in the same data. This is the efficient market hypothesis, and it applies to Polymarket temperature markets just as much as it applies to the stock market.

Total cost of the experiment:

• ~$72 in lost trades
• $6 for the VPS
• ~15 hours of development
• One expensive lesson about market efficiency

The code is open-source on GitHub as a cautionary tale. Learn from my $80 so you don't have to spend your own.

This bot was built entirely with an AI coding assistant running on OpenClaw. If you want your own AI agent that can build things like this (and hopefully talk you out of the bad ideas), check out Lobsterlair — managed OpenClaw hosting so you can skip the server setup and get straight to the tinkering.