Provably Fair

1. Что именно проверяется

Новые раунды используют winshot-v3: 100 000 билетов (0–99 999), RTP и зафиксированные билетные зоны. Старые winshot-v1 и winshot-v2 проверяются в прежнем диапазоне 0–4 294 967 295. Для каждого предложения сервер создаёт случайный 32-байтовый server seed и возвращает его SHA-256 hash. После получения предложения браузер генерирует client seed и отправляет его при принятии ставки. Предложение действует 60 секунд.

После завершения сервер раскрывает server seed, client seed, ID раунда, билет и порог победы. Сохранённый заранее хеш позволяет проверить, что сервер не заменил секрет после получения client seed. Сам по себе хеш, полученный вместе с готовым результатом, этого не доказывает.

2. Шанс и выигрышный диапазон

Расчёт выполняется по целым минимальным единицам коинов. stake — стоимость предметов и добавленных коинов; target — цена цели. Для новых раундов winshot-v3 chanceBps = min(maxChanceBps, floor(stake × rtpBps / target)), где maxChanceBps равен 8000: максимальный шанс — 80%. При RTP 90% rtpBps равен 9000. Старые раунды проверяются с сохранённым для них пределом; в доказательствах без maxChanceBps используется прежнее значение 9000. В старой winshot-v1 вместо rtpBps используется 10000. Ставка с шансом ниже 1% отклоняется, цель должна быть дороже ставки. Выигрышные билеты распределяются между источниками стоимости пропорционально с точным целочисленным округлением. Источник выигранного билета наследуется новым предметом.

Из HMAC-SHA256 берутся первые четыре байта как беззнаковое число big-endian. В v3 значения от 4 294 900 000 включительно отбрасываются; HMAC пересчитывается с четвёртым элементом сообщения — счётчиком попытки начиная с 1 — пока число не окажется ниже границы. Билет равен остатку деления принятого числа на 100 000. Это исключает смещение вероятностей. Победа строго при ticket < threshold; равенство — проигрыш. В v1/v2 используется исходный 32-битный билет без отбора.

message = JSON.stringify(["winshot-v3", String(roundId), clientSeed])
n = UInt32BE(HMAC_SHA256(hexToBytes(serverSeed), UTF8(message))[0..3])
attempt = 0
while n >= 4294900000:
  attempt += 1
  message = JSON.stringify(["winshot-v3", String(roundId), clientSeed, attempt])
  n = UInt32BE(HMAC_SHA256(hexToBytes(serverSeed), UTF8(message))[0..3])
ticket = n % 100000
threshold = chanceBps * 10
won = ticket < threshold
rollPercent = ticket / 100000 * 100

3. Как проверить раунд

Сохраните commitment из ответа /api/upgrades/prepare до принятия ставки. После завершения данные вашей игры доступны в ответе /api/upgrades/{id}/accept и через GET /api/upgrades/{id} после авторизации. Проверка ниже принимает JSON этого ответа и не отправляет введённые данные на сервер.

Хеш commitment вычисляется от UTF-8 строки serverSeed, содержащей 64 hex-символа; ключ HMAC — это уже декодированные из hex 32 байта. ID раунда в сообщении обязательно передаётся строкой. Различие между текстом и байтами важно для воспроизведения результата.

Вставьте исходный commitment и шанс из предложения, чтобы дополнительно сопоставить результат с параметрами до игры. Без них можно проверить только внутреннюю согласованность предоставленного результата, но не неизменность первоначального предложения.

4. Анимация и границы проверки

Вращение стрелки не генерирует случайное число. Быстрый и медленный режимы показывают один и тот же серверный результат; переключение скорости не меняет вероятность.

При обычной игре браузер автоматически сопоставляет раскрытый секрет с исходным commitment. Полный пересчёт HMAC доступен в форме ниже. Провал проверки требует разбора сохранённых параметров раунда, а не повторной ставки.

Provably Fair не гарантирует выигрыш, надёжность платежей, доступность вывода или соблюдение оператором юридических требований. Проверка алгоритма также не заменяет независимый аудит всего сервиса.