Server seed y client seed: cómo funciona de verdad la aleatoriedad en los juegos crash

Las dos semillas que deciden cada ronda

¿Te preguntas qué hacen exactamente la server seed y la client seed? Son las dos entradas que determinan el resultado de cada ronda de crash. La server seed la genera el estudio. La client seed la genera el jugador (o varios jugadores en Aviator). Las dos juntas pasan por un hash y de ahí sale el punto de crash.

El truco que hace que esto sea provably fair: la server seed se compromete (se publica su hash) antes de que arranque la ronda, pero solo se revela después. La client seed es tuya y la puedes cambiar cuando quieras. Ningún lado puede manipular el resultado por su cuenta.

Por qué la server seed tiene que comprometerse primero

¿Te preguntas por qué importa tanto el orden? Si el operador conociera tu client seed antes de comprometer su server seed, podría elegir una server seed que produzca un crash bajo. Mal asunto para ti.

Al comprometerse primero (publicando el hash SHA de la server seed), el operador deja su entrada bloqueada. Ya no puede cambiar la server seed después de ver tu client seed, porque el hash no cuadraría con el compromiso y le pillarías.

Qué controla realmente la client seed

La client seed es aleatoriedad que tú metes en la ronda. La mayoría de jugadores se queda con la que el juego genera por defecto. Algunos rotan la client seed manualmente cada ronda para meter entropía propia.

Importante: la client seed no afecta a tus probabilidades de ganar. Matemáticamente es una entrada de aleatorización, no de estrategia. Da igual si pones 12345 o abc123: las distribuciones de probabilidad son idénticas.

El motivo por el que existe la client seed: impide que el operador pueda predecir el resultado. Si solo usaran la server seed, podrían calcular cada ronda con antelación. Al meter tu client seed les cierras esa puerta.

Esquemas de tres y cuatro semillas

Aviator usa tres client seeds tomadas de tres jugadores aleatorios en cada ronda. Lucky Jet usa cuatro. La idea matemática: a más fuentes de semillas, menos posibilidad de que un solo jugador (o el operador coludiendo con uno) pueda manipular la ronda.

Efecto práctico: no puedes influir en las rondas en las que participas más allá de aportar tu propia client seed. Las otras semillas vienen de jugadores aleatorios que no conoces.

Cómo rotar la client seed en la práctica

La mayoría de juegos crash te deja meter una client seed personalizada en los ajustes. Pon lo que te dé la gana: tu número favorito, la hora a la que entraste, una cadena al azar. Cámbiala cuando te apetezca.

Lo cambies o no lo cambies, el juego sigue funcionando igual de bien. Rotar es para jugadores paranoicos que quieren máxima entropía personal. Para la mayoría, el valor por defecto vale.

Qué pasa después de la ronda

El operador revela la server seed. Tú puedes verificar que el hash SHA cuadra con el compromiso de antes de la ronda. Luego calculas el punto de crash por tu cuenta usando todas las semillas. Si tu cálculo cuadra con la salida del juego, la ronda fue honesta.

Ese es el mecanismo entero. Dos semillas, dos reglas de timing, un pasó de verificación. Nada de magia.

Más material: guía de provably fair, verifica cualquier ronda, cómo funciona el algoritmo.

Para nuestro método de pruebas, mira la política editorial.

Server seed: qué es y cómo se genera

La server seed es una cadena hexadecimal aleatoria larga que genera el servidor del casino justo antes de cada ronda. La longitud depende de la función hash que se use:

• Para esquemas SHA-256 (SmartSoft, BGaming, Turbo Games, Upgaming, InOut Games, 1win Gaming, Pragmatic Play, Evolution y la mayoría de proveedores): 64 caracteres hex, equivalentes a 256 bits.
• Para esquemas SHA-512 (Spribe / Aviator, Aviatrix, Pilot): 128 caracteres hex, equivalentes a 512 bits.

El método de generación cambia según el proveedor, pero sigue prácticas criptográficas estándar:

1. El servidor del casino tira de una fuente de entropía a nivel de SO (Linux /dev/urandom, Windows BCryptGenRandom o equivalente) para recoger aleatoriedad.
2. Esa entropía alimenta un generador de números aleatorios criptográfico (CSPRNG) que produce bits indistinguibles de la aleatoriedad real.
3. La salida del CSPRNG se formatea como cadena hexadecimal con la longitud que toque.
4. El resultado se guarda en privado en el servidor del casino, indexado por número de ronda.

Hay tres propiedades que importan para la confianza:

