> ## 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. # Equidad en Mines > Cuándo se fija el tablero, cómo se deriva y qué vuelve a comprobar el programa al liquidar. Un tablero de Mines queda fijado antes de que elijas una sola casilla. La transacción de apertura fija el hash SHA-256 de una semilla del servidor aleatoria y captura un hash de slot de Solana, y el tablero es una función pura de ambos. Al liquidar, el programa vuelve a derivar todo el tablero on-chain y rechaza cualquier liquidación que no coincida con él. Esta página explica el mecanismo exacto detrás de cada tablero de [Mines](/es/docs/games/mines): qué se fija y cuándo, la derivación precisa del tablero, qué vuelve a comprobar el programa al liquidar y los límites honestos del esquema. Contexto: [Resumen de provably fair](/es/docs/provably-fair/overview). ## Qué se fija y cuándo Una partida de Mines empieza con una única transacción on-chain (`mines_start`) que hace tres cosas a la vez, **antes de que elijas cualquier casilla**: 1. **Fija la contribución del operador.** El backend genera una `server_seed` aleatoria de 32 bytes y la transacción guarda su hash SHA-256, el compromiso. La semilla en sí queda oculta hasta que termina la partida. 2. **Captura entropía de la cadena.** El programa lee el hash de slot más reciente del sysvar `SlotHashes` de Solana y lo guarda en la partida. 3. **Congela las condiciones.** La ventaja de la casa, el tope de pago y el tiempo límite de reembolso quedan registrados en tu partida; nada puede cambiar el precio de un tablero que ya estás jugando. El tablero es una función pura de la semilla fijada, el hash de slot guardado, tu cuenta y tu contador de partidas. **Desde ese momento el tablero está fijado**: las minas no pueden moverse según lo que elijas. Durante el juego, las casillas reveladas se sirven off-chain (eso es lo que las hace instantáneas); al final, la transacción de liquidación revela la semilla y el programa **vuelve a derivar todo el tablero on-chain**, rechazando cualquier liquidación que no coincida con él.

¿Cómo se deriva el tablero de Mines?

Las 25 casillas se numeran del 0 al 24, fila por fila en la cuadrícula de 5×5 (`index = row × 5 + column`). El tablero es una máscara de 25 bits: si el bit `t` está activo, la casilla `t` esconde una mina. ```text theme={null} entradas server_seed 32 bytes semilla del operador, fijada como sha256(server_seed) al iniciar la partida slothash 32 bytes último hash de slot de Solana cuando se ejecuta la transacción de inicio user 32 bytes la dirección de tu cuenta de usuario on-chain nonce 8 bytes tu contador de partidas de Mines, little-endian mines_count 1..24 la cantidad de minas que elegiste flujo aleatorio: bloques SHA-256 consumidos de 4 en 4 bytes block(k) = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k ) // "mines" = 5 bytes ASCII; k = contador de bloques 0, 1, 2, … en 8 bytes little-endian next_u32() = los siguientes 4 bytes sin leer del bloque actual, big-endian; cuando un bloque se agota, se pasa a block(k+1) extracción sin sesgo en 0..bound (muestreo por rechazo, sin sesgo de módulo) draw(bound): zone = 4294967295 − (4294967295 mod bound) repetir v = next_u32() hasta que v < zone devolver v mod bound tablero: barajado parcial de Fisher–Yates tiles = [0, 1, …, 24] mine_mask = 0 for i in 0..mines_count: j = i + draw(25 − i) intercambiar tiles[i] y tiles[j] mine_mask = mine_mask OR (1 << tiles[i]) ``` Detalles que importan cuando lo recalculas: * El orden de entrada al hash es exactamente: semilla, hash de slot, dirección de la cuenta de usuario, nonce (**8 bytes little-endian**), la etiqueta ASCII `"mines"` y luego el contador de bloques (**8 bytes little-endian**, empezando en 0). * Cada fragmento de 4 bytes se lee en **big-endian**. Un bloque da como máximo 8 extracciones; el flujo se recarga con el siguiente valor del contador cuando hace falta. * El bucle de muestreo por rechazo hace que cada extracción sea exactamente uniforme: el barajado no tiene ningún sesgo que discutir.

¿Qué fórmula de pago aplica el programa?

