Разработчик, представившийся как ialakey, опубликовал репозиторий caseforge — учебный проект сайта с кейсами CS2, включающий полный цикл: авторизацию через Steam, открытие кейса с проверяемым результатом, продажу и апгрейд предметов, а также вывод средств через торгового бота. Работа выложена под лицензией MIT и позиционируется как исследовательская база для изучения архитектуры таких сервисов, а не готовый бизнес. Поводом послужил вопрос, который автор задал сам себе: обманывают ли подобные сайты на этапе ролла или механизм нечестности устроен иначе. Ответ оказался неочевидным: подкручивать сам розыгрыш оператору не требуется, поскольку нужный экономический эффект достигается через настройку таблицы выигрышей. Сайтов с кейсами CS2 десятки, деньги там крутятся серьёзные, и при этом ни один не публикует исходники — снаружи видна только крутящаяся лента и кнопка «открыть», тогда как внутри работают Steam-боты, эмуляция клиента, HMAC и целочисленная бухгалтерия.

В проекте реализована схема provably fair, знакомая по многим азартным сервисам. Сервер генерирует serverSeed из 32 случайных байт и публикует только его хеш sha256, клиент задаёт собственный clientSeed, а счётчик nonce увеличивается при каждом открытии. Итоговый ролл вычисляется как HMAC-SHA256 от пары сидов и номера попытки, после чего берётся остаток от деления на фиксированный тикет-спейс в 1 000 000. Выпадает предмет, чей диапазон тикетов накрыл полученное число. При ротации серверного сида старый раскрывается, и любой прошлый ролл можно пересчитать и сверить с опубликованным хешем. Автор отдельно отмечает, что использует диапазоны, а не веса, чтобы проверка была доступна в уме и не зависела от порядка обхода массива: диапазон [0, 749999] читается как 75% без всякой нормализации, а размер тикет-спейса зафиксирован навсегда — его изменение сделало бы непроверяемыми все прошлые открытия. Верификация в браузере реализована независимо на Web Crypto, а не вызовом того же серверного кода, иначе страница проверяла бы согласованность сервера с самим собой, а не честность конкретного открытия.

Техническая часть проекта построена целиком на TypeScript, и это решение продиктовано не вкусовыми предпочтениями, а ограничениями платформы. Обмен предметами в Steam не проходит через официальный Web API: он умеет только читать инвентарь, историю и профиль, тогда как создать трейд-оффер, подтвердить его мобильным аутентификатором и отследить статус можно только через внутренние эндпоинты steamcommunity.com, что требует эмуляции клиента. Единственная живая и поддерживаемая экосистема для этого — набор библиотек DoctorMcKay на Node, тогда как Python-аналоги отстают в покрытии и медленнее чинятся после очередных изменений Valve. Для проекта, где ферма ботов — это касса, неделя отставания означает неделю без выводов. Поскольку торговый слой всё равно остаётся на Node, писать остальной бэкенд на другом языке означало бы поддерживать две модели данных ради незначительного прироста производительности. В монорепозитории выделены приложения web на Next.js 15 и React 19, api на NestJS 11 с Prisma и Postgres, а также бот-воркер для фермы Steam-ботов. Общий пакет shared содержит изоморфную функцию расчёта шанса апгрейда, которая исполняется и на сервере, и в браузере, что исключает расхождение логики; при этом пакет намеренно разрезан на два входа, чтобы node:crypto не попадал в браузерный бандл.

Отдельного внимания заслуживает вопрос о смещении modulo bias, которое неизбежно возникает при делении 2^32 на 1 000 000. Первые 967 296 тикетов получают по 4295 возможных хешей, остальные — по 4294, что даёт перекос около 0,023%. Автор сознательно отказывается от rejection sampling, поскольку тот ломает главное свойство схемы — возможность проверить ролл калькулятором или одной строчкой в консоли. Этот компромисс зафиксирован в комментариях к коду, а не скрыт. Такой подход отличает caseforge от закрытых аналогов: там пользователю предлагают доверять странице с проверкой, не показывая ни самой реализации, ни допущений, на которых она построена. Здесь же видно, что даже учебный проект вынужден идти на компромиссы между строгостью математики и практичностью проверки, и эти компромиссы честно проговорены.

Ключевой вывод автора касается не алгоритма, а экономики. Даже полностью честный в смысле provably fair сайт может собирать кейс с RTP 85%, то есть в среднем забирать 15% от каждой ставки. Подкрутка ролла не нужна: она рискованна, поскольку раскрытие сида превращает её в математическое доказательство мошенничества, и бессмысленна, потому что настоящий рычаг — таблица диапазонов. Именно она определяет, какие предметы и с какой вероятностью попадают в кейс, и именно её оператор настраивает до вывода в продакшен. В админке проекта кейс собирается по заданному RTP, что наглядно показывает: прозрачность розыгрыша и выгодность для оператора — независимые параметры. Для российского рынка, где подобные сервисы находятся в серой зоне и часто блокируются, это означает, что апелляция к честности ролла не является аргументом в пользу игрока. Публикация исходников в этом смысле важна не как разоблачение конкретных площадок, а как демонстрация того, что открытый код и выгодная для оператора математика спокойно сосуществуют.

В тексте также приводится дисклеймер: покупка кейсов за реальные деньги в большинстве юрисдикций регулируется как азартная игра и требует лицензии, KYC и возрастной верификации. В проекте нет платежей, пополнение баланса — заглушка, отключённая по умолчанию. Автор подчёркивает, что запуск подобной кодовой базы на реальные деньги без юридической части является прямым нарушением, и MIT-лицензия этого не отменяет. Таким образом, caseforge — это не инструмент для создания очередного сайта с кейсами, а разбор архитектуры и математики, который показывает, где именно в таких сервисах заложено преимущество оператора. Открытым остаётся вопрос, изменит ли публикация исходников хоть что-то в поведении игроков, привыкших оценивать честность по наличию страницы с проверкой ролла, и появится ли у российских площадок стимул раскрывать не только алгоритм, но и таблицу диапазонов.