• Impredecibilidad. Ninguna parte externa puede predecir la semilla. La salida del CSPRNG es computacionalmente indistinguible de la aleatoriedad real; aunque conocieras todas las semillas anteriores, no puedes predecir la siguiente.
• Privacidad hasta la revelación. La semilla vive en el servidor hasta que termina la ronda. Los jugadores no la ven antes del cierre, solo se publica el hash SHA pre-ronda.
• Compromiso vía hash. Publicar el hash SHA antes de la ronda ata al casino: cualquier semilla que se revele luego tiene que hashear a ese mismo valor, y si no cuadra, la discrepancia es evidencia pública de fraude.

¿Por qué genera la semilla el casino y no un tercero? Por motivos prácticos (generarla en servidor es rápido y operativamente sencillo) más la protección criptográfica del esquema compromiso-revelación. La generación del casino no necesita ser "sin confianza" porque el mecanismo de compromiso más revelación la hace verificable post-ronda, sin importar quién la generara.

Client seed: cómo aportan los jugadores la entropía

La client seed es la mitad de la entropía que ponen los jugadores. El mecanismo de quién aporta y cómo cambia según el proveedor; el propósito estructural es siempre el mismo: impedir que el casino elija una server seed que produzca un resultado a su gusto, mezclando entrada que el casino no controla.

Spribe (Aviator y demás títulos de Spribe): tres client seeds. Cuando arranca una ronda, el servidor del casino coge client seeds de los tres primeros jugadores que apuestan en esa ronda concreta. Cada semilla es una cadena hex (típicamente de 32 caracteres) que se genera en el lado del cliente, en el navegador del jugador, en el momento de conectarse a la ronda, tirando de fuentes de entropía del navegador (window.crypto.getRandomValues en navegadores modernos). Las tres semillas las generan de forma independiente tres jugadores distintos que no se conocen y no pueden ponerse de acuerdo (se eligen al azar entre quienes apuestan primero en la ronda).

SmartSoft (JetX y demás títulos crash de SmartSoft): una client seed. El jugador que apuesta aporta una client seed. Suele derivarse del ID de cuenta del jugador hasheado mediante una función del lado del casino, o ser una cadena aleatoria que tú mismo puedes cambiar en los ajustes de cuenta. El esquema de una sola semilla coincide con la especificación de Bustabit de 2014 y es la base del sector.

1win Gaming (Lucky Jet, Rocket X, Rocket Queen): cuatro client seeds. La tuya más tres tomadas al azar de otros participantes en vivo de la ronda. Criptográficamente parecido al esquema de tres semillas de Spribe, pero con una entrada independiente extra. Estructuralmente todavía más estricto contra la manipulación: un ataque con éxito tendría que comprometer cuatro client seeds independientes de jugadores aleatorios a la vez.

BGaming (Aviamasters, Space XY, etc.): una client seed más hash de bloque de Bitcoin opcional. SHA-256 estándar con una client seed para la mayoría de títulos de BGaming; algunos títulos seleccionados meten el último hash de bloque de Bitcoin como fuente extra de entropía. El hash de bloque de Bitcoin es públicamente verificable, lleva marca temporal en el momento de inicio de la ronda y nadie puede manipularlo sin tirarse abajo toda la red Bitcoin. Mejora matemática marginal sobre el esquema estándar; señal de confianza importante para audiencias cripto.

Por qué Spribe usa tres client seeds

La innovación de las tres client seeds es lo que hace que el esquema provably fair de Aviator sea estructuralmente más estricto que la base del género. La idea:

Con una sola client seed (SmartSoft, BGaming, la mayoría de proveedores), el jugador que la aporta tiene una influencia teórica (acotada criptográficamente) sobre el resultado. El casino tiene que comprometerse con su server seed antes de conocer la del cliente, pero un jugador que pueda predecir su propia semilla con antelación y conozca el momento del compromiso podría, en teoría, sesgar la combinación de datos. Esa cota es matemáticamente pequeñita con SHA-256 y un CSPRNG bien hecho, pero la superficie de ataque estructural existe.

Con tres client seeds independientes (Spribe), el ataque obliga a comprometer tres semillas independientes de jugadores aleatorios a la vez. Los tres primeros jugadores de cada ronda no son predecibles con antelación (son quien apueste primero); ni siquiera el casino sabe qué tres jugadores van a aportar hasta que la ronda arranca. Comprometer a tres jugadores independientes aleatorios es, en la práctica, inviable a cualquier escala.

