> ## 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. # Justiça no Mines > Quando o tabuleiro é registrado, como ele é derivado e o que o programa confere de novo na liquidação. Um tabuleiro do Mines é fixado antes de você escolher uma única casa. A transação de abertura registra (commit) o hash SHA-256 de uma seed do servidor aleatória e captura um hash de slot da Solana, e o tabuleiro é uma função pura dos dois. Na liquidação, o programa deriva de novo o tabuleiro inteiro on-chain e rejeita qualquer liquidação que não corresponda a ele. Esta página mostra o mecanismo exato por trás de cada tabuleiro do [Mines](/pt-BR/docs/games/mines): o que é registrado e quando, a derivação precisa do tabuleiro, o que o programa confere de novo na liquidação e os limites reais do esquema. Contexto: [Visão geral do provably fair (comprovadamente justo)](/pt-BR/docs/provably-fair/overview). ## O que é registrado, e quando Uma partida de Mines começa com uma única transação on-chain (`mines_start`) que faz três coisas ao mesmo tempo, **antes de você escolher qualquer casa**: 1. **Registra a contribuição do operador.** O backend gera uma `server_seed` aleatória de 32 bytes e a transação armazena o hash SHA-256 dela, o commit. A seed em si fica oculta até o fim da partida. 2. **Captura entropia da blockchain.** O programa lê o hash de slot mais recente do sysvar `SlotHashes` da Solana e o armazena na partida. 3. **Congela as condições.** A vantagem da casa, o teto de pagamento e o prazo de reembolso são registrados na sua partida; nada pode mudar o preço de um tabuleiro que você já está jogando. O tabuleiro é uma função pura da seed registrada, do hash de slot armazenado, da sua conta e do seu contador de partidas. **A partir desse momento o tabuleiro está fixado**: as minas não podem mudar de lugar em resposta às suas escolhas. Durante o jogo, as casas são reveladas off-chain (é isso que as torna instantâneas); no fim, a transação de liquidação revela a seed e o programa **deriva de novo o tabuleiro inteiro on-chain**, rejeitando qualquer liquidação que não corresponda a ele.

Como o tabuleiro do Mines é derivado?

As 25 casas são numeradas de 0 a 24, linha por linha na grade 5×5 (`index = row × 5 + column`). O tabuleiro é uma máscara de 25 bits: o bit `t` ligado significa que a casa `t` esconde uma mina. ```text theme={null} entradas server_seed 32 bytes seed do operador, registrada como sha256(server_seed) no início da partida slothash 32 bytes hash de slot mais recente da Solana quando a transação de início é executada user 32 bytes o endereço da sua conta de usuário on-chain nonce 8 bytes seu contador de partidas de Mines, little-endian mines_count 1..24 o número de minas que você escolheu fluxo aleatório: blocos SHA-256 consumidos 4 bytes por vez block(k) = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k ) // "mines" = 5 bytes ASCII; k = contador de blocos 0, 1, 2, … em 8 bytes little-endian next_u32() = próximos 4 bytes não lidos do bloco atual, big-endian; quando um bloco se esgota, passa para block(k+1) sorteio sem viés em 0..bound (amostragem por rejeição, sem viés de módulo) draw(bound): zone = 4294967295 − (4294967295 mod bound) repita v = next_u32() até v < zone retorne v mod bound tabuleiro: embaralhamento Fisher–Yates parcial tiles = [0, 1, …, 24] mine_mask = 0 for i in 0..mines_count: j = i + draw(25 − i) troque tiles[i] e tiles[j] mine_mask = mine_mask OR (1 << tiles[i]) ``` Detalhes que importam quando você recalcula: * A ordem de entrada do hash é exatamente: seed, hash de slot, endereço da conta de usuário, nonce (**8 bytes little-endian**), a tag ASCII `"mines"` e, por fim, o contador de blocos (**8 bytes little-endian**, começando em 0). * Cada pedaço de 4 bytes é lido em **big-endian**. Um bloco rende no máximo 8 sorteios; o fluxo é reabastecido com o próximo valor do contador conforme necessário. * O laço de amostragem por rejeição torna cada sorteio exatamente uniforme: o embaralhamento não tem nenhum viés a discutir.

Qual fórmula de pagamento o programa aplica?

