Counter-Strike 2 is the most inefficient sports market on Polymarket. Professional matches run 24/7 across dozens of tournaments, but the number of sophisticated market makers pricing them is tiny compared to NBA or NFL. We've seen 40-cent edges sit there for 10 minutes.
The catch: CS2 also has the worst data infrastructure of any sport we trade. There's no equivalent of ESPN's scoreboard API. The two best data sources are HLTV (aggressively Cloudflare-protected) and bo3.gg (better APIs but slightly less coverage).
This is how we built a CS2 bot that handles both the opportunity and the data problem.
Why CS2 Matters Strategically
The mispricings exist because CS2 markets are dominated by retail bettors who follow specific teams emotionally. Polymarket prices reflect their beliefs. If a popular team is playing a tier-2 squad, the popular team gets overpriced. If a tier-2 team has been quietly rising in form, it gets underpriced.
A model with current Elo ratings can systematically detect these mispricings. Our backtest on bo3.gg historical data found 121 trades with +8.4 cents per trade net of fees and slippage.
The challenge is building a model that works across all the data availability scenarios. Sometimes you have full round-by-round economy data. Sometimes you only have the map score. Sometimes you have nothing but team names and the series format. A single-architecture model can't handle all three.
The 4-Tier Architecture
We use four model tiers, ranked by data quality:
Tier 1: Combined Model (bo3.gg with economy) When we have live round data plus economy snapshots (equipment values, buy phases), we use the combined model. This is XGBoost trained on 4,372 matches with 15 features including current round score, half progression, side (CT or T), economy gap, map identifier, and Elo difference.
The economy data matters more than people realize. CS2 has a 4-tier economy: full buy (both teams have full equipment), eco (one team is saving), force buy (suboptimal money), and pistol (first round of each half). When the economy gap exceeds $15,000, the richer team wins the round about 75% of the time. This is a much stronger signal than the round score alone.
Tier 2: Map ML Model (HLTV without economy) When we have round data from HLTV but no economy snapshots, we fall back to the map-level ML model. Same XGBoost architecture, but without the economy features. Less precise than the combined model but still significantly better than Elo alone.
Tier 3: Series ML Model (PandaScore fallback) When we don't have any round data — just the map score in a best-of-3 or best-of-5 — we use the series-level model. Trained on 4,372 matches with 11 features, achieves 84.4% accuracy. We require a 15-cent minimum edge for series-level predictions because they're inherently less precise.
Tier 4: Elo-Only Binomial (no live data) When we have nothing but team names and series format, we fall back to pure Elo. We convert Elo difference to per-map win probability, then use the binomial distribution to compute series probability. This is the least accurate tier, so we apply the heaviest dampening (shrinking predictions toward 50% to avoid overconfidence).
Each tier has its own minimum edge threshold. Tier 1 trades on 8c+ edges. Tier 4 needs 15c+ to compensate for the wider error bars.
Map-Specific CT Win Rates
CS2 maps aren't symmetric. The CT side has structural advantages on some maps and disadvantages on others. From our historical data:
| Map | CT Win Rate |
|---|---|
| Nuke | 57% |
| Vertigo | 54% |
| Ancient | 53% |
| Train | 53% |
| Inferno | 52% |
| Overpass | 52% |
| Mirage | 51% |
| Dust2 | 50% |
| Anubis | 47% |
Most models treat all maps as symmetric (50/50 starting point for each team). That's wrong. A team starting on T-side Nuke is at a structural disadvantage that needs to be priced in. A team starting on CT-side Anubis is actually slightly disadvantaged.
Our combined model takes the current map identifier as a feature. This shifts predictions by 5-10 cents in many situations.
The HLTV Problem
HLTV is the canonical CS2 statistics site. Every team has a profile, every match has detailed round-by-round stats, every player has performance metrics. It's the obvious data source.
The problem: HLTV uses aggressive Cloudflare bot protection. Standard Python requests get blocked instantly. We had to use curl_cffi (a library that impersonates Chrome's TLS fingerprint) just to get past the initial detection. Even with TLS impersonation, HLTV would block us periodically during peak hours.
This was unsustainable. A trading bot that loses its data feed mid-match is worse than a bot that doesn't trade at all.
Switching to bo3.gg
In April 2026, we replaced HLTV with bo3.gg as our primary data source. The trade-offs:
bo3.gg advantages: - Proper REST API, no TLS impersonation needed - Live economy snapshots (equipment values per round) - Better coverage of major tournaments - More reliable uptime
bo3.gg disadvantages: - Slightly less coverage of minor tournaments - Different team naming conventions (required a mapper) - Newer API, less documentation
We kept HLTV as a Tier 2 fallback for matches where bo3.gg doesn't have coverage. PandaScore is the Tier 3 fallback. This three-source pipeline gives us continuous data even when individual sources fail.
The Live Trading Audit
We launched the CS2 bot on March 9, 2026 and ran it for a month. The results were terrible.
33 resolved trades. 15 wins, 18 losses. 45.5% win rate. Net loss of 67 cents.
The backtest had said 78% win rate. A 32-point gap.
We dissected every trade and found five problems: slippage wasn't modeled (avg 4.9c live), the underdog trap (0-40c entries had 17% WR), low-edge noise (0-10c bucket had 38% WR), high-entry asymmetric risk (70-85c bucket lost 81c), and stale Elo ratings (the +100-200 Elo diff bucket had 0% WR on 5 trades).
After tightening the filters (min_edge 4→10c, min_fair 50→55c, max_entry 80→70c, added 8c max_slippage gate) and rebuilding Elo from 4,350 matches, the retroactive filter test showed: 11 of 33 trades would have passed, 6 wins, 5 losses, +40 cents.
The lesson: even with the right data sources and the right model architecture, you need to actively audit your live performance. Backtest assumptions break in ways you can't predict.
What We'd Do Differently
Start with bo3.gg, not HLTV. Cloudflare-protected data sources are landmines for production trading. Choose data sources by reliability, not by which one is most popular among manual bettors.
Build the slippage gate first. Our biggest live performance leak was unmodeled slippage. The 8-cent slippage gate should have been in the bot from day one, not added after losses.
Tighter initial filters. We launched with min_edge=4c because the backtest looked great at that level. The backtest was wrong because it didn't model slippage. A more conservative 8-10c starting threshold would have caught the problem with less damage.
Retrain Elo more often. CS2 teams reshuffle constantly. Monthly Elo rebuilds are too slow. We now rebuild weekly, ideally daily during major tournaments.
The Takeaway
CS2 markets are the most profitable per-trade of any sport we trade. They're also the hardest to build infrastructure for. The combination — high alpha, high friction — is exactly where systematic bots have an advantage over manual bettors.
If you can solve the data problem (bo3.gg + reliable Elo) and the execution problem (slippage gates + smart filters), CS2 has the cleanest edge of any sport on Polymarket.
The CS2 bot is part of our unified trading system. Module 5 of the course covers building Polymarket bots from scratch — including handling unreliable data sources and execution gates.