Algoritmo do Crash Game: Como o Multiplicador É Determinado de Verdade (Nível de Código)

Pesquisar por "algoritmo do crash game" devolve dezenas de artigos prometendo expor como a matemática funciona, e quase todos viram firula de marketing ("a IA calcula o multiplicador a partir do padrão de apostas") ou ficção pura ("o Aviator usa cadeia de Markov para previsão"). O algoritmo de verdade é publicamente documentado por todos os grandes provedores, cabe em três linhas de código e usa uma primitiva criptográfica conhecida (SHA-256 ou SHA-512). Este texto te leva pela fórmula em nível de código para você ver, com seus próprios olhos, o que define o multiplicador de cada rodada. A matemática é curtinha; as implicações para confiança são grandes.

Conhecer o algoritmo é a base da confiança rodada a rodada. Sem isso, você fica refém da palavra do cassino de que está rodando matemática justa. Com isso, você recalcula qualquer rodada em 60 segundos e confirma ou derruba o compromisso criptográfico. A informação é aberta e gratuita; o único pedágio é estar disposto a ler três linhas de código.

Determinístico significa tudo predeterminado pré-rodada

A propriedade mais importante do algoritmo do crash game: ele é determinístico. Dadas entradas idênticas (server seed, client seed(s), nonce), a fórmula produz saídas idênticas em qualquer execução. Pode rodar num laptop de dez anos atrás ou num supercomputador quântico; o resultado sai bit a bit igual. Não tem aleatoriedade dentro do algoritmo em si.

Por que isso importa: o determinismo é o que torna a verificação provably fair viável. O cassino se compromete com uma server seed antes da rodada; a seed é hashada e o hash sai público. Depois da rodada, o cassino revela a seed; quem rodar o mesmo algoritmo, com as mesmas seeds e o mesmo nonce, chega ao mesmo ponto de crash. Aparecendo divergência, a matemática é evidência inequívoca de que algo deu errado.

De onde vem a aleatoriedade aparente, então? Das seeds. Server seeds são geradas pelo gerador pseudoaleatório do cassino antes da rodada, com entropia de SO mais bibliotecas criptográficas. Client seeds vêm dos jogadores (a Spribe puxa das três primeiras apostas; a SmartSoft, de quem aposta). As seeds são imprevisíveis para qualquer parte que não as controle; uma vez comprometidas, o algoritmo roda determinístico em cima delas.

Por isso aquela história de "o cassino escolhe multiplicador baixo quando todo mundo aposta alto" é mecanicamente impossível em esquemas provably fair. As seeds ficam comprometidas antes do cassino enxergar as apostas; o algoritmo roda determinístico sobre as seeds comprometidas; o multiplicador é o que a matemática produzir. Não sobra brecha pro cassino mexer depois do commit.

A fórmula do ponto de crash em nível de código

A fórmula completa em três passos:

Passo 1: hash das seeds + nonce.

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

SmartSoft e a maioria dos demais provedores usam SHA-256 com uma client seed: digest = SHA-256(server_seed + "|" + client_seed + "|" + nonce)

Passo 2: extrair uma fração h do digest.

// Spribe: 13 primeiros caracteres hex
hex_slice = digest[0:13]
// Converte hex em inteiro, divide pelo máximo possível (16^13)
h = int(hex_slice, 16) / (16 ** 13)

A SmartSoft usa fatia hex de tamanho diferente (em geral 8 caracteres), mas o princípio é igual: pegar uma fatia do digest, converter hex em decimal e dividir pelo máximo possível para chegar numa fração h entre 0 e 1 (excluindo o 1).

Passo 3: calcular o ponto de crash.

house_edge = 3 // para o Aviator (margem de 3% = RTP de 97%)
crash_point = (100 - house_edge) / (100 * (1 - h))
crash_point = round(crash_point, 2) // arredonda em 2 casas

É esse o algoritmo inteiro. Três passos, menos de 10 linhas de código. A saída é determinística; as entradas viram públicas depois da rodada; a verificação é viável para qualquer pessoa com noção básica de hash criptográfico.

Para o tutorial operacional completo de verificação em rodadas reais, nosso artigo verificar crash game cobre o passo a passo com prints. O verificador no navegador implementa a fórmula direto via Web Crypto API; você pode inspecionar o código fonte no devtools do próprio navegador.

De onde vêm as seeds

Três fontes de entropia alimentam o algoritmo. Cada uma com suas particularidades:

Server seed. Gerada pelo servidor do cassino antes da rodada começar. O método varia por provedor, mas em geral usa entropia de SO (tipo /dev/urandom no Linux ou equivalente) combinada com bibliotecas criptográficas que garantem saída imprevisível para partes externas. O tamanho fica em 64 caracteres hex (256 bits) para esquemas SHA-256 ou 128 caracteres hex (512 bits) para esquemas SHA-512. Antes da rodada, só o cassino conhece o valor; o hash é publicado, a seed em si fica privada. Depois da rodada, a seed é revelada publicamente.

