> ## Documentation Index > Fetch the complete documentation index at: https://docs.mycryptocasino.com/llms.txt > Use this file to discover all available pages before exploring further. # Dice 공정성 > 운영자 비밀값이 필요 없는 이유와, 공개 입력값으로부터의 전체 도출 과정입니다. Dice 결과에는 운영자 비밀값이 전혀 사용되지 않습니다. 베팅이 실행될 때 기록된 Solana 슬롯 해시, 계정 주소, 개인 베팅 카운터로부터 온체인에서 도출되며, 베팅을 넣은 바로 그 트랜잭션 안에서 정산됩니다. 운영자가 고를 수 있는 시드도 없고, 나중에 공개할 것도 없습니다. 이 페이지에서는 모든 [Dice](/ko/docs/games/dice) 결과 뒤에 있는 정확한 메커니즘을 설명합니다. Dice는 [공정성 검증 방식](/ko/docs/provably-fair/overview) 중 가장 단순한 경우로, **운영자 비밀값이 전혀 없습니다**. 결과는 공개 입력값으로부터 도출되며, 베팅을 넣는 트랜잭션 안에서 온체인으로 정산됩니다.

Dice에는 왜 커밋 단계가 없나요?

Crash는 라운드가 진행되는 동안 결과가 *확정되어 있으면서도 숨겨져* 있어야 하므로 비밀값을 커밋해야 합니다. Dice에는 그런 단계가 없습니다. 결과는 그 결과를 뽑는 명령어 안에서 바로 사용됩니다. 그래서 비밀값을 커밋하는 대신, 도출 과정에 **운영자 입력을 전혀 사용하지 않습니다**. 커밋할 것도, 공개할 것도 없으며, 운영자가 유리하게 고를 수 있는 시드도 없습니다. 엔트로피는 Solana 네트워크 자체에서 나오며, 여기에 베팅을 식별하는 값이 섞입니다. * **`slothash`**: 베팅 트랜잭션이 실행되는 순간 Solana `SlotHashes` sysvar의 가장 최근 항목입니다. 네트워크가 생성하는 엔트로피로, 트랜잭션을 만드는 시점에는 알 수 없습니다(보내는 쪽은 트랜잭션이 정확히 어느 슬롯에 포함될지 알 수 없습니다). * **`user`**: 온체인 사용자 계정(프로그램이 지갑으로부터 도출하는 계정)의 32바이트 주소입니다. 덕분에 플레이어마다 결과가 독립적이며, 같은 슬롯에 들어간 두 베팅도 서로 다른 결과를 받습니다. * **`nonce`**: 온체인에 저장되고 플레이할 때마다 증가하는 개인 베팅 카운터입니다. 같은 슬롯 안에서도 본인의 연속 베팅이 서로 독립적이 되며, 중복 제출 방지 역할도 합니다.

Dice 결과의 정확한 공식은 무엇인가요?

