04PRISSET #25
Arbitration bot mrkt.land → buff163 (CS2)
A fully automatic system that catches undervalued skins on mrkt.land and compares them with buff163 prices in real time.
Architecture - 4 accounts, each with its own role
3 accounts on mrkt.land + 1 on buff163, working in parallel in one process:
• Account feed - reads the “New First” stream, catches newly exhibited lots
• Account catalog - goes through the entire catalog by price, catches overpriced lots (they are not in the “new” ones, but they often hide benefits)
• Buyer account – holds the balance and makes a purchase
• buff163 — background price sync: ask (showcase) and bid (buy-order)
Separation by accounts gives each one its own IP and its own session - the feed and directory are polled simultaneously, without being limited by the general rate-limit.
Dolphin Anty (anti-detect)
Each account lives in a separate Dolphin profile with its own resident proxy. The key point is IP consistency: from which address the account logged in, all requests come from the same. For the site, it looks like a regular live browser, and not like a bot from one server. Proxies are protected by profiles, so nothing breaks when transferred to hosting - traffic still goes through the “native” IP accounts.
How to parse (not DOM, but API)
mrkt.land is Next.js on top of a private JSON-API. We work directly with the API (endpoints are pulled from the JS bundle), rather than parsing HTML. This is an order of magnitude faster - profitable lots are sorted out in a fraction of a second.
An important nuance: the feed is a stream of events, not a list of products. There are 4 types: listing (exposed), change_price (overpriced - still on sale), unlisting (removed), sale (already sold). We buy only the first two + Validated status. We cut off the rest so as not to chase after lots that no longer exist.
Logic of price and benefit
For each skin, we count two landmarks at once from buff163:
• ask (showcase price) - the main threshold: we take it if mrkt is at least 15–25% cheaper
• bid (buy-order, instant sale) - control: usually +3–8%, shows the real output “here and now”
• bid (buy-order, instant sale) - control: usually +3–8%, shows the real output “here and now”
Both numbers are written for each skin found, so you can see both the “paper” benefit and the real one.
Filters and fuses
• We exclude StatTrak, Souvenir, Well-Worn; skins from $20
• Exact name matching (no fuzzy - mistakes cost money)
• Stop at rotten buff prices, outdated rate, thin market (<3 lots), absurd profit (matching error), exceeding limits per trade/day
• Protection against double purchases and “slippage” (purchase at exactly the price at which profit was calculated)
Management
• Web panel: live log, counters, start/stop cycles on the fly, switching DRY_RUN live buyback, setting profit thresholds and limits directly from the browser
• Notifications in Telegram for each purchase - with a picture, float, price, profit and link to the item
• Hosting under systemd, access via IP
About speed
Everything is tied to being the first to receive and evaluate data. Warm keep-alive connections, polling the tape once a second, instant reading of prices from the local cache. The real ceiling is physics: some of the truly profitable lots are taken by co-locking bots in ~100 ms, but the system honestly takes everything it manages to reach.