Client seed(s). Geradas pelos jogadores, contribuídas antes da rodada. O mecanismo de contribuição muda:

• Spribe (Aviator): três client seeds tiradas dos três primeiros jogadores que apostam em cada rodada. Cada uma é uma string hex aleatória (em geral 32 chars) gerada do lado cliente pelo navegador no momento que o jogador conecta. Cada seed é independente das outras.
• SmartSoft (JetX): uma client seed do jogador que aposta. Em geral é o ID da conta com hash via função do cassino, ou uma string aleatória que o jogador pode trocar.
• 1win Gaming (Lucky Jet): quatro client seeds (a do jogador mais três tiradas de outros jogadores aleatórios ao vivo). Criptograficamente parecido com o esquema de três seeds da Spribe, com uma seed independente extra.
• BGaming (Aviamasters, Space XY): uma client seed para a maior parte dos títulos; alguns selecionados incorporam hash de bloco do Bitcoin como fonte de entropia adicional.

São as client seeds que protegem contra manipulação do lado do cassino. Sem elas, a server seed sozinha determinaria o resultado; com elas, o cassino precisa se comprometer com a server seed antes de saber qual client seed vai entrar. O hash que sai é a mistura criptográfica de valores que ninguém controla por completo.

Nonce. Um contador simples de rodada que avança em um a cada rodada sob a mesma chave de server seed. Garante que cada rodada gere um digest único mesmo se as seeds coincidirem. Combinado com as seeds, a tupla (server + client + nonce) é única por rodada.

Para detalhes em nível de bits de como as seeds combinam dentro do hash, nosso tutorial sobre server seed e client seed cobre as primitivas criptográficas.

SHA-256 e SHA-512: o que a diferença significa de fato

Tanto SHA-256 quanto SHA-512 são membros da família SHA-2, projetada por criptógrafos da NSA e padronizada pelo NIST em 2002. As duas foram extensamente estudadas; nenhuma quebrou na prática (sem ataques de pre-image em 2026; sem ataques de colisão também).

A diferença numérica: SHA-256 produz 256 bits (64 chars hex); SHA-512 produz 512 bits (128 chars hex). O dobro de bits significa um espaço de hash exponencialmente maior, ou seja, mais folga contra futuros avanços de criptanálise. Se computadores quânticos um dia acelerarem certos ataques de hash, o SHA-256 pode começar a apresentar fragilidades enquanto o SHA-512 ainda sobra com margem confortável. Em 2026, as duas são igualmente seguras para crash; a escolha do SHA-512 é estruturalmente mais conservadora para estabilidade de longo prazo.

Por que a Spribe escolheu SHA-512:

• Future-proofing. Crash games podem rodar por décadas; SHA-512 entrega mais folga contra avanços futuros de criptanálise.
• Diferenciação de marketing. SHA-512 + três client seeds é o patamar mais rígido do crash regulamentado; a narrativa de "o dobro de bits, três seeds independentes" agrada audiência cripto-consciente.
• Compatibilidade operacional com esquema de várias seeds. O digest de 128 caracteres acomoda naturalmente a concatenação de três seeds sem perda de informação; SHA-256 funcionaria, mas com margens apertadas.

Por que SmartSoft e a maioria escolheram SHA-256:

• Padrão da indústria. O Bustabit lançou o crash original em 2014 com SHA-256; o protocolo é bem estudado e auditado.
• Performance. O cálculo de SHA-256 sai cerca de 30% mais rápido que SHA-512 em hardware comum. Para operadores de alto throughput (400 mil apostas por minuto), isso pesa direto no custo de infraestrutura.
• Compatibilidade com esquema de seed única. O digest de 64 chars do SHA-256 dá conta para esquemas de uma client seed; os bits extras do SHA-512 seriam exagero.

Na prática: os dois esquemas são matematicamente defensáveis em 2026. A escolha da Spribe sinaliza conservadorismo criptográfico mais rígido; a escolha da SmartSoft sinaliza confiabilidade padrão da indústria. Nenhum dos dois está errado; eles refletem filosofias diferentes de design. Nossa comparação Spribe e BGaming cobre a diferenciação mais ampla entre provedores.

Por que jogador não consegue prever o ponto de crash

Resistência a pre-image é a propriedade criptográfica que torna a previsão impossível. SHA-256 e SHA-512 são desenhados para que conhecer o digest não permita calcular a entrada. Mesmo com poder computacional infinito, achar a seed a partir do hash exige busca por força bruta em um espaço astronomicamente grande (2^256 ou 2^512 possibilidades).

Três impossibilidades específicas:

1. Prever a server seed a partir do hash publicado. O cassino publica hash(server_seed) antes da rodada. A resistência a pre-image significa que você não calcula server_seed a partir desse hash; teria de testar 2^256 ou 2^512 candidatos por força bruta, o que é computacionalmente inviável em qualquer escala.
2. Prever o crash da próxima rodada a partir das anteriores. Cada rodada usa combinação diferente de (server seed + client seeds + nonce). As seeds são geradas independentemente; saídas da rodada N não revelam nada sobre as entradas da rodada N+1. Procurar padrão entre rodadas é matematicamente sem sentido, porque as rodadas não têm conexão causal.
3. Prever o resultado antes que todas as entradas existam. No esquema da Spribe, as três client seeds vêm dos três primeiros jogadores que apostam em cada rodada; esses jogadores ainda não existem quando um app preditor é vendido. A combinação completa só fica disponível depois que a rodada começou; prever antes desse ponto é impossível por definição.

Por isso apps preditores são 100% golpe, como documentado no nosso artigo sobre crash games manipulados. A matemática proíbe; vendedores rodam funis de afiliado ou distribuem malware em vez de prever de fato.

Que algoritmos os crash games NÃO usam

Tão importante quanto entender o que o algoritmo É é entender o que ele NÃO é. Três mitos que aparecem direto:

• Machine learning / IA. Crash games não rodam modelos de ML em cima de padrões de aposta para determinar multiplicador. A fórmula determinística baseada em SHA não é sistema de aprendizagem; não adapta, não aprende, não atualiza com base em resultado. O modelo de receita do cassino se sustenta na margem da casa publicada, codificada direto na constante house_edge da fórmula.
• Cadeias de Markov / previsão por padrão. Multiplicador não é determinado por probabilidade de transição das N rodadas anteriores. Cada rodada é independente; resultados anteriores não afetam entradas futuras. Modelos de Markov implicariam conexão causal entre rodadas; o esquema criptográfico remove explicitamente essa conexão.
• Ajuste consciente do volume de apostas. O cassino não modifica o algoritmo conforme o agregado de apostas ("galera apostando alto, faz crashar cedo"). O commit criptográfico acontece antes do cassino enxergar as apostas; modificar o algoritmo depois do commit invalidaria o hash publicado e seria detectável.

O que o algoritmo USA: hash SHA-256 ou SHA-512, aritmética inteira sobre dígitos hex e uma constante de margem da casa. Só isso. A simplicidade do algoritmo real contrasta com a complexidade dos mitos. E a simplicidade é uma feature: torna a verificação viável para qualquer jogador com navegador.

Verifique você mesmo qualquer rodada

Procedimento completo de verificação em uma rodada real do Aviator:

1. Abra o Aviator no seu operador. Jogue uma rodada (ou abra uma do histórico).
2. Vai no painel provably fair: em geral Configurações -> Provably Fair Settings -> Minhas Apostas -> selecione a rodada -> Mostrar a matemática.
3. Copie os quatro valores do painel: server seed revelada, client seeds 1-3, nonce, multiplicador exibido.
4. Abra nosso verificador em uma nova aba.
5. Escolha o esquema: SHA-512 + 3 seeds (Spribe / Aviator).
6. Cole cada valor no campo correspondente.
7. Clique em Calcular. O verificador faz o hash via SHA-512, extrai os 13 primeiros chars hex, calcula h, aplica a fórmula (100 - 3) / (100 (1 - h)), arredonda em 2 casas e mostra o resultado.
8. Compare a saída com o multiplicador exibido. Bateu, foi honesta; não bateu, escale.

Tempo total: cerca de 60 segundos por rodada. A matemática é idêntica à que o servidor da Spribe roda; a única diferença é que o verificador faz a conta no seu navegador em vez do servidor do cassino. Mesmas entradas dão mesmas saídas; é a propriedade do determinismo aplicada à verificação de crash.

Veredito editorial: algoritmo simples, framework de confiança robusto

O algoritmo do crash game é uma das primitivas mais simples do jogo de cassino e uma das mais incompreendidas. Não é IA; não é cadeia de Markov; não se adapta a comportamento de jogador. É uma fórmula determinística baseada em SHA que recebe três entradas (seeds + nonce), produz uma saída (o multiplicador) e roda igualzinho em qualquer computador que execute funções hash. A simplicidade é justamente o ponto: qualquer jogador com navegador recalcula e verifica.

O framework de confiança construído ao redor do algoritmo é a proteção real. Provably fair prende o cassino a seeds específicas antes da rodada; auditorias verificam se o RTP publicado bate com o que o algoritmo produz; reguladores fiscalizam o comportamento do operador no nível da casca. Cada camada cobre o que as outras não cobrem. O algoritmo é o núcleo interno; o framework externo é o que o torna operacionalmente útil para jogadores que não são desenvolvedores.

Para o tutorial operacional de verificação, nosso artigo verificar crash game cobre o passo a passo. Para as primitivas criptográficas em detalhe, nosso guia provably fair aprofunda em SHA-256 e SHA-512 lado a lado. Para a mecânica das seeds em nível de bits, o artigo de server seed e client seed é o tratamento dedicado. Juntos, esses quatro textos formam o framework completo de confiança; este artigo do algoritmo é a base técnica.