Algoritmo del juego crash: cómo se determina realmente el multiplicador (a nivel de código)

Las búsquedas sobre el algoritmo de los juegos crash llevan a docenas de artículos que prometen explicar cómo funcionan las matemáticas, casi todos puro relleno de marketing ("la IA calcula el multiplicador a partir de los patrones de apuesta de los jugadores") o ficción ("Aviator usa predicción por cadenas de Markov"). El algoritmo real está documentado públicamente por todos los grandes proveedores, cabe en tres líneas de código y usa una única primitiva criptográfica conocida (SHA-256 o SHA-512). Esta pieza recorre la fórmula a nivel de código para que veas exactamente qué determina el multiplicador de cada ronda. Las matemáticas son cortas; las implicaciones para la confianza son grandes.

Conocer el algoritmo es la base de la confianza a nivel de ronda. Sin él, te toca aceptar la palabra del casino de que está ejecutando matemáticas honestas. Con él, puedes recalcular cualquier ronda en 60 segundos y confirmar o desmentir el compromiso criptográfico. La información es abierta y gratuita; la única barrera es la voluntad de leer tres líneas de código.

Determinista significa que todo queda fijado antes de la ronda

La propiedad más importante del algoritmo del juego crash es ésta: es determinista. Con datos idénticos (semilla del servidor, semilla(s) del cliente, nonce), la fórmula produce siempre la misma salida. Ejecútalo en un portátil de hace 10 años o en un superordenador cuántico; el resultado es idéntico bit a bit. No hay aleatoriedad dentro del algoritmo en sí.

¿Por qué importa? Porque el determinismo es lo que hace posible la verificación provably fair. El casino se compromete con una semilla del servidor antes de la ronda; la semilla se hashea y el hash se publica. Cuando termina la ronda, el casino revela la semilla; cualquiera que ejecute el mismo algoritmo con las mismas semillas más el nonce produce el mismo multiplicador. Si hay discrepancia, las matemáticas son evidencia inequívoca de que algo se torció.

¿De dónde sale la aparente aleatoriedad? De las semillas. Las semillas del servidor las genera el generador pseudoaleatorio del casino antes de la ronda (con entropía a nivel de SO más librerías criptográficas). Las semillas del cliente vienen de los jugadores (Spribe las toma de las tres primeras apuestas en vivo; SmartSoft del jugador que apuesta). Las semillas son impredecibles para cualquier parte que no las controle; una vez comprometidas, el algoritmo se ejecuta de forma determinista sobre ellas.

Por eso "el casino elige multiplicadores bajos cuando muchos jugadores apuestan a multiplicadores altos" es mecánicamente imposible en esquemas provably fair. Las semillas se comprometen antes de que el casino vea las apuestas; el algoritmo se ejecuta de forma determinista sobre esas semillas comprometidas; el multiplicador resultante es lo que producen las matemáticas. El casino no tiene oportunidad de manipular nada después del compromiso.

La fórmula del multiplicador a nivel de código

La fórmula completa en tres pasos:

Paso 1: hashea las semillas + el nonce.

hash_input = server_seed + "|" + client_seed_1 + "|" + client_seed_2 + "|" + client_seed_3 + "|" + nonce
digest = SHA-512(hash_input) // para Spribe / Aviator

SmartSoft y la mayoría del resto usan SHA-256 con una sola semilla del cliente: digest = SHA-256(server_seed + "|" + client_seed + "|" + nonce)

Paso 2: extrae una fracción h del digest.

// Spribe: primeros 13 caracteres hex
hex_slice = digest[0:13]
// Convierte hex a entero, divide entre el máximo posible (16^13)
h = int(hex_slice, 16) / (16 ** 13)

SmartSoft usa una longitud distinta de segmento hex (típicamente 8 caracteres), pero el principio es el mismo: extrae un trozo del digest, conviértelo de hex a decimal, divide por el valor máximo posible y obtienes una fracción h entre 0 y 1 (excluido el 1).

Paso 3: calcula el multiplicador.