El esquema de cuatro client seeds (1win Gaming) lleva la misma lógica un paso más allá con una semilla independiente adicional. Mejora marginal sobre tres semillas; la ventaja estructural es similar.

En la práctica: SHA-256 con una client seed se sostiene matemáticamente en 2026 (no se conocen ataques que tengan éxito en tiempo práctico); SHA-512 con tres semillas es estructuralmente más estricto en varios órdenes de magnitud. La elección entre ambos es "conservador frente a estándar" en lugar de "seguro frente a inseguro". Spribe se fue a la capa conservadora, la mayoría se quedó en la estándar. Las dos son honestas; el relato de confianza pesa más que la diferencia matemática para la percepción del jugador.

Cómo se combinan las semillas: concatenación más hash

Las semillas y el nonce se concatenan en una sola cadena, esa cadena se hashea y el digest decide el multiplicador. Mecánicamente:

Combinación de datos en Spribe (Aviator):

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

El carácter delimitador exacto cambia según la implementación (algunos usan ":" o "," o ningún delimitador); el principio es el mismo. La concatenación produce una cadena única por ronda; el hash SHA-512 saca un digest hex de 128 caracteres único para esa combinación.

Combinación de datos en SmartSoft (JetX):

hash_input = server_seed + "|" + client_seed + "|" + nonce
digest = SHA-256(hash_input)

Los esquemas de una sola semilla usan la misma estructura con una client seed menos y SHA-256 en vez de SHA-512. La salida es un digest hex de 64 caracteres.

A partir del digest, los proveedores extraen una fracción h entre 0 y 1:

• Spribe: primeros 13 caracteres hex del digest SHA-512. Convertir hex a entero, dividir por 16^13 (el valor máximo posible de 13 caracteres hex), y el resultado es h.
• SmartSoft: primeros 8 caracteres hex del digest SHA-256. Convertir hex a entero, dividir por 16^8, y el resultado es h.
• Otros proveedores: distintas longitudes de segmento hex pero el mismo principio de conversión.

La fracción h alimenta la fórmula del multiplicador: crash_point = (100 - margen_casa) / (100 × (1 - h)). Redondea a 2 decimales. El resultado es el multiplicador en el que va a terminar la ronda. Determinístico, los mismos datos producen siempre la misma salida. Para una cobertura más profunda del algoritmo, nuestra pieza sobre el algoritmo del juego crash recorre la fórmula con ejemplos de código.

El nonce: para qué sirve

El nonce es un contador simple de ronda que sube de uno en uno bajo la misma clave de server seed. Su propósito: asegurarse de que cada ronda saque un digest único aunque la server seed y las client seeds coincidieran entre rondas.

Mecánicamente: al inicio de una clave de server seed (que suele rotarse cada pocas horas o cada varios miles de rondas), el nonce arranca en 0 (o en 1, según la implementación). Cada ronda sube en 1. Cuando la clave se rota (el casino genera una nueva), el nonce se reinicia a 0 bajo la nueva clave.

¿Por qué hace falta el nonce? Sin él, dos rondas con la misma server seed más las mismas client seeds sacarían digests idénticos. En la práctica, las semillas no van a coincidir (se generan al azar), pero el nonce elimina esa posibilidad del todo. El nonce también permite a los verificadores comprobar la secuencia: la ronda 5 bajo la clave de server seed X tiene que tener nonce 5; si la UI del operador muestra la ronda 5 con nonce 7, esa discrepancia es evidencia de salto de rondas o de fraude.

El protocolo de revelación: cuándo se publican las semillas

El mecanismo de confianza depende por completo de que la revelación pase de forma fiable. El protocolo:

1. Pre-ronda (~5-10 segundos antes del cierre): el servidor genera la server seed, calcula su hash SHA y publica el hash en la UI del operador. Los jugadores ven el hash, pero no la semilla.
2. Cierre, ronda en curso: las client seeds se cogen de los primeros N jugadores (según el esquema); la concatenación más hash más extracción del digest más cálculo del multiplicador pasan en el servidor; el multiplicador sube y se estrella según lo que diga la fórmula.
3. Fin de ronda: el casino publica la server seed revelada en texto plaño en la UI del operador. La semilla ya es pública.
4. Verificación (post-revelación): cualquier jugador puede hashear la semilla revelada con SHA-256 o SHA-512 (según el esquema) y confirmar que el digest cuadra con el hash publicado en el paso 1. También puede volver a ejecutar el algoritmo entero con la semilla revelada más las client seeds más el nonce y confirmar que el multiplicador cuadra con el que se mostró.