Cada casilla segura revelada multiplica tu cobro por la inversa exacta de tu probabilidad de sobrevivir, con la ventaja de la casa aplicada una sola vez: ```text theme={null} k−1 multiplicador = (1 − ventaja) × producto ( (25 − i) / (25 − M − i) ) i=0 M = cantidad de minas, k = cantidad de casillas seguras reveladas ``` El programa lo calcula con aritmética entera exacta y una única división entera final (el redondeo, como máximo de un punto básico, favorece a la casa). Con la ventaja actual del 1.5%: | Tablero | Multiplicador | | - | - | | 3 minas, 1 revelada | 1.1193x | | 3 minas, 2 reveladas | 1.2792x | | 24 minas, 1 revelada | 24.625x | | 1 mina, tablero completo (24 reveladas) | 24.625x | El retorno esperado es `1 − ventaja` para cualquier combinación de minas y casillas reveladas. Los valores actuales aparecen en [Comisiones y límites](/es/docs/fees-and-limits). ## Qué aplica el programa al liquidar La transacción de liquidación (`mines_settle`) revela la `server_seed` y declara un resultado: un cobro con un conjunto de casillas reveladas, o una derrota en una casilla concreta. Luego el programa lo comprueba todo on-chain: * `sha256(server_seed)` debe ser igual al compromiso guardado al iniciar la partida; una semilla distinta no puede liquidar la partida. * El tablero se **vuelve a derivar desde cero** con la fórmula anterior. Se rechaza cualquier casilla revelada que en realidad sea una mina; se rechaza una casilla de derrota declarada que no sea una mina; se rechaza una casilla de derrota que también se haya declarado como revelada. * El multiplicador se calcula on-chain a partir de la ventaja **registrada** y tu número real de casillas reveladas, así que el pago no puede informarse mal. * El evento de liquidación publica de forma permanente la semilla, el hash de slot, la máscara completa de minas, tus casillas reveladas y el resultado. ## Qué está garantizado y qué no **Lo que aplica el programa:** * El tablero queda fijado antes de tu primera elección, por el compromiso más el hash de slot guardado. Las minas no pueden moverse a mitad de la partida. * Al liquidar, el operador no puede mentir sobre el tablero: una semilla equivocada, una mina declarada como segura o una derrota falsa hacen que la transacción falle. * Las condiciones con las que empezaste (ventaja, tope de pago, tiempo límite) se aplican hasta el final de la partida. * Tu monto apostado nunca puede quedar bloqueado: si el operador nunca liquida, **cualquiera** puede ejecutar la cancelación una vez vencido el tiempo límite de la partida, lo que te reembolsa lo apostado. En la operación normal nunca llegas a eso: un tablero abandonado se cobra a su multiplicador actual antes del tiempo límite (consulta [Mines](/es/docs/games/mines)), así que conservas tus ganancias y no solo lo apostado. La cancelación sin permisos es la garantía de fondo, para el caso en que el operador ya no esté. **Las advertencias honestas:** * **El operador conoce el tablero mientras juegas.** Esto es estructural, no un defecto de este diseño en particular: las casillas se revelan al instante off-chain, y quien las sirve tiene que saber dónde están las minas. Ningún esquema de aleatoriedad elimina esto: incluso un tablero generado con VRF sería conocido por el operador en el momento en que sirve tu primera casilla. Lo que garantiza el compromiso es que ese conocimiento no puede usarse para *cambiar* el tablero ni para *informar mal* el resultado. * **Momento del inicio.** El tablero depende del hash de slot capturado cuando empieza tu partida, y la transacción de inicio la envía el backend: la misma consideración de tiempo que en los demás juegos. Conocer un tablero de antemano solo sirve si tus elecciones son predecibles; variar dónde haces clic anula cualquier selección de tablero basada en el tiempo. * **Anulaciones.** El operador puede cancelar una partida en curso (incluida, en principio, una que estés ganando). Una cancelación **reembolsa todo lo apostado** (no existe ninguna vía de confiscación) y siempre emite un evento público, así que cualquiera puede auditar on-chain la frecuencia de anulaciones. * Cada partida debe usar una semilla nueva: una semilla revelada es pública, y reutilizarla haría que el siguiente tablero se pudiera derivar públicamente. El programa rechaza on-chain la reutilización consecutiva, y el backend garantiza la unicidad global.

¿Cómo verificas una partida de Mines?

El evento de liquidación (`MinesGameSettled`) en la transacción final de tu partida contiene `server_seed`, `slothash`, `user`, `nonce`, `mines_count`, `mines_mask`, `revealed_mask`, `bust_tile`, `multiplier_bps` e `is_win`. Para verificar: 1. Comprueba el compromiso: `sha256(server_seed)` debe ser igual al `commit_hash` publicado en la transacción de inicio de tu partida (evento `MinesGameStarted`), lo que demuestra que el tablero quedó fijado antes de tu primera elección. 2. Vuelve a derivar la máscara de minas con la fórmula anterior y compárala con el `mines_mask` del evento. 3. Comprueba el resultado contra la máscara: cada bit de `revealed_mask` debe ser una casilla segura, y una casilla de derrota debe ser una mina. 4. Comprueba el multiplicador con la fórmula de pago. Consulta [Verificar una ronda](/es/docs/provably-fair/verify-a-round) para ver consejos generales sobre cómo leer los datos de eventos desde un explorador. Para saber cómo se juega, consulta la [guía de Mines](/es/docs/games/mines).