Server Seed e Client Seed: Como Funciona a Aleatoriedade dos Crash Games

Server seed e client seed são as primitivas criptográficas que tornam crash games provably fair. A maioria dos artigos descreve em nível de marketing ("o cassino escolhe uma seed, você escolhe uma seed, elas combinam para produzir o resultado") e para por aí. O nível marketing está correto, mas é operacionalmente inútil; entender a mecânica em nível de bits é o que torna a verificação possível e justifica a confiança no esquema. Este texto percorre as seeds em detalhe: como são geradas, de onde vêm, como combinam, quando são reveladas e o que fazer quando o reveal não acontece.

Por que esse nível de detalhe importa: a garantia criptográfica depende de propriedades específicas das seeds (independência, imprevisibilidade, momento do compromisso). Conhecer a mecânica é o que separa confiança de fé. Fé diz "o cassino roda matemática honesta"; confiança diz "verifico a matemática porque entendo como as entradas combinam". A segunda é durável; a primeira pede esperança.

Server seed: o que é e como é gerada

A server seed é uma string hexadecimal aleatória longa, gerada pelo servidor do cassino imediatamente antes de cada rodada. O tamanho depende da função hash:

• Para esquemas SHA-256 (SmartSoft, BGaming, Turbo Games, Upgaming, InOut Games, 1win Gaming, Pragmatic Play, Evolution, maioria dos provedores): 64 caracteres hex = 256 bits.
• Para esquemas SHA-512 (Spribe / Aviator, Aviatrix, Pilot): 128 caracteres hex = 512 bits.

A geração varia por provedor, mas segue prática criptográfica padrão:

1. O servidor do cassino usa fonte de entropia em nível de SO (Linux /dev/urandom, Windows BCryptGenRandom ou equivalente) para reunir aleatoriedade.
2. A entropia alimenta um gerador criptográfico de números pseudoaleatórios (CSPRNG) que produz bits indistinguíveis de aleatoriedade real.
3. A saída do CSPRNG é formatada como string hexadecimal do tamanho exigido.
4. O resultado fica armazenado privado no servidor do cassino, indexado pelo número da rodada.

Três propriedades importam para a confiança:

• Imprevisibilidade. A seed não pode ser prevista por nenhuma parte externa. A saída do CSPRNG é computacionalmente indistinguível de aleatoriedade real; mesmo conhecendo seeds anteriores, você não prevê a próxima.
• Privacidade até o reveal. A seed fica no servidor até a rodada terminar. Os jogadores não veem a seed antes do fechamento; só o hash SHA é publicado antes da rodada.
• Compromisso via hash. A publicação pré-rodada do hash SHA prende o cassino: qualquer seed revelada depois precisa dar o mesmo hash, ou a divergência vira evidência pública de trapaça.

Por que o cassino gera a server seed em vez de um terceiro? Por motivos práticos (geração no servidor é rápida e operacionalmente simples) somados à proteção criptográfica do esquema commit-reveal. A geração do cassino não precisa ser "trustless" porque o mecanismo commit + reveal torna a seed verificável depois da rodada, independentemente de quem gerou.

Client seed: como os jogadores contribuem entropia

A client seed é a metade contribuída pelo jogador. O mecanismo de quem contribui e como varia por provedor; o propósito estrutural é o mesmo: impedir que o cassino escolha uma server seed que produza um resultado desejado, misturando uma entrada que ele não controla.

Spribe (Aviator e títulos Spribe): três client seeds. Quando uma rodada começa, o servidor do cassino puxa client seeds dos três primeiros jogadores que apostam naquela rodada específica. Cada seed é uma string hex (em geral 32 caracteres) gerada do lado cliente pelo navegador do jogador quando ele se conecta à rodada, usando fontes de entropia do navegador (window.crypto.getRandomValues em navegadores modernos). As três seeds são geradas independentemente por três jogadores que não se conhecem e não podem conluiar (são selecionados aleatoriamente entre quem apostar primeiro na rodada).