```text theme={null} 입력값 slothash 32바이트 베팅 트랜잭션 실행 시점의 최신 Solana 슬롯 해시 user 32바이트 온체인 사용자 계정의 주소 nonce 8바이트 베팅 카운터, 리틀엔디언 도출 hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce ) // "dice" = ASCII 4바이트 0x64 0x69 0x63 0x65 roll = u128_be( hash[0..16] ) mod 10000 // 처음 16바이트, 빅엔디언 부호 없는 128비트 결과 roll은 0..9999 범위의 정수이며, 소수점 둘째 자리까지의 0.00–99.99에 해당합니다 ``` 다시 계산할 때 중요한 세부 사항: * 해시 입력은 정확히 이 순서대로 이어 붙인 값입니다. ASCII 태그 `"dice"`, 슬롯 해시, 사용자 계정 주소, 그리고 **8바이트 리틀엔디언**으로 인코딩한 논스(nonce)입니다. * 샘플은 SHA-256 출력의 **처음 16바이트**를 **빅엔디언** 부호 없는 128비트 정수로 읽은 뒤, 10,000으로 나눈 나머지입니다. * 128비트 샘플을 10,000으로 나눈 나머지에는 이론적으로 2⁻¹¹⁴ 미만의 편향이 있습니다. 이는 하우스 엣지보다 수십 자릿수나 작은 값이므로, 보정하지 않고 문서로 명시합니다. ## 승리 조건과 지급액 ```text theme={null} 언더 : roll < target이면 승리 승률 = 10000가지 결과 중 target가지 오버 : roll > target이면 승리 승률 = 10000가지 결과 중 9999 − target가지 multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps ) ``` 선택하는 승률은 2%에서 98% 사이여야 합니다. 현재 하우스 엣지 1.5%(`edge_bps = 150`) 기준: | 베팅 | 승률 | 배수 | | - | - | - | | 언더 5000 | 50% | 1.97x | | 언더 200 | 2% | 49.25x | | 언더 9800 | 98% | 1.0051x | 기대 수익률은 모든 목표에서 동일하게 베팅액 대비 `승률 × 배수 ≈ 98.5%`입니다(내림 처리로 인한 차이는 하우스에 유리하게 최대 1 베이시스 포인트입니다). 현재 하우스 엣지와 한도는 [수수료 및 한도](/ko/docs/fees-and-limits)에 나와 있습니다. ## 보장되는 것과 보장되지 않는 것 **프로그램이 강제하는 사항:** * 결과는 프로그램이 직접 읽는 입력값으로부터, 하나의 온체인 명령어 안에서 도출**되고** 정산됩니다. 백엔드는 결과를 제공하지 않으며, 잘못 보고할 수도 없습니다. * 운영자는 도출 과정에 **아무 입력도** 제공하지 않습니다. 유리한 결과를 얻기 위해 반복 시도할 서버 시드가 없습니다. * 논스는 정확히 일치해야 하므로, 같은 베팅이 실수로(또는 악의적으로) 두 번 플레이될 수 없습니다. * 모든 플레이가 도출 입력값과 결과를 모두 게시하므로, 과거의 모든 결과를 누구나 다시 계산할 수 있습니다. **솔직하게 밝혀 두는 한계: 제출 시점.** Dice 베팅은 가스비가 없습니다. MCC 백엔드가 트랜잭션에 서명하고 대신 제출하므로, 운영자가 *언제* 제출할지를 통제합니다. 슬롯 `N−1`의 해시는 슬롯 `N`이 시작될 때 공개되므로, 지연 시간이 매우 짧은 운영자라면 베팅이 현재 슬롯에 포함될 *경우* 받을 결과를 추정하고, 제출을 늦춰 다시 뽑을 수도 있습니다. 이 방식은 그렇지 않은 척하기보다 이 점을 인정합니다(이를 없애려면 VRF 오라클이 필요한데, 베팅당 비용이 소액 베팅에서 하우스의 기댓값을 넘어섭니다). 이를 제한하는 요소는 다음과 같습니다. * 포함 시점을 완전히 통제할 수 없습니다. 트랜잭션이 들어갈 정확한 슬롯은 보내는 쪽이 아니라 네트워크가 결정합니다. * 모든 입력값이 게시되므로, 제출 지연 패턴이나 전체 승률이 표시된 확률에서 벗어나는 정도를 공개 데이터로 **누구나 측정할 수 있습니다**. 체계적인 악용은 숨겨질 수 없습니다.

Dice 결과는 어떻게 검증하나요?

모든 플레이는 해당 베팅의 트랜잭션 안에서 `DiceBetSettled` 이벤트를 발생시키며, 여기에 필요한 모든 값이 담겨 있습니다. `slothash`, `user`, `nonce`, `target_bps`, `direction`, `win_chance_bps`, `roll`, `multiplier_bps`, `is_win`, 그리고 전체 정산 내역입니다. 검증 방법: 1. Solana 익스플로러에서 베팅 트랜잭션을 열고 이벤트 필드를 읽습니다(앱의 Dice 화면에 현재 세션의 공정성 입력값이 표시되며, 베팅 기록에서 해당 트랜잭션으로 이동할 수 있습니다). 2. `sha256("dice" ‖ slothash ‖ user ‖ nonce)`를 다시 계산하고, 처음 16바이트를 빅엔디언으로 읽어 10,000으로 나눈 나머지를 이벤트의 `roll`과 비교합니다. 3. 승패 판정(언더는 `roll < target`, 오버는 `roll > target`)과 배수를 위 공식과 대조합니다. 익스플로러에서 이벤트 데이터를 읽는 일반적인 방법은 [라운드 검증](/ko/docs/provably-fair/verify-a-round)을 참고하세요. 게임 플레이 방법은 [Dice 게임 가이드](/ko/docs/games/dice)를 참고하세요.