> ## 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. # Resumen de provably fair > El esquema de compromiso y revelación en palabras simples, lo que aporta la entropía de la cadena y lo que puedes comprobar tú mismo. Banner de provably fair Cada resultado de juego en My Crypto Casino se produce con un **esquema de compromiso y revelación combinado con la entropía de la cadena de Solana**, ejecutado por el programa on-chain. Para ti como jugador, eso significa dos cosas: 1. **El resultado no se puede cambiar a posteriori.** El operador fija su aporte (un valor secreto) *antes* de jugar, publicando on-chain una huella criptográfica de ese valor. Después, el programa se niega a liquidar si el secreto revelado no coincide exactamente con esa huella. 2. **Puedes comprobarlo todo tú mismo.** Todas las entradas y la fórmula exacta son públicas. Después de cualquier ronda o apuesta, puedes recalcular el resultado a partir de los datos on-chain y compararlo con lo que pagó el juego. Esta página explica el esquema en palabras simples. Las páginas de cada juego dan las fórmulas exactas, y [Verificar una ronda](/es/docs/provably-fair/verify-a-round) te guía paso a paso para comprobar una ronda real. Compromiso, juego, revelación, verificación: el secreto queda sellado on-chain antes de jugar, el programa lo comprueba al revelarse y, después, cualquiera puede recalcular cada resultado

¿De qué está hecho provably fair?

**Un secreto fijado de antemano.** Cuando un resultado debe permanecer oculto durante el juego (Crash, Mines), el backend genera un secreto aleatorio de 32 bytes y publica on-chain su hash SHA-256 (el *compromiso*) antes de que empiece el juego. Un hash funciona como un sobre sellado: no revela nada del secreto, pero una vez publicado, solo ese secreto exacto puede coincidir con él. Cuando el secreto se revela al final, el propio programa calcula su hash y rechaza la transacción si no coincide con el compromiso. **Entropía de la cadena de Solana.** El resultado nunca depende solo del secreto. También incorpora un **hash de slot**: el hash de un slot reciente de Solana, que el programa lee del sysvar `SlotHashes` de Solana en un momento definido. Este valor lo produce la red de Solana, no el casino, y todavía no existe cuando se hace el compromiso. **Una fórmula pública y determinista.** El resultado es una función matemática fija de esas entradas. La misma función se ejecuta dentro del programa on-chain (el backend no puede informar un resultado falso; lo calcula el programa), y está publicada en estas páginas para que puedas ejecutarla tú mismo.

¿Cómo transcurre una ronda, paso a paso?