Cada casa segura revelada multiplica o seu cash out pelo inverso exato da sua chance de sobreviver, com a vantagem da casa aplicada uma única vez: ```text theme={null} k−1 multiplicador = (1 − vantagem) × produto ( (25 − i) / (25 − M − i) ) i=0 M = número de minas, k = número de casas seguras reveladas ``` O programa calcula isso com aritmética inteira exata e uma única divisão com arredondamento para baixo no final (o arredondamento, de no máximo um ponto-base, favorece a casa). Com a vantagem atual de 1.5%: | Tabuleiro | Multiplicador | | - | - | | 3 minas, 1 casa revelada | 1.1193x | | 3 minas, 2 casas reveladas | 1.2792x | | 24 minas, 1 casa revelada | 24.625x | | 1 mina, tabuleiro limpo (24 casas reveladas) | 24.625x | O retorno esperado é `1 − vantagem` para qualquer combinação de minas e casas reveladas. Os valores atuais estão em [Taxas e limites](/pt-BR/docs/fees-and-limits). ## O que o programa aplica na liquidação A transação de liquidação (`mines_settle`) revela a `server_seed` e declara um resultado: um cash out com um conjunto de casas reveladas, ou um estouro em uma casa específica. O programa então confere tudo on-chain: * `sha256(server_seed)` precisa ser igual ao commit armazenado no início da partida; uma seed diferente não consegue liquidar a partida. * O tabuleiro é **derivado de novo do zero** com a fórmula acima. Qualquer casa revelada que na verdade seja uma mina é rejeitada; uma casa de estouro declarada que não seja mina é rejeitada; uma casa de estouro que também tenha sido declarada como revelada é rejeitada. * O multiplicador é calculado on-chain a partir da vantagem **registrada** e do número real de casas que você revelou, então o pagamento não pode ser informado errado. * O evento de liquidação publica a seed, o hash de slot, a máscara completa de minas, as casas que você revelou e o resultado, para sempre. ## O que é garantido, e o que não é **Garantido pelo programa:** * O tabuleiro é fixado antes da sua primeira escolha, pelo commit mais o hash de slot armazenado. As minas não podem mudar de lugar no meio da partida. * Na liquidação, o operador não pode mentir sobre o tabuleiro: seed errada, uma mina declarada como segura ou um estouro falso fazem a transação falhar. * As condições com que você começou (vantagem, teto de pagamento, prazo) valem até o fim da partida. * O seu valor apostado nunca pode ficar travado: se o operador nunca liquidar, o cancelamento pode ser chamado por **qualquer pessoa** depois do prazo da partida, reembolsando o valor apostado. Em operação normal você nunca chega a isso: um tabuleiro abandonado recebe cash out no multiplicador atual antes do prazo (veja [Mines](/pt-BR/docs/games/mines)), então você fica com os seus ganhos, e não só com o valor apostado. O cancelamento sem permissão é a garantia de base, para o caso de o operador desaparecer. **As ressalvas honestas:** * **O operador conhece o tabuleiro enquanto você joga.** Isso é estrutural, não uma falha deste design em particular: as casas são reveladas instantaneamente off-chain, e quem as revela precisa saber onde estão as minas. Nenhum esquema de aleatoriedade elimina isso: mesmo um tabuleiro gerado por VRF seria conhecido pelo operador no momento em que ele revela a sua primeira casa. O que o commit garante é que esse conhecimento não pode ser usado para *mudar* o tabuleiro nem para *informar errado* o resultado. * **Momento do início.** O tabuleiro depende do hash de slot capturado quando a sua partida começa, e a transação de início é enviada pelo backend, a mesma questão de timing dos outros jogos. Conhecer um tabuleiro com antecedência só ajuda se as suas escolhas forem previsíveis; variar onde você clica neutraliza qualquer seleção de tabuleiro baseada em timing. * **Anulações.** O operador pode cancelar uma partida em andamento (inclusive, em princípio, uma que você está ganhando). Um cancelamento **reembolsa todo o valor apostado** (não existe caminho de confisco) e sempre emite um evento público, então a frequência de anulações pode ser auditada on-chain por qualquer pessoa. * Cada partida precisa usar uma seed nova: uma seed revelada é pública, e reutilizá-la tornaria o próximo tabuleiro derivável por qualquer um. O programa rejeita on-chain a reutilização em partidas consecutivas, e o backend garante a unicidade global.

Como verificar uma partida de Mines?

O evento de liquidação (`MinesGameSettled`) na transação final da sua partida traz `server_seed`, `slothash`, `user`, `nonce`, `mines_count`, `mines_mask`, `revealed_mask`, `bust_tile`, `multiplier_bps` e `is_win`. Para verificar: 1. Confira o commit: `sha256(server_seed)` precisa ser igual ao `commit_hash` publicado na transação de início da sua partida (evento `MinesGameStarted`), o que prova que o tabuleiro foi travado antes da sua primeira escolha. 2. Derive de novo a máscara de minas com a fórmula acima e compare com o `mines_mask` do evento. 3. Confira o resultado contra a máscara: cada bit de `revealed_mask` precisa ser uma casa segura, e uma casa de estouro precisa ser uma mina. 4. Confira o multiplicador com a fórmula de pagamento. Veja [Verificar uma rodada](/pt-BR/docs/provably-fair/verify-a-round) para dicas gerais sobre como ler os dados de eventos em um explorador. Para saber como o jogo em si funciona, veja o [guia do jogo Mines](/pt-BR/docs/games/mines).