Публикация появилась в потоке «Разработка» и представляет собой разбор архитектуры учебного проекта, а не анонс коммерческого запуска. Автор подчёркивает, что платежей в системе нет вообще: пополнение баланса реализовано как заглушка, отключённая в продакшене. Цель работы — показать, как устроена честность, которую можно проверить, и как математика кейса определяет его экономику.

Репозиторий github.com/ialakey/caseforge включает несколько приложений: веб-часть на Next.js 15 с App Router, React 19, Tailwind, Zustand и socket.io-client, API на NestJS 11 поверх Fastify с Prisma 6, Postgres 16, Redis 7, BullMQ и socket.io, а также Node-воркер, обслуживающий ферму Steam-ботов и очередь выводов. Общий пакет packages/shared содержит типы, zod-схемы, переводы, тикеты и логику provably fair. Весь стек написан на TypeScript, и, по словам автора, этот выбор ему не принадлежал — история связана с интеграцией Steam и вынесена в отдельную статью.

Функционально проект закрывает полный цикл: вход через Steam, открытие кейса с проверяемым роллом, апгрейд предметов, контракт из нескольких вещей в одну, ежедневное колесо бонусов, промокоды на пополнение, инвентарь с историей и обратной продажей, очередь выводов и админку. В админке кейс собирается под нужный RTP ещё до того, как уйдёт в прод. Каталог и живая лента дропов подтягивают цены из Steam-маркета, а переключатели языка и валюты находятся в шапке сайта. Каждый кейс на витрине публикует состав с редкостью, текущей ценой и точным шансом каждого предмета — например, 0,90% на карамбит и 63,20% на M4A1-S. Это не рекламные цифры, а те самые диапазоны тикетов, против которых роллит сервер.

Схема provably fair построена на паре сидов. Сервер генерирует serverSeed из 32 случайных байт и публикует только его sha256, игрок задаёт clientSeed или получает случайный и может менять его когда угодно, а счётчик nonce растёт на каждом открытии. Ролл считается через HMAC-SHA256 от строки clientSeed:nonce, из хеша берутся первые восемь шестнадцатеричных знаков, приводятся к числу и берётся остаток от деления на фиксированный тикет-спейс в миллион. Выпадает предмет, чей диапазон тикетов накрыл полученное значение. При ротации серверного сида старый раскрывается целиком, и любой прошлый ролл пересчитывается и сверяется с опубликованным хешем. Автор отдельно объясняет, почему выбраны диапазоны тикетов, а не веса: диапазон проверяется в уме, а порядок обхода массива на результат не влияет, тогда как с весами пришлось бы верить нормализации на слово. Размер тикет-спейса зафиксирован навсегда — его изменение сделает все прошлые открытия непроверяемыми. Перепроверка в браузере написана отдельной реализацией на Web Crypto, чтобы страница верификации не проверяла согласованность сервера с самим собой. Пакет shared пришлось разрезать на два входа: основной изоморфный и серверный за сабпасом, иначе node:crypto уезжает в браузерный бандл и фронт перестаёт собираться.

Отдельно автор разбирает modulo bias, который решил не убирать. Два в степени 32 на миллион нацело не делится: первые 967 296 тикетов получают по 4295 хешей, остальные по 4294, что даёт перекос порядка 0,023%, одинаковый для всех и на порядки меньший шага цен. Rejection sampling не применяется сознательно, потому что он ломает главное свойство схемы — возможность проверить ролл калькулятором и одной строчкой в консоли. Как только появляется цикл «не подошло — берём следующий хеш», объяснить проверку обычному человеку становится втрое сложнее. Автор счёл, что 0,023% того не стоят, и написал это в комментарии к коду прямым текстом, предложив оспорить решение в комментариях.

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

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