La revelación tiene que pasar para que el compromiso criptográfico tenga sentido. Sin ella, solo te queda la palabra del casino sobre qué semilla se comprometió; el compromiso es inverificable. Los operadores con licencia Tier 1 (UKGC, MGA, DGOJ España, AGCO Ontario) revelan siempre porque los reguladores auditan el protocolo. Los operadores offshore de Curazao a veces esconden la revelación detrás de tickets de soporte o directamente no la hacen, y eso anula el protocolo entero.

Qué hacer si las semillas no se revelan

Si juegas una ronda y el operador no publica la server seed revelada después, el juego no es provably fair, prometa lo que prometa el marketing. Tres respuestas en escalada:

1. Primera observación: abre el panel de ajustes de provably fair del operador, revisa el historial de rondas, busca la semilla revelada. Algunos operadores la entierran a 3 o 4 clics de profundidad. Si de verdad no la encuentras en la UI, escribe a soporte.
2. Petición a soporte: pídele a soporte que te dé la server seed revelada de la ronda concreta. Dales 7 días para responder. Los operadores serios la van a soltar; los poco fiables darán largas o se negarán.
3. No juegues más ahí: si el operador no revela las semillas con fiabilidad, te falta la protección criptográfica. El juego, técnicamente, ejecuta provably fair desde el lado del proveedor, pero la envoltura del operador no respeta el protocolo. Cambia de operador y métete en casinos con licencia Tier 1 con procedimientos de revelación auditados.

Esconder la revelación es una de las señales más potentes de operador poco fiable. El casino no gana nada ocultando las semillas si su matemática es honesta; solo gana algo si su matemática es deshonesta. Trata la fricción en la revelación como una alerta contra el operador. Para el marco más amplio de confianza en el operador, nuestra pieza ¿están amañados los juegos crash? cubre la protección por capas (esquema provably fair más licencia regulatoria más hábito de verificar).

Recorrido práctico: verifica tu ronda con las semillas

Vamos al lío con un recorrido concreto para ejecutar una verificación con datos de server seed y client seed:

1. Abre Aviator en tu operador. Juega una ronda (o ábrela desde el historial).
2. Navega al panel de provably fair: típicamente Settings → Provably Fair Settings → My Bets → pulsar la ronda → Show me the math.
3. Copia los cuatro valores del panel: server seed revelada, client seed 1, client seed 2, client seed 3, nonce.
4. Abre nuestro verificador de navegador en una pestaña nueva.
5. Elige esquema: SHA-512 + 3 semillas (Spribe / Aviator).
6. Pega los cuatro valores en los campos correspondientes.
7. Pulsa Compute. El verificador hashea los datos vía SHA-512, extrae los primeros 13 caracteres hex, calcula h, aplica la fórmula del crash y muestra el multiplicador calculado.
8. Compara la salida del verificador con el multiplicador mostrado. Si cuadra, ronda honesta; si no cuadra, escalado a soporte del operador y, si no se resuelve, al regulador.

Tiempo total: 60 segundos por ronda. La matemática es idéntica a la que ejecuta el servidor de Spribe; lo único que cambia es el sitio donde se ejecuta (tu navegador en vez del servidor del casino). Mismos datos, mismas salidas; esa es la propiedad del determinismo aplicada a la verificación basada en semillas.

Preguntas que se hacen los lectores

¿Esta estrategia es realmente rentable? No hay estrategia de crash que se cargue el margen de la casa. El 3% de margen en la mayoría de crashes de aviación y el 1% en Cash or Crash Live se aplican da igual el cashout que escojas. Lo que hacen las estrategias es darle forma a la varianza: si vas a sufrir un goteo constante o algún subidón puntual de camino al mismo resultado esperado.

¿Te puedes fiar de las matemáticas? Si el juego es provably fair, sí. Puedes verificar cualquier ronda por tu cuenta con las semillas que el operador revela. Cubrimos el proceso de verificación en nuestra guía de verificación. Si el juego usa RNG certificado (formatos en vivo), te fías de la auditoría de GLI o iTech Labs en vez de hacerla tú.

¿Cómo sabes si el operador es honesto? Mira la licencia. Los operadores con UKGC, MGA y NJDGE tienen consecuencias regulatorias si hacen trampa. Los que solo tienen Curazao tienen un cumplimiento más flojo, pero publican informes de auditoría si son serios. Recomendamos siempre verificar el estado de la licencia en los registros públicos antes de meter pasta en una cuenta de operador.

