CS2 Trade-Up Bot

Real-time CS2 trade-up contract analyzer. Continuously discovers profitable trade-ups across all 6 rarity tiers by combining live market data from CSFloat, DMarket, and Skinport with a time-bounded discovery engine that evaluates thousands of listing combinations per cycle.

Live at tradeupbot.app

How Trade-Up Contracts Work

CS2 trade-up contracts let you trade 10 skins of one rarity for 1 skin of the next rarity tier. The output float (condition value) is deterministic:

outputFloat = outputMin + avg(normalizedInputFloats) * (outputMax - outputMin)

The only randomness is which output skin you get, weighted by how many collections are represented in the inputs. This means profitability is calculable — if you know the input prices, output prices at the resulting float, and the probability distribution across possible outputs, you can compute exact expected value.

The bot automates this: it fetches real market listings, tests input combinations at specific float targets near condition boundaries (where price jumps are largest), and identifies trade-ups where EV exceeds cost.

Features

Discovery Engine — Evaluates thousands of listing combinations every 20-minute cycle across all rarity tiers (Consumer through Knife/Glove). Float-targeted selection at 45+ condition-boundary transition points per collection. Workers run in parallel child processes with time-bounded budgets.

Outcome Probability Charts — Each trade-up expands to show every possible output skin with its probability, market price at the predicted float, and profit/loss. Visual breakdown of exactly where your money goes.

Price Intelligence — Float vs. price scatter charts with data from CSFloat sales, DMarket listings, and Skinport. Per-condition pricing across every source. Custom canvas-based scatter chart implementation for rendering 10K+ data points.

Collection Browser — All 89 collections with knife/glove pool info, listing counts, and profitable trade-up counts.

Claim & Verify System — Pro users can claim trade-ups (locks the underlying listings for 30 minutes) and verify that input listings are still available on-market before purchasing. Verification propagates status changes across all trade-ups sharing those listings.

Tiered Access — Free/Basic/Pro tiers with Stripe billing. Free tier shows top 10 per type with a 30-minute delay. Pro gets real-time data, claims, and higher verify limits.

Architecture

~20K lines of TypeScript across 56 server files and 38 frontend files.

┌─────────────────────────────────────────────────────────────┐
│  React Frontend (Vite, port 5173)                           │
│  Trade-up table, data viewer, collection browser            │
├─────────────────────────────────────────────────────────────┤
│  Express API (port 3001, proxied by Vite)                   │
│  Trade-up list, verify, claims, Stripe webhooks, Steam auth │
├──────────┬──────────────────────────┬───────────────────────┤
│  Daemon  │  DMarket Fetcher (2 RPS) │  Skinport WebSocket   │
│  20-min  │  Continuous separate     │  Passive, no auth     │
│  cycles  │  process                 │                       │
├──────────┴──────────────────────────┴───────────────────────┤
│  PostgreSQL 16          │  Redis (cache, claims, rate limits)│
│  Listings, trade-ups,   │  30-min trade-up cache, 5-min     │
│  price observations     │  claims, per-user rate limits      │
└─────────────────────────┴───────────────────────────────────┘

Tech Stack

Layer	Technology
Frontend	React 19, Vite, Tailwind CSS 4, shadcn/ui, custom canvas charts
Backend	Express, TypeScript (ESM), tsx (no build step for server)
Database	PostgreSQL 16 (async pg driver), Redis (ioredis)
Auth	Steam OpenID via passport-steam, express-session (SQLite store)
Payments	Stripe (Checkout, Customer Portal, Webhooks)
Infrastructure	Hetzner VPS (3 vCPU), nginx, PM2, Let's Encrypt
Data Sources	CSFloat API, DMarket API (HMAC-signed), Skinport WebSocket

Daemon: Time-Bounded Discovery Engine

The daemon is the core of the system — a continuous loop that fetches market data and discovers profitable trade-ups within strict time and API budgets.

Each 20-minute cycle runs through these phases:

Phase 1: Housekeeping — purge stale trade-ups, refresh listing statuses
Phase 3: API Probe — detect remaining rate limits across 3 CSFloat pools
Phase 4: Data Fetch — sale history, new listings, DMarket coverage gaps
Phase 4.5: Verify profitable inputs — individual listing lookups
Phase 4.6: Staleness checks — verify oldest listings still exist on-market
Phase 4b: Recalculate trade-up costs from price updates
Phase 5: Discovery — all remaining time (~17 min)
  └─ Repeating super-batches until cycle budget exhausted:
     ├─ Round 1: Knife + Classified workers (dynamic time limit)
     ├─ Round 2: Restricted + Mil-Spec workers
     ├─ Round 3: Industrial + Consumer workers
     ├─ Merge results into DB (deduplication by signature)
     ├─ Revival (re-evaluate previously-stale trade-ups)
     └─ Staleness spot-checks

Workers are forked child processes with read-only DB access. Each worker:

1. Loads existing trade-up signatures from DB to skip known combinations
2. Runs structured discovery with a deadline (60% of time budget) — float-targeted selection at condition boundaries
3. Runs deep exploration with remaining time — 7 strategies including random pairs, condition-pure, cross-condition, and float-targeted
4. Returns results via NDJSON streaming

Dynamic time allocation: first super-batch gets remaining/3 (up to 5 min), subsequent batches get 2-min minimum. Workers are killed at timeLimit + 30s.

Pricing System

Output pricing is layered by confidence:

This is the beginning of the README. Read the rest at the original. Read the full README ↗