```mermaid theme={null} sequenceDiagram participant MCC as Backend de MCC (operador) participant SOL as Programa de Solana participant You as Jugador Note over MCC,SOL: 1. Compromiso MCC->>SOL: Publica compromiso = sha256(secreto) Note over You,SOL: 2. Juego You->>SOL: Las apuestas se hacen on-chain Note over SOL: 3. Entropía de la cadena SOL->>SOL: Captura el hash de slot más reciente de Solana Note over MCC,SOL: 4. Revelación MCC->>SOL: Envía el secreto SOL->>SOL: Verifica que sha256(secreto) coincide con el compromiso SOL->>SOL: Calcula el resultado con la fórmula pública Note over You: 5. Verificación (en cualquier momento después) You->>SOL: Lee de la cadena el compromiso, el hash de slot y el secreto You->>You: Recalcula el resultado y compara ``` Dice condensa este flujo en una sola transacción: no tiene ningún estado oculto que proteger, así que no hay ningún secreto del operador. La tirada se deriva del hash de slot, tu cuenta y tu contador de apuestas, y se liquida en la misma instrucción que la genera. ## Qué fija cada juego, y cuándo | Juego | Secreto del operador | Entropía de la cadena | Resultado fijado en | Aplicado on-chain | | - | - | - | - | - | | [Crash](/es/docs/provably-fair/crash) | Secreto de 32 bytes, fijado **antes de que se abran las apuestas** | Hash de slot capturado al empezar la ronda | Inicio de la ronda | Comprobación del compromiso + punto de crash calculado por el programa al revelarse | | [Dice](/es/docs/provably-fair/dice) | Ninguno | Hash de slot en el momento en que llega tu transacción de apuesta | Inclusión de la transacción de apuesta | Tirada derivada y liquidada por el programa en una sola instrucción | | [Mines](/es/docs/provably-fair/mines) | Semilla de 32 bytes, fijada **en la transacción que inicia tu partida** | Hash de slot capturado en esa misma transacción de inicio | Inicio de la partida, antes de tu primera elección | Comprobación de la semilla + tablero completo vuelto a derivar por el programa al liquidar | ## Qué garantiza esto, y qué da por supuesto Aquí la honestidad importa más que el marketing, así que seamos precisos. Este esquema es **de compromiso y revelación con entropía pública de la cadena, no un VRF** (función aleatoria verificable). Esta es la frontera exacta entre lo que *aplica el código* y lo que *depende de que el operador se porte bien*. ### Aplicado por el programa on-chain * **No se pueden cambiar resultados después del compromiso.** El programa calcula el hash del secreto revelado y rechaza cualquier liquidación en la que no coincida con el compromiso publicado. El operador no puede elegir otro secreto después de ver cómo va una ronda. * **Entropía que el operador no produce.** El hash de slot viene de la red de Solana. Es desconocido cuando se publica el compromiso, y el casino no lo genera. * **Resultados calculados on-chain.** El punto de crash, la tirada de dados y el tablero de Mines los calcula (o los vuelve a derivar y comprueba) el propio programa. El backend no puede informar un resultado que la fórmula no produzca. * **Auditabilidad pública total.** Cada ronda y cada apuesta emiten eventos on-chain con todas las entradas de la derivación y el resultado. Cualquiera, no solo el jugador involucrado, puede recalcular todos los resultados históricos. ### Lo que se da por supuesto: las advertencias honestas * **Influencia sobre el momento.** El backend del operador elige *cuándo* enviar ciertas transacciones, lo que le da una influencia parcial sobre *qué* hash de slot se captura. Cada página por juego explica exactamente qué podría y qué no podría lograr con esto en ese juego. * **Las cancelaciones son posibles, pero solo con reembolso.** El operador puede anular una ronda de Crash o una partida de Mines. Una anulación siempre reembolsa todo lo apostado (el programa no tiene forma de confiscar mediante una cancelación), y cada anulación queda registrada públicamente, así que cualquiera puede auditar la frecuencia de cancelaciones. Cancelaciones frecuentes serían la huella visible on-chain de un operador que se porta mal. * **El operador conoce el tablero de Mines durante el juego.** Esto es estructural: las casillas se revelan al instante off-chain, y quien las revela tiene que conocer el tablero. El compromiso garantiza que el tablero quedó fijado antes de tu primera elección y que no se puede reescribir después. Consulta [Equidad en Mines](/es/docs/provably-fair/mines) para ver exactamente cómo se aplica. ### ¿Por qué aceptar estas concesiones? Porque son el precio de un juego instantáneo y fluido, no atajos. Cada juego se ubica exactamente donde tiene que estar en ese espectro: * **Mines**: revelar una casilla en milisegundos requiere, estructuralmente, una parte que ya conozca el tablero. Las alternativas (una transacción on-chain por clic, o una consulta de ida y vuelta a un oráculo por cada revelación) convertirían cada casilla en una comisión y una espera. Un operador que conoce el tablero es indispensable para un Mines que se sienta instantáneo y aun así se liquide on-chain; el esquema de compromiso existe para acotar lo que ese conocimiento puede hacer. * **Crash**: una ronda en vivo compartida necesita que alguien la conduzca para todos los jugadores a la vez. Es una elección pragmática más que una necesidad estructural, y por eso el programa incluye una vía de migración integrada hacia aleatoriedad basada en oráculos (VRF), una fase futura que eliminaría las advertencias sobre el momento allí donde la economía lo permita. * **Dice**: el otro extremo del espectro. No hay nada que ocultar durante el juego, así que no hay ningún secreto del operador. Donde eliminar la confianza en el operador no cuesta nada, el diseño la elimina. En resumen: el operador gestiona los juegos, y la cadena hace que hacer trampa sea **imposible** (cualquier cosa posterior al compromiso) o **detectable públicamente** (patrones de tiempo, frecuencia de cancelaciones, estadísticas de tasa de victorias). **Equidad del resultado vs. custodia de los fondos** Esta sección trata de cómo se generan los *resultados*. Cómo se custodian on-chain los depósitos, los saldos y los retiros es otro tema; consulta [Arquitectura on-chain](/es/docs/security/on-chain-architecture). ## Verifícalo tú mismo * En la app, cada ronda de Crash terminada muestra sus datos de equidad (el secreto revelado, el hash de bloque y enlaces a las transacciones on-chain) en los detalles de la ronda, junto con una herramienta de equidad de un solo clic. * Dice y Mines publican todas las entradas de la derivación en el evento de liquidación de la propia transacción de la apuesta. [Verificar una ronda](/es/docs/provably-fair/verify-a-round) recorre todo el proceso, desde los datos de la app hasta recalcular el resultado con unas pocas líneas de código.