¿Cuál es la diferencia entre RTP y margen de la casa? Son las dos caras de la misma moneda. Resta el RTP a 100% y te sale el margen. 97% de RTP equivale a 3% de margen. Cuanto más bajo el margen, mejor para el jugador en sesiones largas.

¿Importa la volatilidad? Para la forma de la varianza, sí; para el valor esperado, no. Volatilidad alta significa premios gordos puntuales entre muchas pérdidas pequeñas. Volatilidad baja significa premios pequeños frecuentes. Mismo RTP en los dos casos, sensación psicológica distinta.

¿Es mejor apostar más fuerte? No. Apuestas más grandes solo amplifican la varianza. Pon el tamaño de apuesta en el 1-2% del bankroll de sesión para sobrevivir a rachas malas realistas. Lo cubrimos en nuestra guía de gestión de bankroll.

Ejemplo trabajado para aterrizar la teoría

Coge una sesión típica: 200 € de bankroll, cashout objetivo de 2x, 2 € por ronda (1% del bankroll), 100 rondas.

Victorias esperadas: 49 rondas a 4 € cada una = 196 € recogidos.

Pérdidas esperadas: 51 rondas a 2 € cada una = 102 € perdidos.

Resultado neto esperado: 196 € - 200 € apostados = -4 €. Ese es el 2% de margen sobre 100 rondas con esta configuración.

Varianza real de sesión: la mayoría de sesiones acaba entre -30 € y +30 € alrededor del -4 € esperado. Algunas las cierras muy arriba; otras muy abajo. El -2% solo aparece como media a largo plazo agregando muchas sesiones.

Lo que te llevas: la varianza a corto plazo grita mucho más fuerte que el valor esperado a largo. La disciplina te deja seguir en el juego el tiempo suficiente para que las matemáticas converjan.

Cómo encaja esto en la estrategia general de crash

Este artículo es una pieza de un cuadro más grande. El marco de estrategia completa pasa por:

1. Elegir un cashout objetivo que puedas defender matemáticamente. Lo cubrimos en nuestra guía de estrategia 2026.

2. Dimensionar las apuestas contra la profundidad esperada de las rachas. La matemática está en nuestra guía de bankroll.

3. Elegir juegos con el RTP más alto que tengas disponible. El ranking está en nuestros rankings de RTP.

4. Verificar provably fair en cada ronda que te importe. El proceso está en nuestra guía de verificación.

Cada pieza apoya a las otras. Ninguna por sí sola le gana al margen de la casa; lo que hacen juntas es ayudarte a sobrevivir a las matemáticas el tiempo suficiente para disfrutar jugando.

Veredicto editorial: las semillas son la base criptográfica de la confianza en el crash

La server seed y la client seed son los primitivos elementales que hacen realmente justos a los juegos crash provably fair. Entenderlos a nivel de mecánica te deja evaluar el marco de confianza en lugar de tirar de fe. La innovación de Spribe de tres client seeds es genuinamente significativa a nivel estructural; la base de SmartSoft de una client seed es matemáticamente defendible pero menos estricta estructuralmente; el esquema de cuatro semillas de 1win es todavía más estricto que el de Spribe. Los cuatro esquemas (una semilla, tres semillas, cuatro semillas, con o sin entropía de Bitcoin) son creíbles; ninguno está roto; el factor diferencial de confianza es la envoltura del operador alrededor de la mecánica de semillas más que la primitiva criptográfica en sí.

La revelación es lo que le da sentido a las matemáticas. Los operadores que publican revelaciones con fiabilidad (casinos Tier 1 con licencia UKGC + MGA + DGOJ + AGCO Ontario) hacen posible la verificación; los que esconden revelaciones (algunas plataformas offshore de Curazao) anulan el protocolo, da igual la calidad matemática que haya por debajo. Trata la fricción en la revelación como la señal más fuerte de confianza en el operador sobre la que puedes actuar. Combina la comprensión criptográfica con licencia regulatoria y hábito de verificar (saca una ronda por sesión); el marco por capas produce confianza duradera que ninguna capa por sí sola puede aportar.

Para el recorrido más amplio de provably fair, nuestra guía de provably fair cubre el protocolo a nivel de protocolo. Para el algoritmo a nivel de código, algoritmo del juego crash entra en la fórmula. Para el recorrido operativo de verificación, verificar juego crash cubre el procedimiento pasó a paso. Este artículo sobre semillas es la base a nivel de bits; los otros se construyen encima.