Skin platforms

Skinified gambling infrastructure

CS2 and Rust economies move on Steam trades, third-party liquidity, and razor-thin trust windows. We build the full stack: bots, pricing, provably fair game logic, and the admin tools your team needs when a trade gets stuck at 2 a.m.

What we deliver

Steam API Integration

OpenID login with Steam Guard 2FA flows, encrypted refresh-token storage, trade offer create/accept/cancel with exponential backoff against HTTP 429, GetAssetClassInfo and inventory snapshots cached in Redis with ETag-style invalidation on trade completion. Session persistence across bot restarts via encrypted vault.

Trade Bot Systems

Fleet of isolated Steam identities with per-account rate-limit budgets, deposit bots that escrow incoming offers against expected float/pattern, and withdrawal bots that honor inventory reservations. Post–7-day-hold P2P routing: players trade directly when custody is legally or operationally undesirable, with signed handoff messages and dispute windows.

Multi-Marketplace Valuation

Composite mid-price from SteamAnalyst, BUFF163, CSFloat, and Skinport with staleness thresholds and outlier rejection (median absolute deviation). Doppler phase tables and sapphire/ruby premiums as first-class keys. Manipulation resistance: cap single-source influence, require minimum liquidity depth, and flag wash-traded patterns.

Game Modules

Coinflip (1v1 skin locks, deterministic outcome from committed seeds), jackpot (tickets proportional to contributed value, weighted draw), roulette (color buckets mapped from uniform roll), crash (multiplier curve from geometric parameter you publish). Each module exposes verify endpoints and archives seeds after reveal.

P2P Marketplace

Order book or RFQ-style listings with atomic swap via Steam trade offers, optional instant-cash rails backed by treasury float and clawback if chargebacks or reversals hit, and broker integrations (Waxpeer, SkinSwap, RapidSkins) behind a single internal listing schema.

Withdrawal & Liquidity

Multi-source fulfillment: internal bot inventory, partner APIs, and manual ops queue. Reservation tokens prevent double-spend of the same asset ID; aging reports surface stuck offers; hot/warm bot segmentation limits blast radius if an account is trade-banned.

How it works

01 — Deposit

Offer matching

Player selects skins; the system prices them against the composite index and opens a bot trade template. When the offer hits `ETradeOfferStateAccepted`, ingestion workers verify asset IDs and paint seeds, then credit internal balances only after hold rules pass.

02 — Wager

Escrow + fairness

Skin value is locked in the ledger for the match duration. Outcomes use the same HMAC stream as our casino stack, mapped to module rules. Public verify pages replay the bytes so power users can diff your implementation against the spec you publish.

03 — Cashout

Inventory routing

Withdrawals dequeue by priority and bot health. If internal float is thin, the router sources from partner APIs or falls back to ops with a clear SLA. Every outbound offer logs the `tradeofferid` for support tooling and chargeback analysis.

Technical depth

  • Steam Web API quotas modeled per key; global token bucket with per-bot shards and circuit breakers when Valve returns 503 series.
  • PostgreSQL row-level locks on `skin_asset_id` during offer acceptance to prevent cross-request double assignment.
  • Rust services for hot paths (offer parsing, float extraction) alongside Node.js orchestration and BullMQ job queues for retries.
  • WebSocket + polling hybrid: Socket.IO or native WS for lobby UX, background pollers for trade state until Steam callbacks land.
  • Price service warms caches from marketplace CSV/API feeds; optional ClickHouse for time-series arbitrage detection across venues.

Build your skin platform

From first Steam key to production bot fleet — we design for Valve rate limits, trade holds, and the edge cases that kill inexperienced teams.

Start a Project