house_edge = 3 // para Aviator (3% de margen = 97% RTP)
crash_point = (100 - house_edge) / (100 * (1 - h))
crash_point = round(crash_point, 2) // redondea a 2 decimales

Eso es todo el algoritmo. Tres pasos, menos de 10 líneas de código. La salida es determinista; los datos son públicos al cerrar la ronda; la verificación está al alcance de cualquiera con conocimientos básicos de hashing criptográfico.

Si quieres el recorrido operativo de la verificación sobre rondas reales, nuestra pieza de cómo verificar una ronda de juego crash cubre el procedimiento pasó a paso con capturas. El verificador de navegador implementa la fórmula directamente vía la API Web Crypto; puedes inspeccionar el código fuente desde las herramientas de desarrollo de tu navegador.

De dónde vienen las semillas

Tres fuentes de entropía alimentan el algoritmo. Cada una con propiedades concretas:

Semilla del servidor. La genera el servidor del casino antes de que arranque la ronda. El método varía según el proveedor, pero suele tirar de entropía a nivel de SO (por ejemplo, /dev/urandom de Linux o equivalente) combinada con librerías criptográficas que aseguran que la salida sea impredecible para partes externas. La longitud es de 64 caracteres hex (256 bits) en esquemas SHA-256 o 128 caracteres hex (512 bits) en SHA-512. Antes de la ronda, solo el casino conoce el valor; el hash se publica, la semilla en sí permanece privada. Al terminar la ronda, la semilla se revela públicamente.

Semilla(s) del cliente. Las generan los jugadores y las aportan antes de la ronda. El mecanismo varía según el proveedor:

• Spribe (Aviator): tres semillas del cliente tomadas de los tres primeros jugadores que apuestan en cada ronda. Las semillas son cadenas hex aleatorias (típicamente de 32 caracteres cada una) generadas en el lado del cliente por el navegador del jugador en el momento de conectarse. Cada una es independiente de las otras.
• SmartSoft (JetX): una semilla del cliente aportada por el jugador que apuesta. Suele ser el ID de cuenta del jugador hasheado por una función del lado del casino, o una cadena aleatoria que el jugador puede cambiar.
• 1win Gaming (Lucky Jet): cuatro semillas del cliente (la propia más tres tomadas al azar de otros participantes en vivo). Criptográficamente similar al esquema de tres semillas de Spribe, pero con un dato independiente extra.
• BGaming (Aviamasters, Space XY): una semilla del cliente para la mayoría de títulos; títulos selectos incorporan el hash de bloque de Bitcoin como fuente adicional de entropía.

Las semillas del cliente son lo que protege contra la manipulación del lado del casino. Sin ellas, la semilla del servidor por sí sola determinaría el resultado; con ellas, el casino tiene que comprometerse con su semilla del servidor antes de saber con qué semilla del cliente se va a combinar. El hash resultante es la mezcla criptográfica de valores que ninguna parte controla por completo.

Nonce. Un contador simple de ronda que sube de uno en uno bajo la misma clave de semilla del servidor. El nonce asegura que cada ronda produzca un digest único aunque la semilla del servidor y las del cliente coincidieran. Combinada con las semillas, la tupla (servidor + cliente + nonce) es única por ronda por garantía.

Si quieres los detalles a nivel de bits sobre cómo se combinan las semillas dentro de la función hash, nuestro recorrido por la semilla del servidor y la del cliente cubre las primitivas criptográficas.

SHA-256 frente a SHA-512: qué significa la diferencia

Tanto SHA-256 como SHA-512 son miembros de la familia SHA-2, diseñada por criptógrafos de la NSA y estandarizada por NIST en 2002. Las dos se han estudiado a fondo; ninguna se ha roto en términos prácticos (a fecha de 2026 no existen ataques de pre-imagen ni ataques de colisión).

La diferencia numérica: SHA-256 produce 256 bits (64 caracteres hex); SHA-512 produce 512 bits (128 caracteres hex). El doble de longitud significa que el espacio de hash es exponencialmente mayor, lo que da más margen frente a futuras mejoras de criptoanálisis. Si los ordenadores cuánticos llegaran a acelerar ciertos ataques, SHA-256 podría empezar a mostrar grietas mientras SHA-512 conserva un margen sustancial. En 2026, las dos son igual de seguras para juegos crash; la elección de SHA-512 es estructuralmente más conservadora a largo plazo.