SmartSoft (JetX e títulos crash da SmartSoft): uma client seed. O jogador que aposta contribui com uma client seed. A seed normalmente vem de um ID da conta com hash, ou de uma string aleatória que o jogador troca nas configurações. O esquema de seed única casa com a especificação Bustabit de 2014 e é o padrão da indústria.

1win Gaming (Lucky Jet, Rocket X, Rocket Queen): quatro client seeds. A seed do próprio jogador mais três tiradas de outros jogadores aleatórios ao vivo na rodada. Criptograficamente similar ao esquema de três seeds da Spribe, com uma entrada independente extra. Estruturalmente ainda mais rígido contra manipulação; um ataque bem-sucedido exigiria comprometer simultaneamente as seeds de quatro jogadores aleatórios independentes.

BGaming (Aviamasters, Space XY etc.): uma client seed mais hash de bloco do Bitcoin opcional. SHA-256 padrão com uma client seed para a maior parte dos títulos BGaming; títulos selecionados incorporam o hash do último bloco do Bitcoin como fonte adicional de entropia. O hash do bloco do Bitcoin é publicamente verificável, com timestamp do horário de início da rodada, e não pode ser manipulado por nenhuma parte sem comprometer toda a rede Bitcoin. Melhoria matemática marginal em relação ao esquema padrão de seed única; sinalização de confiança relevante para audiências cripto.

Por que a Spribe usa três client seeds

A inovação das três client seeds é o que torna o esquema provably fair do Aviator estruturalmente mais rígido que o padrão do gênero. O argumento:

Com uma client seed (SmartSoft, BGaming, maioria), o jogador que contribui tem influência teórica (criptograficamente limitada) sobre o resultado. O cassino precisa se comprometer com a server seed antes de saber qual client seed entra na combinação, mas um jogador que prevê sua própria seed em avanço somado ao timing do compromisso poderia, em tese, enviesar a combinação. O limite desse ataque é matematicamente pequeno para SHA-256 com CSPRNG decente, mas a superfície estrutural existe.

Com três client seeds independentes (Spribe), o ataque exigiria comprometer simultaneamente as seeds de três jogadores aleatórios independentes. Os três primeiros da rodada não são previsíveis em avanço (são quem aposta primeiro); nem o cassino sabe quais três contribuirão até a rodada começar. Comprometer três jogadores aleatórios independentes é praticamente inviável em qualquer escala.

O esquema de quatro client seeds (1win Gaming) estende a mesma lógica com mais uma seed independente. Melhoria marginal em relação a três seeds; a vantagem estrutural é parecida.

Na prática: SHA-256 com uma client seed é matematicamente defensável em 2026 (sem ataques conhecidos em tempo prático); SHA-512 com três seeds é estruturalmente mais rígido em ordens de grandeza. A escolha entre os dois é conservadora-vs-padrão, não segura-vs-insegura. A Spribe escolheu o patamar conservador; a maioria escolheu o padrão da indústria. Os dois são honestos; a narrativa de confiança pesa mais que a diferença matemática para a percepção do jogador.

Como as seeds combinam: concatenação mais hash

As seeds e o nonce concatenam em uma única string; a string passa pelo hash; o digest determina o multiplicador. Mecanicamente:

Combinação de entrada da Spribe (Aviator):

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

O delimitador exato varia por implementação (alguns usam ":", "," ou nenhum); o princípio é o mesmo. A concatenação produz uma string única por rodada; o hash SHA-512 produz um digest hex de 128 caracteres único para aquela combinação.

Combinação de entrada da SmartSoft (JetX):

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

Esquemas de seed única usam a mesma estrutura com uma client seed a menos e SHA-256 em vez de SHA-512. A saída é um digest hex de 64 caracteres.

Do digest, os provedores extraem uma fração h entre 0 e 1:

• Spribe: 13 primeiros caracteres hex do digest SHA-512. Converte hex para inteiro; divide por 16^13 (valor máximo possível de 13 caracteres hex); resultado é h.
• SmartSoft: 8 primeiros caracteres hex do digest SHA-256. Converte hex para inteiro; divide por 16^8; resultado é h.
• Outros provedores: tamanhos diferentes de fatia hex, mesmo princípio de conversão.

A fração h alimenta a fórmula do multiplicador: crash_point = (100 - margem_da_casa) / (100 × (1 - h)). Arredondar em duas casas decimais. O resultado é o multiplicador em que a rodada termina. Determinístico; entradas idênticas sempre produzem saídas idênticas. Para cobertura mais profunda do algoritmo, nosso artigo do algoritmo do crash game percorre a fórmula com exemplos de código.

O nonce: para que serve

O nonce é um contador de rodadas simples que avança em um a cada rodada sob a mesma chave de server seed. O propósito: garantir que cada rodada produza um digest único mesmo se a server seed e as client seeds coincidirem entre rodadas.

Mecanicamente: no início de uma chave de server seed (em geral rotacionada a cada poucas horas ou alguns milhares de rodadas), o nonce começa em 0 (ou 1, dependendo da implementação). Cada rodada incrementa em 1. Quando a chave é rotacionada (o cassino gera nova chave), o nonce zera sob a nova chave.

Por que precisa do nonce? Sem ele, duas rodadas com server seed e client seeds idênticas dariam digests idênticos. Na prática é improvável as seeds coincidirem (são geradas aleatoriamente), mas o nonce remove a possibilidade de vez. O nonce também permite que verificadores cruzem o sequenciamento das rodadas: rodada 5 sob a chave X precisa ter nonce 5; se a UI do operador mostra rodada 5 com nonce 7, a divergência sinaliza pulo de rodada ou trapaça.

O protocolo de reveal: quando as seeds são publicadas

O mecanismo de confiança depende inteiramente de o reveal acontecer com previsibilidade. O protocolo:

1. Pré-rodada (~5-10 segundos antes do fechamento): servidor gera a server seed; calcula o hash SHA; publica o hash na UI do operador. Os jogadores veem o hash, não a seed.
2. Apostas fecham, rodada roda: client seeds são puxadas dos N primeiros jogadores (conforme o esquema); concatenação + hash + extração de digest + cálculo do ponto de crash acontecem no servidor; o multiplicador sobe e "crasha" segundo a saída da fórmula.
3. Rodada termina: o cassino publica a server seed revelada em texto claro na UI do operador. A seed agora é pública.
4. Verificação (pós-reveal): qualquer jogador faz hash da seed revelada via SHA-256 ou SHA-512 (conforme o esquema) e confirma que o digest bate com o hash pré-publicado do passo 1. Também rerroda o algoritmo todo com a seed revelada + client seeds + nonce e confirma que o multiplicador bate com o exibido.

O reveal precisa acontecer para o compromisso criptográfico ter sentido. Sem ele, você só tem a palavra do cassino sobre qual seed foi comprometida; o compromisso fica não verificável. Operadores licenciados Tier 1 (UKGC, MGA, ANJL Brasil, AGCO Ontario) sempre revelam porque os reguladores auditam o protocolo. Operadores offshore Curaçao às vezes escondem o reveal atrás de pedidos ao suporte ou nem revelam; isso destrói o protocolo por completo.

O que fazer se as seeds não forem reveladas

Se você joga uma rodada e o operador não publica a server seed revelada depois, o jogo não é provably fair, ignorando o marketing. Três respostas escalonadas:

1. Primeira observação: abra o painel de configurações provably fair do operador; cheque o histórico de rodadas; procure pela seed revelada. Alguns operadores enterram em 3-4 cliques de menu. Se realmente não achar na UI, contate o suporte.
2. Solicitação ao suporte: peça a server seed revelada da rodada específica. Dê 7 dias para resposta. Operadores sérios entregam; operadores duvidosos enrolam ou recusam.
3. Recuse jogar: se o operador não revela as seeds com previsibilidade, a proteção criptográfica está faltando. Tecnicamente o jogo do provedor pode ser provably fair, mas a casca do operador não cumpre o protocolo. Troque de operador; escolha cassinos Tier 1 com procedimentos auditados de reveal.

Esconder o reveal é um dos sinais mais fortes de operador não confiável. O cassino não tem nada a ganhar escondendo seeds se a matemática é honesta; tem algo a ganhar se for desonesta. Trate atrito de reveal como bandeira contra o operador. Para o framework mais amplo de confiança no operador, nosso artigo sobre crash games manipulados cobre a proteção em camadas (esquema provably fair + licença do regulador + hábito de verificar).

Tutorial: verifique sua rodada usando as seeds

Caminho concreto rodando uma verificação com server seed e client seed:

1. Abra o Aviator no seu operador. Jogue uma rodada (ou abra uma do histórico).
2. Vá no painel provably fair: em geral Configurações -> Provably Fair Settings -> Minhas Apostas -> clique na rodada -> Mostrar a matemática.
3. Copie os quatro valores do painel: server seed revelada, client seed 1, client seed 2, client seed 3, nonce.
4. Abra nosso verificador no navegador em uma nova aba.
5. Escolha o esquema: SHA-512 + 3 seeds (Spribe / Aviator).
6. Cole os quatro valores nos campos correspondentes.
7. Clique em Calcular. O verificador faz hash das entradas via SHA-512, extrai os 13 primeiros caracteres hex, calcula h, aplica a fórmula do crash e mostra o ponto calculado.
8. Compare com o multiplicador exibido. Bater significa rodada honesta; não bater significa escalar para o suporte do operador e (se não resolver) o regulador.

Tempo total: 60 segundos por rodada. A matemática é idêntica à que o servidor da Spribe roda; a única diferença é o local de execução (seu navegador vs servidor do cassino). Mesmas entradas produzem mesmas saídas; é a propriedade do determinismo aplicada à verificação baseada em seeds.

Veredito editorial: seeds são a base criptográfica da confiança em crash

Server seed e client seed são as primitivas elementares que tornam crash games provably fair de fato justos. Entender em nível de mecânica permite avaliar o framework de confiança em vez de depender da fé. A inovação Spribe das três client seeds é genuinamente relevante em termos estruturais; o padrão SmartSoft de uma client seed é defensável matematicamente, mas estruturalmente menos rígido; o esquema 1win de quatro seeds é ainda mais rígido que o de três. Os quatro modelos (uma seed, três seeds, quatro seeds, com ou sem entropia Bitcoin) são críveis; nenhum está quebrado; o diferencial de confiança é a casca do operador, não a primitiva criptográfica em si.

O reveal é o que dá sentido à matemática. Operadores que publicam reveals com previsibilidade (cassinos Tier 1 UKGC + MGA + ANJL Brasil) viabilizam a verificação; operadores que escondem (algumas plataformas offshore Curaçao) destroem o protocolo, independentemente da qualidade da matemática subjacente. Trate atrito de reveal como o sinal mais forte de confiança no operador que você consegue agir. Combine o entendimento criptográfico com licenciamento de regulador e hábito de verificar (uma rodada amostrada por sessão); o framework em camadas produz confiança durável que nenhuma camada sozinha entrega.

Para o tutorial completo de provably fair, nosso guia provably fair cobre o protocolo no nível de protocolo. Para o algoritmo no nível de código, algoritmo do crash game entra na fórmula. Para o tutorial operacional de verificação, verificar crash game cobre o passo a passo. Este artigo sobre seeds é a base em nível de bits; os outros constroem em cima.