Por qué Spribe escogió SHA-512:

• Protección frente al futuro. Los juegos crash pueden funcionar durante décadas; SHA-512 tiene más margen frente a mejoras criptoanalíticas eventuales.
• Diferenciación comercial. SHA-512 + tres semillas del cliente es la capa estándar más estricta del crash regulado; el relato de "el doble de bits, tres semillas independientes" atrae a audiencias cripto.
• Compatibilidad operativa con esquema multi-semilla. El digest de 128 caracteres acomoda de forma natural la concatenación de tres semillas sin pérdida de información; SHA-256 funcionaría, pero con márgenes más ajustados.

Por qué SmartSoft y la mayoría escogieron SHA-256:

• Estándar industrial. Bustabit lanzó el crash original de 2014 sobre SHA-256; el protocolo se entiende bien y está auditado.
• Rendimiento. El cálculo SHA-256 es aproximadamente un 30% más rápido que SHA-512 en hardware estándar. Para operadores de alto tráfico (400.000 apuestas por minuto), el margen de rendimiento importa a nivel de coste de infraestructura.
• Compatibilidad con esquema de una sola semilla. El digest de 64 caracteres de SHA-256 es suficiente para esquemas de una sola semilla del cliente; los bits extra de SHA-512 serían excesivos.

En la práctica: los dos esquemas son matemáticamente defendibles en 2026. La elección de Spribe señala un conservadurismo criptográfico más estricto; la de SmartSoft señala fiabilidad estándar del sector. Ninguna está mal; reflejan filosofías de diseño distintas. Nuestra comparación entre Spribe y SmartSoft cubre la diferenciación más amplia entre proveedores.

Por qué los jugadores no pueden predecir multiplicadores

La resistencia a pre-imagen es la propiedad criptográfica que hace imposible la predicción. SHA-256 y SHA-512 están diseñadas para que conocer el digest no te permita calcular la entrada. Aunque tuvieras potencia de cálculo infinita, encontrar la semilla a partir del hash exigiría una búsqueda por fuerza bruta de un espacio astronómico (2^256 o 2^512 posibilidades, respectivamente).

Tres imposibilidades concretas:

1. Predecir la semilla del servidor a partir del hash publicado. El casino publica hash(server_seed) antes de la ronda. La resistencia a pre-imagen significa que no puedes calcular server_seed a partir de ese hash; tendrías que probar 2^256 o 2^512 candidatos por fuerza bruta, lo que es computacionalmente inviable a cualquier escala.
2. Predecir el crash de la ronda siguiente a partir de las anteriores. Cada ronda usa una combinación distinta de (semilla del servidor + semillas del cliente + nonce). Las semillas se generan de forma independiente; las salidas de la ronda N no revelan nada sobre las entradas de la ronda N+1. Detectar patrones entre rondas es matemáticamente irrelevante porque las rondas no tienen conexión causal.
3. Predecir el resultado antes de que existan todos los datos. En el esquema de Spribe, las tres semillas del cliente vienen de los tres primeros jugadores que apuestan en cada ronda; esos jugadores no existen cuando se vendió la app de predicción. La combinación completa de datos no está disponible hasta que la ronda ya ha arrancado; predecir antes de ese momento es imposible por definición.

Por eso las apps de predictor son estafas al 100%, como documenta nuestra pieza sobre si los juegos crash están amañados. Las matemáticas las prohíben; los vendedores ejecutan embudos de afiliación o distribuyen malware en lugar de predecir nada.

Qué algoritmos NO usan los juegos crash

Tan importante como entender lo que ES el algoritmo es entender lo que NO es. Tres mitos comunes:

• Aprendizaje automático / IA. Los juegos crash no ejecutan modelos ML sobre patrones de apuesta para determinar multiplicadores. La fórmula determinista basada en SHA no es un sistema que aprenda; no se adapta, no aprende ni se actualiza según los resultados. El modelo de ingresos del casino se basa en el margen publicado, codificado directamente en la constante house_edge de la fórmula.
• Cadenas de Markov / predicción por patrones. Los multiplicadores crash no se determinan por probabilidades de transición desde las N rondas anteriores. Cada ronda es independiente; los resultados anteriores no afectan a los datos de la siguiente. Los modelos de Markov implicarían conexiones causales entre rondas; el esquema criptográfico elimina expresamente esas conexiones.
• Ajuste consciente del conjunto de jugadores. El casino no modifica el algoritmo según la apuesta agregada ("hay muchos jugadores apostando alto, hagamos que esta ronda se estrelle pronto"). El compromiso criptográfico ocurre antes de que el casino vea las apuestas; modificar el algoritmo después invalidaría el hash publicado y sería detectable.

Lo que el algoritmo SÍ usa: hashing SHA-256 o SHA-512, aritmética entera sobre dígitos hex y una constante fija de margen de la casa. Eso es todo. La simplicidad real contrasta con la complejidad de los mitos a su alrededor. La simplicidad es una característica: hace viable la verificación para cualquier jugador con un navegador.

Verifica cualquier ronda por ti mismo

El procedimiento completo de verificación sobre una ronda real de Aviator:

1. Abre Aviator en tu operador. Juega una ronda (o abre una anterior del historial).
2. Navega al panel provably fair: típicamente Settings → Provably Fair Settings → My Bets → seleccionar ronda → Show me the math.
3. Copia los cuatro valores del panel: semilla del servidor revelada, semillas del cliente 1-3, nonce, multiplicador mostrado.
4. Abre nuestro verificador en una pestaña nueva.
5. Elige esquema: SHA-512 + 3 semillas (Spribe / Aviator).
6. Pega cada valor en el campo correspondiente.
7. Pulsa Compute. El verificador hashea los datos vía SHA-512, extrae los primeros 13 caracteres hex, calcula h, aplica la fórmula (100 - 3) / (100 (1 - h)), redondea a 2 decimales y muestra el resultado.
8. Compara la salida del verificador con el multiplicador mostrado. Coincidencia significa ronda honesta; discrepancia significa que toca escalar.

Tiempo total: aproximadamente 60 segundos por ronda. Las matemáticas son idénticas a las que ejecuta el servidor de Spribe; lo único distinto es que el verificador ejecuta el cálculo en tu navegador en lugar del servidor del casino. Los mismos datos producen las mismas salidas; ésa es la propiedad del determinismo aplicada a la verificación en juegos crash.

Veredicto editorial: algoritmo simple, marco de confianza sólido

El algoritmo del juego crash es una de las primitivas más simples del juego de casino y, a la vez, una de las más malinterpretadas. No es IA; no son cadenas de Markov; no se adapta al comportamiento del jugador. Es una fórmula determinista basada en SHA que toma tres datos (semillas + nonce), produce una salida (el multiplicador) y se ejecuta igual en cualquier ordenador capaz de calcular hashes. La simplicidad es el punto: cualquier jugador con un navegador puede recalcular y verificar.

El marco de confianza construido alrededor del algoritmo es la protección real. Provably fair compromete al casino con semillas concretas antes de la ronda; las auditorías de laboratorios independientes como eCOGRA y Gaming Labs International verifican que el RTP publicado coincide con lo que produce el algoritmo; los reguladores fuerzan el comportamiento del operador a nivel de envoltura. Cada capa cubre lo que las otras no. El algoritmo en sí es el núcleo interno; el marco de confianza externo es lo que lo hace operativamente útil para jugadores no desarrolladores.

Para el recorrido operativo de verificación, nuestra pieza sobre cómo verificar una ronda de juego crash cubre el pasó a paso. Para las primitivas criptográficas en detalle, nuestra guía de provably fair entra más a fondo en SHA-256 frente a SHA-512. Para la mecánica a nivel de bits de las semillas, la pieza sobre semilla del servidor y del cliente es el tratamiento dedicado. Juntos, esos cuatro artículos forman el marco de confianza completo; éste de algoritmo es la base técnica.