A casa joga com vantagem: a matemática, o código e o controle por trás das bets

A tela mostra um avião subindo, símbolos girando ou uma bola atravessando obstáculos. Para quem joga, parece que o resultado está nascendo naquele instante. Mas a animação é apenas a parte visível. O que realmente decide uma rodada pode ter acontecido antes, em uma função no servidor, em uma seed controlada pela própria plataforma ou em uma configuração que o usuário jamais verá.

Foi por isso que eu decidi sair da discussão rasa entre “é só sorte” e “é tudo manipulado”. As duas frases são insuficientes. Um jogo pode usar aleatoriedade real e ainda ter expectativa matemática negativa. Pode calcular o resultado antes da animação sem necessariamente fraudá-lo. Pode usar criptografia e continuar incapaz de provar que a escolha inicial foi imparcial. E pode não conter uma linha explícita de force_loss, mas ainda concentrar no operador controles que o jogador não consegue auditar.

Neste artigo, abro os repositórios públicos nutcas3/aviator-fun e daanrox/subway-pay, comparo outros clones, reconstruo a matemática, sigo o ciclo de uma rodada e examino seeds, HMAC, cash-out, autenticação, saldo, saque, dificuldade e painel administrativo. Depois conecto o código à regulação, ao design comportamental, ao mercado de afiliados, à ética e ao cuidado pastoral.

Esses projetos tornam visíveis possibilidades técnicas reais: resultado pré-calculado, seeds controladas pelo servidor, parâmetros administrativos, simulações e fluxos financeiros frágeis. A constatação termina nos sistemas efetivamente examinados. Como eu não tive acesso ao código-fonte, à configuração, aos logs nem à infraestrutura das grandes plataformas comerciais, este artigo não afirma que elas utilizem os mesmos mecanismos ou pratiquem manipulação. Possibilidade técnica não é prova de uso.

É uma investigação longa porque o assunto não cabe em uma denúncia de rede social. Todos os exemplos, fórmulas, achados, limitações, matrizes, checklists, recomendações e fontes do dossiê original estão aqui, mas reorganizados para uma leitura técnica e progressiva.

A posição deste artigo é direta: não aposte. Não existe horário mágico, sequência segura ou método capaz de anular a vantagem matemática da casa. Algumas pessoas vencem rodadas e uma minoria pode encerrar uma sessão no lucro, mas essas exceções não mudam a expectativa negativa do conjunto nem o modelo econômico sustentado pela diferença entre apostas recebidas e prêmios pagos. Isso não significa afirmar que todas as bets roubam, manipulam resultados ou cometem fraude: cada uma dessas acusações exigiria prova específica. A expressão “jogo responsável” aparece aqui apenas como categoria regulatória; ela não torna a aposta financeiramente favorável, segura ou recomendável.

O ponto central: vantagem matemática, manipulabilidade, manipulação direta e ausência de auditoria são coisas diferentes. Misturar essas categorias enfraquece qualquer crítica séria.

Índice completo do artigo

1 Antes de começar: escopo, ética e segurança

A regra aqui é simples: entender e prevenir, não ensinar alguém a instalar, operar, promover ou fraudar uma plataforma. Os repositórios são públicos e aparecem como objetos de auditoria, mas não devem ser tratados como se revelassem o código interno de marcas comerciais conhecidas. Um clone independente prova o que existe naquele clone — nada além disso.

Durante toda a leitura, vou trabalhar com três níveis de afirmação. “Foi encontrado” significa que o mecanismo aparece no código analisado. “Seria tecnicamente possível” descreve uma capacidade demonstrada pela arquitetura, sem afirmar que tenha sido utilizada. “Não é possível concluir” marca tudo o que dependeria de código proprietário, configuração de produção, logs ou evidência externa aos repositórios. Nenhuma descoberta será transferida automaticamente para uma marca ou plataforma diferente.

• Vantagem matemática comprovada: a fórmula cria expectativa negativa para quem aposta.
• Manipulabilidade comprovada: o código entrega ao operador um controle relevante, sem provar que ele foi usado para fraudar.
• Manipulação direta comprovada: existe uma lógica explícita de resultado forçado, seleção por usuário ou intervenção adaptativa.
• Não auditabilidade: faltam dados para que o usuário ou um auditor confirme a imparcialidade da rodada.

Dizer que um sistema é manipulável não prova que uma rodada foi manipulada. Dizer que o resultado foi calculado antes da animação não prova fraude. E dizer que existe vantagem da casa não significa que cada pessoa perderá em toda sessão; significa que o conjunto de apostas favorece economicamente o operador.

Vamos começar pela diferença entre aquilo que a interface encena e aquilo que o software realmente executa. É nessa distância que nasce a assimetria de controle.

2 Por que olhar para o código muda a conversa sobre apostas

2.1 Por que tudo muda quando o cassino cabe no celular

A aposta digital combina três elementos que, separadamente, já possuem grande poder de influência: dinheiro, incerteza e tecnologia interativa. Quando esses elementos são reunidos em um telefone celular, a participação deixa de depender de deslocamento físico, horário de funcionamento ou interação com um atendente. O usuário pode apostar durante uma pausa, no transporte, em casa ou no trabalho. O intervalo entre a decisão e o resultado pode durar poucos segundos.

Essa velocidade altera a natureza da experiência. Uma loteria tradicional normalmente separa a compra do bilhete e o sorteio. Em jogos digitais, aposta, animação, resultado, nova aposta e promessa de recuperação podem ser condensados em uma sequência contínua. O sistema pode ainda acrescentar notificações, sons, barras de progresso, multiplicadores, recompensas, rankings, mensagens de incentivo e supostos vencedores.

O crescimento do setor no Brasil tornou necessário distinguir pelo menos quatro debates:

• a legalidade e a regulação das empresas;
• a matemática inerente aos jogos;
• a integridade técnica do software;
• os impactos humanos e éticos da atividade.

Uma empresa autorizada pode oferecer um jogo com vantagem matemática da casa e ainda cumprir a regulamentação. Um sistema tecnicamente aleatório pode continuar produzindo perda esperada ao apostador. Um clone não autorizado pode copiar a aparência de um produto e substituir suas regras. Uma interface pode simular transparência sem oferecer material suficiente para auditoria independente.

Por isso, a pergunta “é sorte ou manipulação?” é insuficiente quando formulada como uma escolha binária. Um jogo pode utilizar números aleatórios e, ao mesmo tempo, possuir vantagem da casa. Pode calcular honestamente um resultado aleatório, mas esconder as probabilidades efetivas. Pode permitir alteração administrativa de parâmetros sem que a alteração seja usada. Pode usar criptografia verdadeira para provar apenas uma parte do processo. Pode ainda exibir uma animação cujo resultado já foi decidido, sem que esse pré-cálculo seja, por si só, ilícito.

A questão central desta investigação é mais precisa:

Quais mecanismos matemáticos, arquiteturais e administrativos podem determinar ou influenciar resultados em jogos digitais de aposta, quais deles aparecem nos repositórios públicos analisados e até onde o código permite concluir manipulação, manipulabilidade ou ausência de auditoria?

2.2 Quando o problema deixa de ser apenas individual

O Banco Central publicou, em 2024, uma análise preliminar baseada principalmente em transferências via Pix para empresas identificadas como relacionadas a jogos e apostas. O estudo estimou movimentação bruta mensal entre R$ 18 bilhões e R$ 21 bilhões, retenção aproximada de 15% pelas empresas e participação de cerca de 24 milhões de pessoas durante o período analisado. O próprio Banco Central advertiu que os números representavam transferências brutas e estimativas, não uma medição perfeita de perda líquida individual [BCB, 2024].

No primeiro semestre de 2025, já sob o mercado federal regulado, a Secretaria de Prêmios e Apostas divulgou que 17,7 milhões de brasileiros haviam realizado apostas de quota fixa. O dado não deve ser somado diretamente ao número do Banco Central, pois os períodos, metodologias e universos são diferentes. Ainda assim, ambos demonstram escala populacional relevante [SPA/MF, 2025].

A Organização Mundial da Saúde reconhece que o jogo pode causar danos financeiros, familiares, psicológicos e sociais, especialmente quando o gasto desvia recursos de necessidades essenciais. A OMS também ressalta que os danos não se limitam aos casos diagnosticados como transtorno do jogo: existe um espectro de consequências sobre jogadores, familiares, empregadores e comunidades [WHO, 2024].

O ponto fica ainda mais importante quando a plataforma se apresenta como uma tecnologia neutra. Software não nasce neutro: alguém escolhe a fórmula de pagamento, a velocidade, a duração da rodada, o limite de aposta, o comportamento da animação, os dados exibidos, quem acessa o painel administrativo e quais registros serão guardados. Abrir o código torna ao menos parte dessas decisões visível.

2.3 A parte que a tela não mostra

Em um cassino físico, a roleta, o baralho, as fichas e a mesa podem ser inspecionados materialmente. Em software, a regra existe como código e configuração. O usuário recebe apenas a interface e as respostas do servidor. Quando o motor de resultado permanece fechado, o jogador não vê:

• a fonte de aleatoriedade;
• a fórmula usada para converter números em prêmios;
• a versão do algoritmo;
• os parâmetros ativos;
• a ordem temporal entre aposta e sorteio;
• as intervenções administrativas;
• os registros descartados;
• as diferenças entre contas;
• a possibilidade de alteração durante o jogo.

A confiança, portanto, depende de mecanismos substitutivos: certificação, auditoria, compromisso criptográfico, logs, segregação de funções, controle regulatório e reputação. Um selo ou a expressão “provably fair” não substitui a análise do protocolo completo.

2.4 O lado humano e pastoral também entra nessa conversa

O tema também possui dimensão teológica. O problema não pode ser reduzido à afirmação simplista de que todo risco financeiro é pecado, pois inúmeras atividades legítimas envolvem risco. A análise cristã deve perguntar sobre finalidade, domínio próprio, responsabilidade, verdade, cuidado com o próximo, exploração de vulneráveis e relação com o dinheiro.

Textos como Lc 12:15 advertem contra a ganância; Mt 6:24 aborda a impossibilidade de servir simultaneamente a Deus e ao dinheiro; 1Tm 6:9–10 trata das armadilhas associadas ao desejo de enriquecimento; Pv 11:1 condena balanças desonestas; 1Co 6:12 oferece o princípio de não se deixar dominar. Esses textos não constituem uma descrição técnica de RNG, mas fornecem categorias morais para avaliar promessa de enriquecimento, persuasão, dependência e opacidade.

Há ainda um problema linguístico contemporâneo. A palavra inglesa bet significa aposta. O elemento Bet, Beth ou Beit em nomes bíblicos deriva do hebraico relacionado a “casa”. Betel, por exemplo, significa “casa de Deus”. A semelhança gráfica não cria relação etimológica ou espiritual entre cassino e nomes bíblicos. O uso de linguagem “gospel” não altera a estrutura econômica do produto.

3 O que precisamos descobrir olhando para esses projetos

A pergunta central. Como os mecanismos de vantagem matemática, geração de resultado, configuração administrativa e apresentação visual aparecem em clones públicos de jogos de aposta, e quais conclusões podem ser sustentadas sem generalizar indevidamente para todas as plataformas comerciais?

O que esta análise procura esclarecer. Analisar, sob perspectiva técnica, matemática, regulatória, comportamental, ética e teológica, repositórios públicos que reproduzem jogos e plataformas de apostas, classificando evidências de vantagem da casa, manipulabilidade, manipulação direta e falta de auditabilidade.

3.1 As respostas que vamos buscar pelo caminho

1. Explicar de maneira acessível HOUSE_EDGE, RTP, valor esperado e volatilidade.
2. Diferenciar resultado aleatório, resultado pré-calculado e resultado manipulado.
3. Examinar o protocolo “provably fair” do nutcas3/aviator-fun.
4. Examinar configurações, mensagens e fluxos do daanrox/subway-pay.
5. Identificar falhas de autenticação, autorização, atomicidade e persistência relevantes para integridade.
6. Comparar alegações de README com o código efetivamente publicado.
7. Desenvolver taxonomia de mecanismos de controle.
8. Relacionar achados a requisitos brasileiros e padrões internacionais.
9. Discutir conflito de interesse em afiliados e participação na receita.
10. Formular princípios éticos e teológicos para comunicação pastoral.
11. Propor checklist reproduzível para futuras auditorias.
12. Estabelecer linguagem pública que informe sem produzir acusações não demonstradas.

3.2 As ideias que o código precisa confirmar ou derrubar

Em vez de partir da conclusão de que tudo é sorte ou tudo é fraude, a análise testa seis ideias concretas:

• A vantagem matemática pode ser demonstrada pela própria fórmula, sem que seja necessário provar fraude.
• Um protocolo criptográfico pode confirmar a consistência dos dados e ainda não garantir que a escolha inicial foi imparcial.
• Calcular o resultado antes da animação não é necessariamente fraudulento, mas torna o compromisso temporal e a auditoria muito mais importantes.
• Configurações administrativas escondidas criam assimetria de informação, mesmo quando não existe evidência de uso abusivo.
• Clones públicos revelam possibilidades de arquitetura, mas não podem ser atribuídos automaticamente a plataformas comerciais.
• Mensagens, animações e prova social podem empurrar a pessoa para outra rodada independentemente da matemática do resultado.

4 Como eu segui o caminho do resultado dentro do código

4.1 Como a leitura foi feita na prática

Eu trabalhei em duas frentes. Na primeira, li o código, reconstruí a arquitetura, acompanhei mensagens da interface e comparei o comportamento encontrado com normas e padrões técnicos. Na segunda, levei as fórmulas para o papel: valor esperado, probabilidade dos multiplicadores e formato das distribuições.

Isso permite descrever o que cada sistema faz, testar matematicamente suas regras e transformar os achados em algo reutilizável — checklist, matriz de evidências e recomendações — sem fingir que um repositório público responde por todo o mercado.

Por que esses projetos entraram na análise. Os repositórios foram selecionados porque já haviam sido identificados por quem conduziu a auditoria como projetos públicos relacionados a jogos de aposta. Não foi realizada uma busca destinada a encontrar sistemas para operação. Os objetos centrais são:

Estudo de caso A: nutcas3/aviator-fun. Repositório público com backend em Go, Redis, PostgreSQL e comunicação em tempo real. Arquivos centrais:

• internal/game/provably_fair.go;
• internal/game/manager.go;
• internal/game/provably_fair_test.go;
• internal/server/handlers.go;
• internal/server/game_routes.go.

Estudo de caso B: daanrox/subway-pay. Repositório público em PHP e SQL, anunciado como sistema de iGaming. Arquivos centrais:

• README.md;
• painel/index.php;
• play/win.php;
• play/loss.php;
• saque/saque.php;
• sql_subway.sql.

Casos comparativos

• tanh1c/stake-originals-clone;
• akashmahlaz/aviator-crash.

Os casos comparativos servem para demonstrar diferença entre demo, frontend, documentação e motor de resultado.

O passo a passo usado para abrir cada sistema. A auditoria seguiu dez etapas.

Inventário. Foram identificados arquivos, linguagens, dependências, banco, cache e componentes de interface.

Localização do motor. Buscou-se o ponto em que o sistema transforma entradas em resultado: multiplicador, posição de minas, resultado de dado ou pagamento.

Reconstrução temporal. Foi reconstruída a sequência:

1. criação de rodada;
2. geração de aleatoriedade;
3. publicação de compromisso;
4. abertura de apostas;
5. execução visual;
6. encerramento;
7. revelação;
8. persistência.

A ordem é essencial. Uma seed publicada depois da aposta oferece garantia diferente de um hash publicado antes.

Inspeção de parâmetros. Foram procurados termos como:

• house_edge;
• rtp;
• win_rate;
• lose_rate;
• chance;
• difficulty;
• force_win;
• force_loss;
• manual_result;
• risk;
• profit;
• fake;
• bot.

A presença do nome não basta. É necessário seguir o fluxo de uso.

Inspeção por usuário. Foi verificado se o resultado depende de identificador, saldo, depósito, perdas anteriores, grupo, afiliado ou marcação administrativa.

Integridade transacional. Foram avaliadas operações de saldo, aposta e saque quanto a atomicidade, idempotência e concorrência.

Auditabilidade. Foram avaliados compromisso, revelação, nonce, participação do cliente, histórico, retenção e endpoint de verificação.

Segurança de acesso. Foram examinadas autenticação, autorização, vínculo entre usuário e aposta e exposição de identificadores.

Comunicação e interface. Foram analisados textos de vitória, derrota, continuidade, popularidade e sucesso de saque.

Classificação de confiança. Cada achado foi classificado como:

• confirmado pelo código;
• inferência técnica forte;
• possibilidade arquitetural;
• não demonstrado.

4.1.1 O que o código público não permite afirmar

Esta investigação não teve acesso:

• aos servidores de plataformas comerciais;
• aos bancos em produção;
• aos painéis de operadores reais;
• aos certificados de cada jogo comercial;
• aos logs de apostas de usuários;
• aos contratos privados de afiliados;
• às versões não publicadas dos projetos.

A ausência de uma função no repositório não prova que ela não exista em outra versão. A presença de uma função em clone não prova que uma marca conhecida a utilize. A análise é uma fotografia do material público consultado.

4.1.2 Como outra pessoa pode conferir os mesmos achados

Para que outra pessoa consiga conferir o caminho percorrido, uma auditoria reproduzível deve registrar:

• nome do repositório;
• branch;
• data de consulta;
• arquivo;
• função;
• trecho relevante;
• interpretação;
• hipótese alternativa;
• nível de evidência.

Também é importante registrar o hash do commit consultado, porque branches podem mudar. Quando esse hash não estiver documentado, é preciso deixar claro que a análise se refere ao conteúdo público disponível na data da consulta.

4.2 Glossário para consultar durante a leitura

Aposta: valor arriscado em evento incerto.

Cash-out: encerramento da aposta antes do fim ou retirada em multiplicador.

Client seed: contribuição atribuída ao cliente.

Commitment: hash publicado antes da revelação.

Crash: jogo de multiplicador crescente que termina em ponto de queda.

Entropia: imprevisibilidade usada para gerar aleatoriedade.

GGR: apostas menos prêmios.

Hash: resumo criptográfico.

House edge: vantagem esperada da casa.

HMAC: autenticação baseada em hash e chave.

Idempotência: repetição não duplica efeito.

Ledger: registro de transações.

Mines: jogo de seleção de casas com minas e prêmios.

Nonce: contador usado para diferenciar resultados.

NGR: receita líquida após ajustes.

Plinko: bola em pinos com multiplicadores.

Provably fair: protocolo de verificação de resultado.

RNG: gerador de números aleatórios.

RTP: retorno teórico ao jogador.

Seed grinding: busca por seed conveniente antes do compromisso.

Slot: jogo de rolos e símbolos.

Volatilidade: dispersão de pagamentos.

Antes de procurar uma função suspeita no código, precisamos resolver um equívoco comum: aleatoriedade honesta não é sinônimo de pagamento justo.

5 Antes do código: a matemática que já favorece a casa

5.1 Sorte não significa igualdade

Uma moeda honesta produz cara e coroa com probabilidades iguais. Um jogo pode usar aleatoriedade honesta e ainda não oferecer pagamento justo. Se o jogador paga R$ 1 por uma aposta em cara e recebe apenas R$ 1,80 quando acerta, a probabilidade continua sendo 50%, mas o valor esperado é negativo.

O valor esperado é calculado pela soma dos resultados possíveis multiplicados por suas probabilidades.

Nessa expressão, p_i é a probabilidade de cada resultado e x_i é o ganho ou a perda correspondente. O símbolo de soma pede apenas que façamos a mesma conta para todos os resultados possíveis e juntemos os valores. Se o total ficar negativo, isso não prevê uma rodada específica; mostra quanto se perde, em média, quando a mesma regra é repetida muitas vezes.

Considere uma aposta de R$ 1:

• 50% de chance de perder R$ 1;
• 50% de chance de obter lucro líquido de R$ 0,80.

Então:

O primeiro termo representa os 50% de chance de perder o real inteiro. O segundo representa os 50% de chance de lucrar oitenta centavos. Depois de ponderar os dois caminhos, sobra menos dez centavos. Portanto, a perda esperada é de R$ 0,10 por real apostado. Uma rodada isolada pode terminar em ganho; o valor esperado descreve o comportamento médio de um grande conjunto de rodadas.

5.2 Vantagem da casa

A HOUSE_EDGE, ou vantagem da casa, representa a fração esperada que o operador retém em relação ao valor apostado, segundo a matemática do jogo.

Se o RTP é 96%, a vantagem teórica é aproximadamente 4%:

A conta subtrai do total — representado por 1, ou 100% — a parcela que volta aos jogadores. Se 96% retornam em média, os 4% restantes formam a margem matemática da casa. RTP e house edge são, portanto, duas maneiras de observar a mesma regra por lados opostos.

Isso não significa que uma pessoa que aposta R$ 100 necessariamente encerrará com R$ 96. A afirmação correta é coletiva e de longo prazo: para um volume muito grande de apostas, o pagamento esperado é de R$ 96 por R$ 100 movimentados, antes de considerar imperfeições, bônus, limites e comportamento.

5.3 Exemplo prático

Suponha mil apostas de R$ 10 em um jogo com vantagem de 4%.

Volume total:

Perda esperada agregada:

Os R$ 400 não são uma cobrança fixa nem a previsão do saldo de uma pessoa. Eles representam o que a regra tende a reter quando o volume de R$ 10 mil é repetido em condições semelhantes. O resultado real daquele lote pode ser R$ 1.000 de perda, R$ 100 de ganho ou outro valor. A expectativa não é profecia da sessão. Para o operador, porém, milhões de rodadas reduzem a importância relativa dessas oscilações.

A plataforma possui:

• capital maior;
• mais rodadas;
• jogadores independentes;
• limites de pagamento;
• dados agregados;
• vantagem matemática.

O jogador possui:

• capital limitado;
• necessidade de encerrar;
• exposição emocional;
• risco de perseguir perdas;
• amostra pequena e volátil.

5.4 RTP não é devolução individual

A expressão “RTP de 96%” costuma ser interpretada equivocadamente como garantia de que R$ 96 voltarão para quem apostar R$ 100. O RTP normalmente se refere ao conjunto de apostas em um horizonte extenso.

Dois jogos com RTP de 96% podem oferecer experiências diferentes:

• jogo A paga prêmios pequenos com frequência;
• jogo B paga raramente, mas com valor alto;
• jogo C concentra pagamento em prêmio máximo improvável;
• jogo D impõe limites ou regras de saque.

O RTP não descreve sozinho a distribuição.

5.5 Volatilidade

Volatilidade descreve a dispersão dos resultados. Alta volatilidade significa longos períodos sem prêmio, interrompidos por pagamentos maiores. Baixa volatilidade produz retornos pequenos e frequentes.

Essa diferença importa para percepção. Prêmios frequentes, mesmo abaixo do valor apostado, podem ser apresentados com som e celebração. O jogador sente que “ganhou”, embora o saldo tenha diminuído. A literatura denomina esse fenômeno, em certos contextos, de “loss disguised as a win”: perda líquida apresentada como vitória.

5.6 Taxa de vitória não é RTP

WIN_RATE e RTP não são sinônimos.

Um jogo pode ter taxa de vitória de 40% e RTP de 90%, se as vitórias forem pequenas. Outro pode ter taxa de vitória de 5% e RTP de 96%, se poucos prêmios forem grandes.

Exemplo:

• aposta: R$ 1;
• 40% das rodadas pagam R$ 1,50;
• 60% pagam zero.

Pagamento esperado:

RTP:

A taxa de vitória é 40%, mas a vantagem da casa é 40%.

5.7 “Só 10% ganham” exige definição

Dizer que “o operador configura para só 10% ganharem” pode significar coisas diferentes:

1. 10% das rodadas têm pagamento maior que zero;
2. 10% das rodadas geram lucro líquido;
3. 10% dos usuários encerram sessão positivos;
4. 10% do dinheiro volta;
5. 10% das contas recebem prêmio;
6. 10% dos resultados alcançam certo multiplicador.

Uma investigação precisa definir a métrica. Um win_rate de 10% não implica automaticamente retenção de 90%, pois os 10% vencedores podem receber pagamentos grandes. Para provar retenção de 90%, é necessário calcular valores, não apenas frequência.

5.8 Repetição e expectativa negativa

Considere apostas independentes com perda esperada de 4%. Se o jogador movimenta R$ 10 repetidamente, o valor total apostado cresce mesmo quando o depósito inicial é menor, pois prêmios podem ser reapostados.

Um depósito de R$ 100 pode gerar volume de R$ 500 antes do saldo acabar. A vantagem incide sobre volume, não apenas depósito:

Se o volume acumulado for R$ 500:

Essa é uma das razões pelas quais “ganhei e continuei” pode terminar em perda. O prêmio aumenta a capacidade de gerar volume adicional.

5.9 Falácia do jogador

A falácia do jogador é a crença de que uma sequência de perdas torna a vitória “devida”. Em eventos independentes, o histórico não altera a probabilidade da próxima rodada.

Se a chance de vitória é 10%, perder nove vezes não torna a décima uma certeza. A probabilidade permanece 10%, salvo se o sistema for adaptativo.

Mensagens como “não desanime”, “a persistência é a chave” ou “continue para recuperar” exploram uma intuição incompatível com independência estatística.

5.10 Lei dos grandes números e sua interpretação

A lei dos grandes números afirma que a média observada tende à expectativa conforme aumenta a amostra, sob hipóteses adequadas. Ela não garante equilíbrio em amostras pequenas.

A casa opera no domínio das grandes amostras. O jogador frequentemente interpreta uma sequência curta como padrão:

• duas vitórias são vistas como “horário pagante”;
• três perdas são vistas como “prêmio próximo”;
• um influenciador vencedor é visto como prova de facilidade.

Amostras selecionadas não substituem dados completos.

Os exemplos seguintes mudam frequência, pagamento e multiplicador para mostrar por que uma porcentagem isolada quase nunca conta a história inteira.

5.11 Exemplo de RTP de 90%

Considere um jogo que recebe R$ 100.000 em apostas durante um período. Se o RTP teórico é de 90%, o pagamento médio de longo prazo é:

A vantagem da casa é:

Esse cálculo não informa quantas pessoas ganharam. É possível que:

• uma pessoa receba R$ 20.000;
• cem pessoas recebam R$ 500;
• milhares recebam pequenos retornos;
• a maioria termine negativa.

A publicidade tende a mostrar o prêmio de R$ 20.000, não a distribuição completa.

Taxa de vitória de 10% com RTP diferente

Cenário A

• 10% pagam 5x;
• 90% pagam zero.

RTP:

RTP de 50%, house edge de 50%.

5.12 Cenário B

• 10% pagam 9,5x;
• 90% pagam zero.

RTP:

RTP de 95%, house edge de 5%.

Os dois possuem taxa de vitória de 10%, mas retenções muito diferentes. Por isso, afirmar que 10% ganham e a casa fica com 90% pode ser errado sem saber o pagamento.

5.12.1 Retenção de 90%

Para que apenas 10% do valor retorne, o RTP deve ser 10%, independentemente da quantidade de vitórias.

Um painel que permitisse RTP de 10% poderia reter 90% em média. Entretanto, nenhum valor exato de 10% foi comprovado nos estudos de caso principais. Esse cenário deve ser apresentado apenas como exemplo do que um parâmetro poderia significar.

5.13 Volume reciclado

Jogador deposita R$ 100, aposta R$ 10 e recebe R$ 9 repetidamente. Embora cada rodada devolva quase tudo, o saldo diminui.

Após dez rodadas, o volume total é R$ 100. A perda aproximada, com edge de 10%, é R$ 10.

Se continuar usando o saldo restante, o volume pode superar o depósito. Assim, uma house edge aparentemente pequena pode consumir o saldo com repetição.

5.14 Probabilidade de sequência

Com chance de vitória de 10%, probabilidade de duas vitórias seguidas:

Em um milhão de pares de rodadas, milhares de sequências ocorrerão. Alguém publicará vídeo.

Probabilidade de vinte perdas seguidas:

Uma sequência longa não é prova de manipulação.

Chance de ruína. A chance de ruína depende de:

• capital;
• tamanho da aposta;
• edge;
• limite;
• estratégia;
• volatilidade;
• objetivo.

Com expectativa negativa e repetição ilimitada, a tendência de ruína é alta. Isso não significa que toda sessão termina em zero.

5.15 Martingale

Dobrar após perda não elimina house edge. A estratégia transforma muitas pequenas vitórias em risco de grande perda.

Exemplo com aposta inicial R$ 1:

• 1;
• 2;
• 4;
• 8;
• 16;
• 32;
• 64.

Após sete perdas, o total é R$ 127. Limites e capital impedem dobrar indefinidamente.

Crash com retirada em 2x. No modelo teórico de 1%:

• chance aproximada de chegar a 2x: 49,5%;
• retorno ao acertar: 2;
• retorno esperado: 0,99.

A estratégia parece “quase 50%”, mas a perda média permanece.

Crash em 1,10x. Chance aproximada:

Pagamento pequeno e alta frequência geram sensação de segurança. Uma queda instantânea elimina vários ganhos.

Crash em 100x. Chance aproximada:

Poucos vencedores podem produzir vídeos impressionantes. A expectativa continua perto de 99%.

Arredondamento. Se o motor trunca em vez de arredondar, sempre reduz frações. Pequenas diferenças acumulam.

Auditoria deve comparar:

• cálculo bruto;
• valor exibido;
• valor pago;
• regra de empate;
• precisão monetária.

5.16 Float e dinheiro

Usar float64 em saldo pode produzir erros binários. Sistemas financeiros preferem:

• centavos inteiros;
• decimal exato;
• regras de arredondamento.

Esse problema não foi o foco central, mas aparece como risco no aviator-fun.

Com a matemática clara, a próxima pergunta é arquitetural: qual componente decide o resultado e em que momento ele faz isso?

6 Onde o resultado realmente nasce

6.1 Cliente, servidor e motor

Um jogo on-line pode ser dividido em:

• cliente: navegador ou aplicativo;
• servidor de jogo: cria rodadas e resultados;
• carteira: controla saldo;
• banco ou cache: armazena estado;
• painel administrativo: define parâmetros;
• serviço de auditoria: registra e verifica;
• provedor de pagamento: recebe e paga;
• camada de marketing: afiliados, campanhas e notificações.

O usuário vê o cliente. A maior parte das decisões críticas ocorre fora dele.

6.2 Resultado no cliente

Em protótipos, o navegador pode usar Math.random():

const win = Math.random() < winProbability;

Isso é inadequado para dinheiro real porque:

• o código é modificável;
• a função não é criptograficamente apropriada;
• o servidor pode não validar;
• a versão entregue pode variar;
• não há prova independente.

Ainda assim, encontrar Math.random() não prova fraude. A função pode controlar partículas ou posição visual. É necessário seguir o valor até o prêmio.

6.3 Resultado no servidor

O servidor pode calcular o resultado e enviar apenas:

{
  "round_id": "R123",
  "multiplier": 1.42
}

Essa arquitetura é comum. O problema não é o servidor decidir; é a ausência de garantia sobre como decide.

Perguntas:

• o algoritmo foi certificado?
• a versão está registrada?
• a seed foi comprometida antes?
• o jogador contribuiu?
• existe log imutável?
• a probabilidade pode mudar?
• o resultado depende da conta?

6.4 Resultado pré-calculado

Em jogos Crash, o ponto de queda pode ser definido antes da animação. O servidor abre a rodada sabendo que ela terminará em 1,37x, por exemplo. A tela apenas incrementa até esse valor.

Isso tem vantagens técnicas:

• sincronização entre jogadores;
• reprodução determinística;
• verificação posterior;
• prevenção de alteração depois da aposta.

Mas também cria risco:

• o servidor pode selecionar o resultado antes de comprometer;
• o operador pode descartar rodadas;
• o resultado pode vazar;
• a animação pode sugerir decisão em tempo real.

A frase precisa é:

A animação pode representar um resultado previamente calculado; a honestidade depende de como esse resultado foi selecionado, comprometido, registrado e verificado.

6.4.1 Máquina de estados

Um Crash típico possui estados:

1. WAITING;
2. BETTING;
3. RUNNING;
4. CRASHED;
5. SETTLEMENT.

A integridade depende de transições controladas. Uma aposta enviada na fronteira entre BETTING e RUNNING precisa de timestamp autoritativo. Um saque enviado no instante do crash precisa de regra definida.

6.5 Painel administrativo

Parâmetros legítimos podem incluir:

• valor mínimo;
• valor máximo;
• idioma;
• manutenção;
• limites de sessão;
• velocidade visual.

Parâmetros sensíveis incluem:

• RTP;
• taxa de vitória;
• dificuldade;
• multiplicador;
• modo compensado;
• resultado manual;
• perfil de risco por usuário.

A existência de painel não é fraude. A questão é quais parâmetros são alteráveis, quem tem acesso, se a alteração é auditada e se exige nova certificação.

6.6 Configuração versus código

O comportamento pode estar:

• hard-coded;
• em arquivo .env;
• em banco;
• em painel;
• em serviço remoto;
• em fornecedor externo.

Auditar apenas o frontend raramente basta. Um clone visual pode não conter motor algum. Um README pode prometer backend não publicado.

Encontrar um parâmetro administrativo não autoriza chamar todo o sistema de fraude. Para falar com precisão, vale separar os mecanismos por nível de controle.

7 Nem toda assimetria é fraude: uma escala de controle

Nível A: vantagem matemática declarada. O jogo possui regra fixa favorável à casa. Não é manipulação individual; é expectativa negativa.

Exemplos:

• RTP de 96%;
• margem embutida nas odds;
• pagamento inferior ao justo;
• taxa de 1% em Crash.

7.1 Nível B: parâmetro configurável

O operador pode alterar probabilidade, dificuldade ou retorno.

Exemplo conceitual:

win_probability = admin_settings["win_probability"]

Isso comprova superfície de controle. Para provar abuso, é necessário registro da configuração usada.

Nível C: seleção por usuário. O resultado depende da conta:

if user.risk_group == "restricted":
    probability *= 0.5

Essa lógica seria evidência forte de tratamento desigual. Não foi encontrada nos dois principais repositórios examinados.

7.2 Nível D: resultado forçado

Exemplos conceituais:

if round.force_loss:
    return LOSS

ou:

result = admin.next_result

Esse é o tipo mais direto de intervenção. A mera busca por nomes pode falhar, pois a função pode estar disfarçada.

7.2.1 Nível E: jogo compensado

A probabilidade muda conforme arrecadação ou pagamentos anteriores:

if payouts_today > target:
    reduce_win_probability()

A UK Gambling Commission define jogos compensados como aqueles em que a probabilidade é ajustada conforme pagamentos ou entradas anteriores e proíbe comportamento adaptativo em jogos remotos sujeitos ao RTS 7.

7.3 Nível F: seed grinding

O operador gera muitas seeds, calcula o resultado de cada uma e publica apenas a que produz o resultado desejado. O hash posterior continuará válido.

Pseudocódigo ilustrativo:

while True:
    seed = secure_random()
    result = calculate(seed)
    if result <= target:
        publish(hash(seed))
        break

Este pseudocódigo demonstra o risco teórico. Não significa que esse laço exista no aviator-fun.

Nível G: descarte seletivo. O servidor calcula resultados, mas inicia apenas rodadas convenientes. Um compromisso isolado não prova que resultados anteriores não foram descartados. Cadeias de hashes ou fontes externas ajudam a reduzir esse risco.

Nível H: manipulação visual. A matemática pode permanecer igual, mas a interface altera percepção:

• near miss;
• celebração de perda líquida;
• multiplicador animado;
• botão pulsante;
• som de vitória;
• cronômetro;
• usuários falsos;
• vencedor simulado.

Nível I: fricção de retirada. O sistema facilita depósito e dificulta saque:

• rollover obscuro;
• revisão indefinida;
• condição lógica impossível;
• mensagem de sucesso antes do pagamento;
• taxas não transparentes.

7.3.1 Nível J: conflito de afiliado

O divulgador recebe participação na receita líquida gerada pelo grupo indicado. Isso não altera diretamente o RNG, mas cria incentivo econômico para levar pessoas a perderem ou continuarem.

Criptografia ajuda, mas somente quando o protocolo responde à pergunta certa. Um hash pode provar que algo não mudou depois; ele não prova sozinho que a escolha anterior foi neutra.

8 Provably fair sem marketing: o que a criptografia consegue provar

Conceito. “Provably fair” descreve protocolos em que o jogador pode recalcular o resultado usando dados comprometidos antes da rodada e revelados depois.

Componentes comuns:

• server seed;
• hash da server seed;
• client seed;
• nonce;
• função determinística;
• revelação;
• verificador independente.

8.1 HMAC

O HMAC combina chave e mensagem para produzir código autenticador. O RFC 2104 define o mecanismo. Em jogo:

A serverSeed funciona como chave secreta; clientSeed e nonce formam a mensagem. O símbolo ∥ significa concatenação: os valores são unidos em uma sequência bem definida. A saída H não é o prêmio em si; ela fornece bytes determinísticos que o motor converte em número e, depois, em multiplicador. Alterar qualquer entrada muda completamente essa saída.

HMAC oferece:

• integridade;
• autenticidade para quem conhece a chave;
• determinismo.

HMAC não oferece sozinho:

• prova de que a chave foi escolhida imparcialmente;
• prova de que não houve tentativas anteriores;
• prova de que a implementação publicada é a executada;
• prova de ausência de descarte;
• prova de independência do operador.

8.2 Compromisso criptográfico

O servidor publica:

Depois revela serverSeed. O jogador verifica:

Em linguagem simples, C funciona como um envelope lacrado: antes da rodada, o servidor mostra a impressão digital do segredo; depois, revela o segredo e qualquer pessoa confere se a impressão continua igual. Isso impede troca posterior, desde que o compromisso tenha sido publicado e registrado antes da aposta. O mecanismo, porém, não mostra quantos segredos foram testados antes de o servidor escolher aquele que decidiu lacrar.

Client seed. A client seed deve oferecer contribuição que o servidor não controle integralmente. Pode ser escolhida pelo jogador ou agregada de fontes independentes.

Se o servidor gera a variável chamada clientSeed, o nome não representa independência real.

Nonce. O nonce diferencia rodadas com as mesmas seeds. Deve ser:

• claramente definido;
• monotônico;
• persistente;
• associado à rodada;
• não reutilizado de forma ambígua.

Se reinicia a zero a cada processo, a auditabilidade histórica diminui.

Verificação útil. Uma verificação robusta deve permitir:

1. consultar o compromisso antes da aposta;
2. guardar timestamp;
3. saber a client seed;
4. saber o nonce;
5. obter a seed revelada;
6. conhecer a fórmula;
7. recalcular;
8. verificar a ordem;
9. consultar histórico;
10. comparar com log independente.

8.3 Autoverificação não é auditoria independente

Uma página fornecida pelo próprio operador pode mostrar cálculo correto e ainda omitir rodadas. A verificação deve poder ser reproduzida fora da plataforma.

Continua nas próximas seções: estudos de caso, regulação, comportamento, afiliados, teologia, checklist e referências.

Agora podemos abrir o primeiro caso. O objetivo não é procurar uma palavra comprometedora, e sim reconstruir a rodada inteira: geração das seeds, cálculo, abertura das apostas, crash, cash-out, revelação e persistência.

9 Por dentro do aviator-fun: resultado, seeds e compromisso criptográfico

9.1 Visão geral

O repositório nutcas3/aviator-fun apresenta uma arquitetura mais completa que a maioria dos clones visuais. O backend é escrito em Go, utiliza Fiber para HTTP, Redis para estado de rodada e saldo, PostgreSQL como dependência declarada e WebSocket para atualizações em tempo real. O projeto inclui um motor de Crash, além de rotas para Mines, Plinko e Dice.

A análise principal concentrou-se em cinco arquivos:

• internal/game/provably_fair.go;
• internal/game/manager.go;
• internal/game/provably_fair_test.go;
• internal/server/handlers.go;
• internal/server/game_routes.go.

O projeto é relevante porque permite observar a diferença entre quatro afirmações:

1. o resultado é determinístico;
2. a seed revelada corresponde ao compromisso;
3. a seed foi escolhida imparcialmente;
4. a rodada é segura para dinheiro real.

O código sustenta parcialmente as duas primeiras. Não sustenta integralmente a terceira e possui falhas importantes quanto à quarta.

9.2 Fórmula do ponto de queda

O arquivo provably_fair.go define:

const HOUSE_EDGE = 0.01

A função recebe serverSeed, clientSeed e nonce. Ela calcula HMAC-SHA256, utiliza os primeiros 64 bits e converte o número em valor entre zero e um. Em seguida, aplica vantagem de 1%.

De forma simplificada:

O HMAC produz muitos bits. O código pega os primeiros 64 e divide pelo total de valores possíveis em 64 bits. O resultado é r, um número entre zero e um. Até aqui ainda não existe avião, animação ou multiplicador: existe apenas um número pseudoaleatório reproduzível a partir das seeds e do nonce.

Se:

o multiplicador retorna 1,00x.

Caso contrário:

Essa segunda fórmula transforma r no multiplicador M. O fator 0,99 incorpora a vantagem aproximada de 1% da casa. Quando r se aproxima de 1, o denominador fica pequeno e o multiplicador cresce; por isso resultados muito altos existem, mas se tornam progressivamente raros. Depois da conversão, o código trunca o resultado para duas casas decimais e aplica limites.

A propriedade aproximada da distribuição é:

A leitura é direta: a chance de o jogo alcançar pelo menos um multiplicador x é aproximadamente 0,99 ÷ x. Para chegar a 2x, fica perto de 49,5%; para 10x, perto de 9,9%; para 100x, perto de 0,99%. Multiplicadores grandes chamam atenção visualmente, mas sua frequência cai na mesma proporção.

Para cash-out fixo em 2x, por exemplo, a probabilidade teórica de alcançar 2x é próxima de 49,5%. Se o jogador aposta R$ 1 e retira em 2x:

O retorno esperado é próximo de 99 centavos por real, antes de efeitos de truncamento e detalhes de implementação. A vantagem teórica é de aproximadamente 1%.

Para 10x:

A fórmula tenta manter expectativa semelhante em diferentes pontos de retirada. Isso não significa que estratégias diferentes sejam equivalentes na experiência: a volatilidade cresce com multiplicadores maiores.

9.3 O comentário “distribuição exponencial”

O código descreve a fórmula como “exponential distribution”. Essa descrição não é matematicamente precisa. Uma distribuição exponencial tradicional possui sobrevivência:

No motor analisado, a cauda se comporta aproximadamente como:

Trata-se de comportamento de cauda pesada semelhante a uma distribuição de Pareto, não de decaimento exponencial convencional. O erro no comentário não prova fraude, mas revela fragilidade na documentação matemática.

Para auditoria, comentários não são fonte final. A fórmula executada tem prioridade.

9.4 Truncamento e probabilidade de 1,00x

O projeto declara 1% de crash instantâneo:

if rFloat < HOUSE_EDGE {
    return MIN_MULTIPLIER
}

Porém, resultados acima de 1,00 e abaixo de 1,01 são truncados:

finalMultiplier := float64(int(crashValue*100)) / 100.0

Logo, não apenas a faixa explícita de 1% aparece como 1,00x. Parte da faixa seguinte também é exibida como 1,00x.

Para descobrir o limiar:

Assim, aproximadamente 1,98% dos valores uniformes podem resultar em exibição 1,00x, considerando a regra explícita e o truncamento. A taxa observada pode variar em amostras finitas.

A distinção é importante:

• vantagem declarada: 1%;
• frequência visual de 1,00x: perto de 1,98%;
• vantagem total: depende da fórmula completa, do cash-out e do truncamento.

Não se deve concluir automaticamente que a vantagem total é 1,98%. O achado demonstra que o teste e o comentário sobre “1% de crashes instantâneos” não descrevem exatamente a saída visual.

9.5 Geração da seed

A função GenerateSeed() aloca 32 bytes e chama crypto/rand. A biblioteca é adequada para aleatoriedade criptográfica. Entretanto, o erro de rand.Read é ignorado.

Trecho reduzido:

b := make([]byte, 32)
rand.Read(b)

Em código financeiro, a falha da fonte de entropia deveria interromper a operação. Uma versão mais robusta trataria o erro:

if _, err := rand.Read(b); err != nil {
    return "", err
}

Este exemplo é uma recomendação de engenharia defensiva, não instrução de operação do cassino.

9.6 Ordem temporal da rodada

O método runRound() executa, em essência:

1. incrementa o nonce;
2. gera server seed;
3. calcula o compromisso;
4. gera client seed;
5. calcula o crash point;
6. cria o estado;
7. grava no Redis;
8. publica o compromisso;
9. abre apostas por cinco segundos;
10. inicia animação;
11. revela a seed no crash.

Portanto, o servidor conhece o resultado antes de abrir as apostas.

Essa ordem pode ser legítima em protocolo commit-reveal. O objetivo do compromisso é impedir mudança depois que as apostas forem conhecidas. Entretanto, a qualidade da prova depende de como as entradas foram escolhidas.

9.7 A “client seed” é gerada pelo servidor

O código contém:

clientSeed := GenerateSeed()

e o comentário:

// In production, aggregate from player inputs

Esse comentário é uma admissão arquitetural relevante. A implementação pública ainda não agrega contribuições de jogadores. O servidor controla:

• server seed;
• client seed;
• nonce em memória;
• momento do compromisso;
• abertura da rodada.

Chamar a variável de client seed não cria independência. O que importa é a origem.

9.8 Seed grinding como possibilidade

Imagine que um operador deseje uma queda abaixo de 1,20x. Se controla todas as entradas, pode gerar pares até encontrar um resultado nessa faixa. Depois publica apenas o hash do par selecionado.

A verificação posterior confirmará:

• a seed revelada produz o hash;
• a seed e as demais entradas produzem o multiplicador.

Ela não revelará quantas seeds foram descartadas antes.

Não foi encontrado laço explícito de seed grinding no repositório. A conclusão correta é:

O protocolo público não impede que uma versão modificada faça seleção prévia de seeds, porque o servidor controla todas as entradas antes do compromisso.

A conclusão incorreta seria:

O projeto comprovadamente procura seeds até forçar derrotas.

A primeira é sustentada. A segunda não.

9.8.1 Como reduzir esse risco

Um protocolo mais robusto pode:

• publicar previamente cadeia de hashes de server seeds;
• permitir client seed escolhida pelo jogador;
• agregar contribuições assinadas de participantes;
• utilizar um beacon público posterior ao compromisso;
• registrar compromisso em serviço independente;
• manter sequência auditável sem lacunas;
• submeter fórmula e versão à certificação.

Nenhum mecanismo isolado elimina confiança. A meta é reduzir a capacidade unilateral.

9.9 Resultado visual pré-calculado

O multiplicador exibido durante a corrida é calculado pelo tempo:

mult := 1.0 + (elapsed / 1.5) + (elapsed * elapsed * 0.005)

O crash point já existe. A função visual aumenta até alcançar esse limite.

Consequência:

• o avião não “decide” cair devido a evento físico;
• o clique do jogador não influencia o ponto de queda;
• a animação é um relógio visual;
• o servidor já conhece o final.

Essa arquitetura deve ser explicada ao público sem dizer que o pré-cálculo é automaticamente fraude. O problema central é verificabilidade.

Uma analogia adequada é filme com final gravado. O espectador não sabe o final, mas o arquivo já o contém.

9.10 Prioridade do crash sobre auto-cashout

No loop, o código verifica primeiro:

if currentMult >= CrashMultiplier {
    // crash
}

Depois verifica auto-cashouts.

Se o multiplicador atual alcança simultaneamente o ponto de queda e o alvo automático, o crash vence. O jogador não recebe pagamento.

Essa regra pode ser válida, mas deve ser explicitada. Em sistemas de alta frequência, “chegar ao valor” e “ser processado antes do crash” não são equivalentes.

O requisito regulatório de implementação das regras conforme divulgadas torna essa fronteira importante. A interface não deve induzir a crença de que coincidência garante pagamento se o motor exige prioridade anterior.

9.11 Granularidade temporal

O loop usa intervalos de 100 milissegundos. O multiplicador não é uma linha contínua para processamento; ele é amostrado em ticks.

Consequências possíveis:

• vários valores são saltados;
• cash-out manual chega entre ticks;
• rede acrescenta atraso;
• fila acrescenta atraso;
• servidor processa em momento diferente da percepção visual.

Um sistema minimamente auditável deve definir qual referência realmente vale:

• horário de recebimento;
• horário de processamento;
• último multiplicador publicado;
• multiplicador autoritativo interno.

9.12 Cache das apostas ativas

Antes da fase de execução:

activeBets := m.loadActiveBets(roundID)

O mapa é carregado uma vez. Quando um auto-cashout é processado, o estado no Redis é alterado, mas a cópia em memória pode continuar com CashedOut = false.

Nos ticks seguintes, o sistema pode iniciar novas tentativas para a mesma aposta. Isso cria risco de concorrência.

A falha não demonstra dano deliberado ao apostador. Na realidade, poderia produzir crédito duplicado ou inconsistência. É evidência de inadequação para dinheiro real.

9.13 Atomicidade do cash-out

O fluxo é dividido:

1. lê aposta;
2. verifica CashedOut;
3. calcula pagamento;
4. incrementa saldo;
5. marca aposta como sacada.

Se duas operações concorrentes leem false antes da atualização, ambas podem creditar.

Em sistemas financeiros, deve existir transação atômica ou operação compare-and-set. Em Redis, alternativas incluem script Lua ou transação com vigilância de versão. A regra técnica é garantir que “verificar e marcar” seja uma única operação indivisível.

Não são apresentados passos de exploração. A análise se limita ao princípio de concorrência.

9.14 Vínculo entre usuário e aposta

O cash-out recebe UserID e BetID. O código busca a aposta, mas não verifica explicitamente:

bet.UserID == req.UserID

O saldo creditado é construído com req.UserID.

Esse é um defeito de autorização. Identidade declarada pelo cliente não deve substituir a identidade autenticada e o proprietário registrado.

9.15 Exposição de identificadores

O evento bet_placed transmite identificador de aposta. Em si, publicar identificadores pode ser necessário para interface multiplayer. O risco surge quando o backend não valida propriedade.

Princípio:

Identificador não é segredo nem autorização.

Mesmo identificadores imprevisíveis devem ser protegidos por checagem de dono.

9.16 Ausência de autenticação robusta

Os handlers aceitam user_id no corpo. No WebSocket, o identificador vem da query string e o padrão é anonymous.

As rotas mostradas não aplicam middleware de autenticação. A própria documentação do projeto reconhece caráter não produtivo.

Em dinheiro real seriam necessários:

• sessão ou token;
• validação criptográfica;
• autorização por recurso;
• prevenção de replay;
• rate limit;
• trilha de auditoria;
• segregação de rotas administrativas.

9.16.1 Alteração de saldo por rota

O projeto expõe uma rota para definir saldo do usuário. Em ambiente de demonstração, isso facilita testes. Em produção sem autenticação, seria crítico.

Este achado reforça a classificação do repositório como protótipo. Não se deve tratá-lo como cassino seguro pronto para uso.

9.17 Timeout e ambiguidade

O cash-out aguarda resposta por 500 ms. Se o tempo excede, retorna “Cashout timeout”. Contudo, a solicitação já pode ter entrado na fila e ser processada depois.

Isso cria resposta ambígua:

• cliente acredita que falhou;
• servidor pode creditar;
• cliente tenta novamente;
• logs divergem.

Operações financeiras devem possuir idempotency key e estado consultável.

Round ID ignorado. As estruturas contêm RoundID, mas o fluxo central utiliza a rodada atual. Em transição, uma solicitação atrasada pode ser interpretada no contexto errado.

A defesa requer validar:

• rodada declarada;
• rodada atual;
• aposta vinculada;
• status;
• timestamps.

9.18 Persistência e histórico

A rodada é gravada no Redis com expiração de uma hora. Redis é útil para estado rápido, mas não substitui livro de auditoria.

Um histórico robusto deveria guardar permanentemente:

• compromisso;
• seeds reveladas;
• client seed;
• nonce;
• multiplicador;
• horários;
• apostas;
• cash-outs;
• versão do motor;
• assinatura;
• resultado da verificação.

O projeto declara PostgreSQL, mas o fluxo de Crash examinado não demonstra um ledger completo.

9.19 Endpoint de verificação

O material do projeto menciona verificação, e existe função interna VerifyRound. Entretanto, as rotas registradas mostram:

• estado;
• aposta;
• cash-out;
• saldo;
• Mines;
• Plinko;
• Dice.

Não aparece rota pública para verificar Crash no arquivo analisado.

A existência de função interna não garante acessibilidade ao jogador.

9.19.1 Nonce em memória

O nonce começa em zero quando o Manager é criado. Reiniciar o processo reinicia a sequência.

Isso não necessariamente repete resultado, pois seeds mudam, mas dificulta história global. Uma auditoria deve associar nonce a cadeia ou sessão de seed, não apenas a processo.

9.20 Escala horizontal

O projeto possui constante de lock de rodada, mas o gerenciador examinado não a utiliza. Cada instância pode iniciar seu próprio loop, manter nonce e estado.

Em múltiplas instâncias, sem eleição de líder, podem surgir:

• rodadas concorrentes;
• compromissos diferentes;
• eventos divergentes;
• cash-outs processados por instância errada.

Alegações de escalabilidade devem ser testadas no motor, não inferidas do uso de Redis.

9.21 Testes

Os testes cobrem:

• limite mínimo e máximo;
• determinismo;
• diferença entre nonces;
• tamanho de seed;
• compromisso;
• verificação básica;
• benchmark.

O teste da house edge conta 1,00x em mil amostras e admite 0,5% a 2%. Se sair da faixa, apenas registra log. O teste não falha.

Problemas:

• amostra pequena para garantia regulatória;
• faixa inclui o efeito de truncamento;
• ausência de teste estatístico formal;
• ausência de teste de distribuição;
• ausência de teste de concorrência;
• ausência de teste de autenticação;
• ausência de teste de seleção de seed;
• ausência de teste de histórico.

“Comprehensive tests” em README não deve ser aceito sem matriz de cobertura.

9.21.1 Ausência de manipulação direta encontrada

Não foram encontrados, no fluxo público examinado:

• force_loss por usuário;
• force_win;
• ajuste pelo saldo da casa;
• ajuste por depósito;
• blacklist de ganhador;
• redução após saque;
• resultado manual;
• perfil de RTP por conta.

Essa ausência precisa ser declarada para preservar a honestidade da análise.

9.22 Manipulabilidade comprovada

Mesmo sem lógica direta, há controle unilateral sobre as entradas e ausência de prova independente. A classificação é:

9.23 Conclusão do caso

O aviator-fun é valioso como laboratório. Ele mostra como HMAC e compromisso podem ser implementados, mas também como “provably fair” pode ser incompleto.

Conclusão precisa:

A versão pública produz resultados determinísticos por HMAC e não contém evidência explícita de resultado forçado por usuário. Contudo, o servidor controla todas as entradas, conhece o resultado antes das apostas e não oferece garantias suficientes contra seleção prévia, descarte ou divergência entre versão publicada e executada.

9.24 Matriz detalhada do aviator-fun

Resultado pré-calculado. Arquivo: internal/game/manager.go
Evidência: crash point calculado antes de BETTING_TIME.
Certeza: 5/5.
Impacto: servidor conhece resultado.
Não prova: seleção maliciosa.

Controle das duas seeds. Evidência: duas chamadas de GenerateSeed().
Certeza: 5/5.
Impacto: client seed não independente.
Risco: seed grinding teórico.

Compromisso. Evidência: SHA-256 da server seed publicado.
Certeza: 5/5.
Benefício: impede troca posterior.
Limite: não impede seleção anterior.

Ausência de verificação pública. Evidência: rotas registradas não incluem verify.
Certeza: 4/5.
Limite: outra rota pode existir fora dos arquivos examinados, mas não foi encontrada.

Cash-out não atômico. Evidência: leitura, crédito e marcação separados.
Certeza: 5/5.
Impacto: risco de corrida.

Propriedade. Evidência: saldo usa req.UserID, sem comparação visível com aposta.
Certeza: 5/5.
Impacto: autorização inadequada.

Autenticação. Evidência: ID vem do corpo/query.
Certeza: 4/5.
Limite: middleware global não analisado poderia existir; nas rotas examinadas não aparece.

Timeout. Evidência: resposta em 500 ms.
Certeza: 5/5.
Impacto: estado ambíguo.

Teste estatístico. Evidência: fora da faixa gera log, não falha.
Certeza: 5/5.
Impacto: teste não garante house edge.

9.25 Manipulação direta

Evidência: não encontrada.
Certeza: limitada à versão pública.
Conclusão: não alegar.

O segundo repositório muda o foco. Em vez de um protocolo criptográfico de Crash, encontramos uma plataforma PHP com painel, dificuldade, mensagens, comissões, saldo e fluxo de saque.

10 Por dentro do subway-pay: dificuldade, mensagens e saques

10.1 Visão geral

O subway-pay é um projeto em PHP com banco SQL, painel, saldo, apostas, ganhos, perdas, afiliados e saque. O README o apresenta como sistema de iGaming e afirma funcionamento amplo. O material público inclui contato comercial do autor, mas telefone e e-mail não são reproduzidos porque não ajudam a compreender o código e exporiam dados desnecessários.

A auditoria concentra-se em:

• dificuldade;
• linguagem promocional;
• campos do banco;
• mensagens após resultado;
• comissões;
• fluxo de saque.

10.2 Dificuldade controlada pelo operador

O banco contém dificuldade_jogo. O painel lê a configuração. Isso comprova que existe parâmetro de dificuldade fora da escolha do jogador.

O ponto crítico não é a existência de níveis, comum em jogos. É a combinação:

• operador seleciona;
• jogador não necessariamente vê;
• dinheiro está envolvido;
• marketing sugere controle pessoal.

Em jogo de habilidade recreativo, escolher dificuldade é recurso normal. Em jogo com aposta, dificuldade oculta pode alterar expectativa.

10.3 Marketing de habilidade

A interface contém mensagem no sentido de que “não existe sorte”, bastando foco e desvio. Tal texto transfere responsabilidade ao jogador.

Se o resultado depende de dificuldade configurada, obstáculos aleatórios ou lógica oculta, a promessa é incompleta. Mesmo que habilidade exista, a experiência não é determinada apenas por foco.

A comunicação pode produzir:

• ilusão de controle;
• culpa pela perda;
• confiança em treino;
• repetição;
• percepção de que recuperação depende de persistência.

10.3.1 Meta de ganho

A interface menciona meta de ganho de dez vezes o valor apostado. Uma meta fixa pode funcionar como objetivo visual, mas é necessário saber:

• probabilidade de alcançar;
• dificuldade;
• distribuição;
• limite;
• custo esperado.

Sem isso, o “10x” é promessa visual sem contexto matemático.

10.4 Esquema do banco

O SQL contém campos como:

• dificuldade_jogo;
• rollover_saque;
• taxa_saque;
• revenue_share;
• chance_afiliado;
• revenue_share_falso;
• cpafake;
• comissaofake;
• percas;
• ganhos.

Nomes de coluna não provam comportamento. Porém, nomes como revenue_share_falso, cpafake e comissaofake são sinais de que o projeto modela valores simulados.

A auditoria deve seguir onde cada campo é utilizado. Na falta de rastreamento completo, a conclusão fica restrita:

O esquema foi projetado para armazenar métricas reais e classificadas como falsas, o que exige investigação do uso na interface e nos relatórios.

10.5 Revenue share

revenue_share representa participação na receita. Em afiliados de cassino, a base frequentemente se aproxima da perda líquida do grupo indicado, com ajustes contratuais.

Exemplo hipotético:

• indicados apostam R$ 100.000;
• recebem R$ 80.000;
• receita bruta: R$ 20.000;
• comissão: 30%;
• afiliado recebe R$ 6.000.

Não se deve dizer que todo afiliado recebe 30%. Modelos incluem:

• pagamento por cadastro;
• pagamento por primeiro depósito;
• híbrido;
• valor fixo;
• participação na receita;
• patrocínio.

O conflito existe quando o ganho do divulgador cresce com a perda do público.

10.6 Mensagem após derrota

A página de derrota comunica:

• perda;
• pedido para não desanimar;
• persistência como chave;
• convite para tentar novamente.

Em um evento de expectativa negativa, insistência não melhora a matemática. A mensagem pode estimular perseguição de perdas.

É um exemplo de design persuasivo, não de manipulação do resultado.

10.7 Mensagem após vitória

A página de vitória incentiva continuar jogando para “continuar faturando” e sacar.

Isso transforma vitória em argumento para nova exposição. O comportamento racional para preservar ganho seria encerrar, mas a interface orienta continuidade.

A combinação cria ciclo:

• perdeu: persista;
• ganhou: continue;
• em ambos: aposte de novo.

10.8 Fluxo de saque

O arquivo saque/saque.php contém condição externa equivalente a:

if ($saldo >= $valor && $valor > 0) {
    // processa solicitação
}

Dentro dela, o bloco de pagamento automático usa:

if ($valor <= 0) {
    // chamada de pagamento
}

As condições são incompatíveis. Para entrar no primeiro bloco, o valor é positivo. Logo, não pode satisfazer o segundo.

O fluxo positivo:

1. valida saldo e valor;
2. desconta saldo;
3. registra saque;
4. marca como processando;
5. não alcança pagamento automático;
6. exibe mensagem de sucesso.

10.9 Interpretações possíveis

Há três hipóteses:

1. bug acidental;
2. pagamento destinado a ser manual;
3. lógica incompleta.

O código não permite provar intenção de não pagar. Permite provar que o caminho automático mostrado é inalcançável para valor positivo.

A comunicação “saque realizado com sucesso” é, no mínimo, imprecisa se o valor está apenas processando.

10.10 Rollover e taxa

O banco possui rollover_saque e taxa_saque. Essas regras podem ser legítimas se transparentes, mas aumentam fricção.

Rollover exige volume antes de retirada. Exemplo: bônus de R$ 100 com rollover 10x exige R$ 1.000 em apostas.

Com house edge de 4%, perda esperada no volume é:

A exigência transforma bônus em obrigação de exposição.

10.10.1 Afiliados e valores simulados

A presença de chance_afiliado sugere lógica probabilística ou condicional relacionada a afiliado. Sem traçar o uso, não se deve afirmar função exata.

A metodologia correta é:

• localizar leitura do campo;
• identificar condição;
• verificar atualização;
• verificar exibição;
• reproduzir em ambiente isolado.

10.10.2 Resultado do jogo

O material examinado demonstra rotas de vitória e derrota e dificuldade configurável. Não foi encontrada, de forma inequívoca, uma função pública que marque usuário específico para perder.

A conclusão é:

• dificuldade controlável: confirmada;
• mensagens de repetição: confirmadas;
• campos simulados: confirmados no esquema;
• saque automático positivo: logicamente inalcançável;
• manipulação individual de toda rodada: não demonstrada.

Contradição entre discurso e sistema. A plataforma apresenta habilidade e foco como centrais, mas mantém dificuldade no banco. Isso é uma assimetria de informação.

O jogador pode atribuir perda a si mesmo, quando o operador controla parte das condições.

10.11 Classificação do caso

10.11.1 Conclusão do caso

O subway-pay demonstra como um clone pode reunir jogo, painel, afiliados, mensagens e saldo sem as garantias esperadas de um sistema financeiro. O achado mais forte sobre jogabilidade é a dificuldade controlada pelo operador. O achado mais forte sobre integridade operacional é a contradição no saque.

Não é possível concluir que toda partida seja programada para perda. É possível concluir que o jogador não possui meios de auditar as condições e que o operador possui superfícies de controle invisíveis.

10.12 Matriz detalhada do subway-pay

Dificuldade. Evidência: dificuldade_jogo no banco e painel.
Certeza: 5/5.
Impacto: operador controla condição.

Linguagem de foco. Evidência: texto promocional.
Certeza: 5/5.
Impacto: ilusão de controle.

Mensagem de derrota. Evidência: persistência após perda.
Certeza: 5/5.
Impacto: incentivo a chasing.

Mensagem de vitória. Evidência: continuar para faturar e sacar.
Certeza: 5/5.
Impacto: retenção.

Campos fake. Evidência: esquema SQL.
Certeza: 5/5 para existência.
Certeza de uso: menor, sem rastreamento.

Saque. Evidência: condição positiva e interna não positiva.
Certeza: 5/5.
Impacto: pagamento automático não executa nesse caminho.

Manipulação de resultado. Evidência: não conclusiva.
Conclusão: dificuldade sim; derrota individual não provada.

11 O que os outros clones acrescentam à análise

11.1 tanh1c/stake-originals-clone

O repositório se apresenta como clone educacional de jogos originais, com React e conceitos de seed. O próprio material declara finalidade de aprendizagem e ausência de dinheiro real.

Ele é útil para:

• visualizar determinismo;
• entender nonce;
• demonstrar fórmula;
• mostrar interface.

Ele não é prova sobre plataforma comercial.

Uma demo em frontend pode exibir verificação, mas o operador real precisa separar segredo, compromisso e revelação. Se tudo ocorre no navegador, a garantia é apenas didática.

11.2 akashmahlaz/aviator-crash

O README anuncia stack completa, multiplayer e provably fair. A árvore pública observada concentra frontend e não permite confirmar todas as promessas.

Esse caso ensina:

• README não é evidência;
• screenshot não é motor;
• interface não prova backend;
• “completo” pode significar apenas visual.

A classificação adequada é “evidência insuficiente”, não “fraude comprovada”.

11.2.1 Clones e atribuição

Clones podem:

• copiar arte;
• copiar fluxo;
• inventar motor;
• omitir servidor;
• vender módulos privados;
• alterar probabilidades.

Logo, analisar clone prova o que aquele clone faz. Para atribuir à marca original, seria necessário:

• código da marca;
• certificado;
• logs;
• perícia de rede;
• versão identificada;
• documentos internos.

O que ainda podemos aprender com clones. Apesar da limitação, eles revelam:

• padrões de arquitetura;
• linguagem de marketing;
• facilidade de implementar controles;
• fragilidade de protótipos;
• circulação de sistemas prontos;
• diferença entre aparência e integridade.

12 O quadro completo dos achados

Antes de avançar para comportamento, regulação e ética, vale colocar os dois casos lado a lado. A tabela abaixo não é um placar de “fraude” ou “honestidade”. Cada linha responde a uma pergunta diferente: existe vantagem matemática explícita? Quem controla as entradas aleatórias? Há compromisso criptográfico? O dinheiro é movimentado de forma atômica? O usuário consegue verificar o que ocorreu?

Leia “sim” como uma característica confirmada naquele código público e “não demonstrado” como ausência de evidência suficiente — não como prova de que o comportamento jamais exista em outra versão.

O contraste é importante. No aviator-fun, encontramos uma fórmula clara e um compromisso criptográfico real, mas o próprio servidor controla as duas seeds, conhece o resultado antecipadamente e não entrega verificação pública suficiente. No subway-pay, a fragilidade aparece de outra forma: dificuldade administrativa, campos de simulação, comunicação persuasiva e um caminho de saque incoerente.

Em nenhum dos dois casos foi encontrada prova de derrota individual forçada para cada usuário. O que a comparação demonstra é uma combinação de vantagem matemática, poder administrativo e baixa capacidade de auditoria externa. Essa distinção orienta toda a linguagem usada a seguir.

13 A fronteira entre evidência, inferência e acusação

Prova. O código pode provar:

• existência de parâmetro;
• ordem de execução;
• fórmula;
• ausência de validação naquele trecho;
• mensagem exibida;
• condição impossível;
• origem da seed;
• momento do cálculo.

Não prova. O código público não prova:

• configuração usada em servidor comercial;
• intenção psicológica do autor;
• volume real de perdas;
• contrato de todo influenciador;
• fraude de marca específica;
• que todas as rodadas foram manipuladas;
• que ninguém recebeu saque.

Essa limitação é especialmente importante quando a conversa chega às grandes plataformas. Sem acesso ao motor executado em produção, às seeds, aos parâmetros ativos, ao histórico de versões e aos logs completos, não há base técnica para declarar que uma empresa específica força derrotas, altera resultados por usuário ou usa o mesmo código dos clones. Certificação e documentos públicos podem ser analisados por seus próprios méritos, mas não substituem acesso ao sistema interno.

Inferência permitida. A inferência deve ser explícita:

Como o servidor controla ambas as seeds, infere-se que uma versão modificada poderia selecionar resultados antes do compromisso. Não foi encontrado código que faça essa seleção na versão examinada.

Linguagem inadequada. Evitar:

• “provei que o Aviator é fraude”;
• “todo Tigrinho rouba”;
• “a plataforma escolhe sempre sua derrota”;
• “nenhum jogo usa sorte”.

Linguagem adequada. Preferir:

• “o clone analisado calcula o resultado antes”;
• “o protocolo não impede seleção prévia”;
• “a dificuldade é controlável pelo operador”;
• “não há prova pública suficiente para auditoria”;
• “a house edge produz expectativa negativa”.

13.1 Os trechos de código essenciais, reunidos e comentados

House edge. Fonte: nutcas3/aviator-fun, internal/game/provably_fair.go.

const HOUSE_EDGE = 0.01

Interpretação: margem teórica de 1% aplicada pela fórmula. Não significa perda de 1% em cada rodada.

Crash instantâneo

if rFloat < HOUSE_EDGE {
    return MIN_MULTIPLIER
}

Interpretação: faixa inicial produz 1,00x.

Seeds. Fonte: internal/game/manager.go.

serverSeed := GenerateSeed()
clientSeed := GenerateSeed()

Interpretação: ambas vêm do servidor. A variável “client” não é contribuição independente.

Pré-cálculo

crashPoint := HashAndMapToMultiplier(
    serverSeed,
    clientSeed,
    m.nonce,
)

Esse cálculo ocorre antes da janela de aposta.

Cash-out. Fluxo conceitual observado:

read bet
check cashed_out
credit balance
mark cashed_out

Interpretação: sequência não atômica.

13.2 Saque no subway-pay

Fonte: saque/saque.php.

if ($valor > 0) {
    // ...
    if ($valor <= 0) {
        // pagamento
    }
}

Interpretação: bloco interno não é alcançado para valor positivo.

Código e matemática explicam como o resultado e o dinheiro circulam. A interface explica por que tanta gente continua clicando mesmo depois de compreender o risco.

14 A interface também faz parte do sistema de apostas

14.1 O resultado matemático não é o único produto

Uma plataforma de apostas não vende apenas a possibilidade de prêmio. Ela vende uma sequência de sensações: antecipação, quase acerto, controle, urgência, recuperação, pertencimento e confirmação social. O motor matemático decide pagamentos; o design decide como o usuário interpreta a experiência.

A literatura sobre características estruturais do jogo investiga como velocidade, som, modalidade de aposta, disponibilidade contínua e feedback influenciam comportamento. Auer e Griffiths, em estudo com rastreamento de jogadores on-line, destacam que características do produto se relacionam com intensidade e comportamento de jogo. Newall discute características estruturais de plataformas on-line e a necessidade de avaliar não somente o jogo individual, mas a arquitetura que conecta produtos, promoções e navegação.

14.2 Ciclo rápido

Quanto menor o tempo entre aposta e resultado, maior o número possível de decisões por minuto. Se um jogo dura cinco segundos, um usuário pode realizar centenas de rodadas em uma sessão.

A vantagem da casa atua sobre volume. A velocidade aumenta o volume.

Exemplo:

• aposta média: R$ 2;
• 12 rodadas por minuto;
• 30 minutos;
• volume: R$ 720.

Com vantagem de 4%:

A perda real pode diferir, mas a velocidade cria exposição.

14.3 Animação e antecipação

No Crash, o multiplicador subindo transforma um número pré-calculado em narrativa. O jogador decide quando sair. Essa decisão gera sensação de habilidade.

A tensão possui duas camadas:

• incerteza do resultado;
• responsabilidade pelo clique.

Se o crash ocorre logo depois do saque, surge confirmação de habilidade. Se ocorre antes, surge arrependimento e desejo de tentar novamente.

14.4 Quase acerto

Near miss é resultado visualmente próximo do prêmio. Em slot, dois símbolos e o terceiro acima da linha. Em Mines, uma casa antes da bomba. Em Plinko, bola próxima do maior multiplicador.

Matematicamente, quase acerto é perda. Psicologicamente, pode ser percebido como progresso.

Não foi realizada análise completa de near miss nos códigos principais, mas a categoria é relevante para futuras auditorias.

14.4.1 Perda disfarçada de vitória

Imagine aposta de R$ 10 e retorno de R$ 4. O saldo diminuiu R$ 6. Se a interface toca música, lança moedas e escreve “você ganhou R$ 4”, a perda é apresentada como vitória.

Checklist:

• o valor apostado aparece ao lado do prêmio?
• o lucro líquido é informado?
• sons distinguem lucro de retorno parcial?
• perdas líquidas recebem celebração?

Persistência depois da perda. No subway-pay, a mensagem após derrota associa persistência a sucesso. Em um jogo de expectativa negativa, insistência não altera vantagem.

Isso pode reforçar chasing, perseguição de perdas: o usuário aposta mais para recuperar.

Persistência depois da vitória. A mensagem de vitória incentiva continuar. O sistema possui resposta para ambos os estados:

• perda justifica nova tentativa;
• vitória justifica aproveitar a fase.

O design fecha a saída.

14.4.2 Saldo como abstração

Fichas, créditos e moedas reduzem saliência do dinheiro. Quando R$ 100 se transforma em 10.000 moedas, o usuário pode perder referência.

Auditoria deve verificar:

• unidade padrão;
• conversão visível;
• saldo em reais;
• confirmação de valor;
• histórico de depósito;
• total apostado.

Auto-play e velocidade. Recursos automáticos removem pausas naturais. Reguladores frequentemente restringem autoplay ou exigem controles.

Mesmo sem autoplay explícito, botão “apostar novamente” reduz fricção.

14.5 Prova social

Contadores, vencedores e apostas em tempo real criam impressão de normalidade.

A prova social pode ser legítima, se derivada de eventos reais. Torna-se enganosa quando:

• números são aleatórios;
• usuários são bots não identificados;
• valores são simulados;
• vencedores são fictícios;
• o modo demo é apresentado como real.

O esquema do subway-pay com campos fake exige atenção. Não basta encontrar campo; é necessário observar exibição.

14.6 Dark patterns

Mathur e colaboradores definiram dark patterns como escolhas de interface que direcionam usuários a decisões que talvez não tomassem. Em aposta, exemplos potenciais incluem:

• botão de depósito destacado e saque escondido;
• bônus com rollover em texto pequeno;
• cancelamento difícil;
• urgência artificial;
• saldo promocional misturado ao sacável;
• mensagem de sucesso antes da liquidação;
• consentimento pré-selecionado;
• retorno automático ao jogo.

Nem todo design persuasivo é ilegal. A análise ética considera assimetria, vulnerabilidade e transparência.

14.6.1 Personalização

Plataformas podem personalizar promoções com base em comportamento. Uma arquitetura responsável deve evitar usar sinais de risco para aumentar aposta.

Perguntas para auditoria:

• o usuário que perde recebe bônus?
• o limite é aumentado após perda?
• notificações ocorrem após inatividade?
• a mensagem promete recuperação?
• existe exclusão de público vulnerável?

14.6.2 Modo demonstração

Demos podem usar saldo fictício. O risco surge se:

• RTP é diferente;
• frequência de vitória é maior;
• transição para dinheiro real não é clara;
• saldo demo parece sacável;
• influenciador usa conta promocional.

Uma auditoria exige comparar motor demo e real.

15 Quando quem recomenda também ganha com a perda

15.1 Modelos de remuneração

Programas de afiliados podem pagar por:

• clique;
• cadastro;
• primeiro depósito;
• apostador qualificado;
• valor fixo;
• híbrido;
• participação na receita.

Nem todo contrato está ligado diretamente à perda. Por isso, a comunicação pública deve dizer “alguns contratos” ou “em modelos de revenue share”.

15.2 Gross Gaming Revenue

GGR é normalmente:

GGR não é o total depositado e também não é necessariamente o lucro líquido final da empresa. Ele mede quanto ficou com a operação depois de subtrair os prêmios do volume apostado, antes de vários custos e ajustes. Essa diferença importa porque alguns contratos de afiliados usam justamente essa receita como base.

Se jogadores apostam R$ 1 milhão e recebem R$ 850 mil:

Com participação de 30%:

Nesse exemplo, o afiliado receberia R$ 45 mil porque sua participação corresponde a 30% dos R$ 150 mil que permaneceram como GGR. Na prática, o contrato pode descontar bônus, taxas, chargebacks e saldo negativo. O ponto ético permanece: quando a remuneração cresce junto com a receita líquida produzida pelos indicados, existe um incentivo econômico diferente de uma publicidade paga por valor fixo.

Conflito de interesse. Quando a remuneração cresce com GGR, o divulgador possui incentivo para:

• trazer usuários;
• aumentar depósitos;
• manter atividade;
• reduzir saídas;
• normalizar perdas.

A frase “eu quero que você ganhe” entra em tensão com o contrato.

15.3 Não generalização

Não se deve afirmar:

Todo influenciador ganha 30% da perda.

Formulação correta:

Em contratos de participação na receita, o afiliado pode receber porcentagem da receita líquida gerada pelos indicados; a base está relacionada à diferença entre apostas e prêmios.

Times e instituições. Patrocínio esportivo pode ser fixo e não depender de perda individual. Mesmo assim, a marca recebe legitimidade.

Perguntas éticas:

• público inclui menores?
• campanha sugere renda?
• ídolos aparecem jogando?
• risco é mencionado?
• canal de ajuda é visível?
• instituição conhece modelo?

15.3.1 Transparência publicitária

A Portaria SPA/MF nº 1.231/2024 disciplina comunicação, publicidade e marketing no mercado regulado. A norma atribui responsabilidade ao operador por ações de afiliados em determinadas condições e exige comunicação responsável.

Uma postagem deve informar publicidade. Mostrar apenas vitória pode ser enganoso se omite relação comercial.

15.3.2 Conta de influenciador

Algumas campanhas podem usar saldos promocionais, cashback, limites diferenciados ou contratos de risco. Sem documentação, não se deve afirmar.

O público deve perguntar:

• o dinheiro é próprio?
• o saldo é sacável?
• há reembolso?
• há comissão?
• a conta tem regras diferentes?
• as perdas são cobertas?

“Sinais” e horários. Grupos prometem sinais, padrões e horários. Em RNG independente, histórico não prevê próxima rodada.

Quando o operador controla parâmetros, o sinal também não oferece garantia; o sinalizador não conhece necessariamente o backend.

Responsabilidade moral. Quem lucra indicando produto de expectativa negativa deve avaliar:

• verdade da promessa;
• vulnerabilidade;
• proporcionalidade;
• destino do dinheiro;
• dano previsível;
• conflito de interesse.

16 O tamanho do fenômeno no Brasil — sem misturar métricas

16.1 Estudo do Banco Central de 2024

O estudo especial do Banco Central analisou transferências Pix para empresas identificadas. Principais estimativas:

• R$ 18 bilhões a R$ 21 bilhões mensais em transferências brutas;
• aproximadamente 15% retidos pelas empresas;
• cerca de 24 milhões de pessoas;
• R$ 3 bilhões enviados em agosto de 2024 por aproximadamente 5 milhões de pessoas de famílias beneficiárias do Bolsa Família.

Cuidados:

• transferência bruta não é perda líquida;
• o dinheiro pode circular;
• identificação de empresas é imperfeita;
• o estudo é preliminar;
• não separa Tigrinho, Aviator ou marca;
• não mede toda operação por outros meios.

16.2 Anualização

Multiplicar R$ 18–21 bilhões por doze produz R$ 216–252 bilhões de fluxo anualizado. Essa conta é projeção, não total oficial fechado.

Aplicar 15% produz R$ 32,4–37,8 bilhões de retenção anualizada. Novamente, é cálculo derivado, não número oficial publicado como perda anual.

Ao comunicar esse achado publicamente, a formulação precisa ser:

Se a faixa mensal fosse mantida por doze meses, a anualização seria...

Mercado regulado em 2025. A SPA informou 17,7 milhões de brasileiros no primeiro semestre de 2025. O mercado federal regulado começou sob nova estrutura.

A apresentação oficial deve ser interpretada no universo dos operadores autorizados e dados reportados ao SIGAP.

16.3 TCU

O Tribunal de Contas da União publicou levantamento sobre efeitos das apostas. O relatório compila estimativas de diversas instituições.

Quando citar um número do TCU originado em estudo privado, é preciso dizer:

O TCU registrou estimativa de...

Não transformar citação secundária em medição própria.

DataSenado. Pesquisa do DataSenado estimou mais de 22 milhões de pessoas que haviam apostado no período investigado em 2024. Pesquisas de declaração medem comportamento diferente de transações.

Por que números divergem. Fontes podem medir:

• pessoas em um mês;
• pessoas em oito meses;
• usuários de operadores regulados;
• transferências Pix;
• apostas esportivas;
• jogos on-line;
• depósitos;
• volume apostado;
• GGR;
• perda líquida;
• declaração em pesquisa.

Comparações devem alinhar definição.

GGR, NGR e faturamento. Não usar “faturamento” sem definir.

• turnover: total apostado;
• payout: prêmios;
• GGR: apostas menos prêmios;
• NGR: GGR menos ajustes;
• depósitos: entradas de dinheiro;
• saques: saídas;
• perda líquida: depósito menos saque, com ajustes.

16.3.1 Impacto em renda essencial

O dado sobre famílias do Bolsa Família gerou preocupação. A resposta regulatória evoluiu em 2025, com normas para impedir uso por beneficiários em certas condições.

A análise ética deve evitar estigmatizar famílias pobres. O foco é proteção contra desvio de renda essencial.

17 O que a regulação brasileira exige

17.1 Marco legal

A Lei nº 13.756/2018 introduziu apostas de quota fixa esportivas. A Lei nº 14.790/2023 ampliou o marco para jogos on-line e definiu regras.

Para operar federalmente, empresas precisam de autorização da SPA e domínio adequado.

17.2 Certificação

A Portaria SPA/MF nº 1.207/2024 estabelece requisitos técnicos para sistemas, jogos e estúdios ao vivo. Entidades certificadoras homologadas avaliam conformidade.

Certificação relevante inclui:

• RNG;
• matemática;
• regras;
• integração;
• segurança;
• versão;
• pagamentos;
• logs.

A página de questões técnicas da SPA esclarece que jogos precisam de certificação individual e que testes não se limitam a identificar RNG.

17.3 O rótulo regulatório de “jogo responsável”

A Portaria nº 1.231/2024 usa a expressão “jogo responsável” ao tratar de direitos, deveres, publicidade e marketing. É importante entender o alcance desse nome: ele descreve obrigações de redução de dano impostas ao operador, não uma garantia de que apostar se tornou uma atividade segura, equilibrada ou recomendável. Um limite de depósito pode conter parte do prejuízo; ele não remove a expectativa negativa. A autoexclusão pode interromper o acesso; ela não devolve o dinheiro perdido.

Dentro dessa categoria regulatória estão medidas como:

• informação;
• prevenção;
• autoexclusão;
• limites;
• proteção;
• vedação de mensagens enganosas.

A norma foi alterada posteriormente, inclusive para ampliar mecanismos de autoexclusão e restrições. Essas barreiras são necessárias porque o dano não é uma possibilidade abstrata: ele aparece em endividamento, perseguição de perdas, conflitos familiares e uso de renda essencial. Para o leitor, a conclusão deste artigo continua sendo mais simples e mais firme do que o eufemismo regulatório: a forma mais segura de não ser capturado pela vantagem da casa é não entrar no jogo.

Beneficiários de programas sociais. Em 2025, novas medidas foram adotadas para impedir uso de recursos de Bolsa Família e BPC em apostas. Esse desenvolvimento mostra que a regulação responde a dados de vulnerabilidade.

Fiscalização e bloqueio. A SPA atua com outros órgãos para bloquear sites ilegais. O número de domínios bloqueados cresceu rapidamente.

Bloqueio não garante desaparecimento: espelhos e novos domínios surgem.

17.3.1 Publicidade

A publicidade não deve:

• prometer enriquecimento;
• tratar aposta como investimento;
• sugerir solução financeira;
• dirigir-se a menores;
• omitir riscos;
• induzir falsa garantia.

Uma “bet gospel” deve ser examinada sob essas regras e sob possíveis implicações religiosas, sem presumir ilegalidade apenas pelo nome.

17.3.2 Certificação e painel

Se RTP ou regra certificada é alterada, a versão pode precisar de nova avaliação. Um painel que permite mudança livre sem controle de versão contraria a lógica de certificação.

Controles recomendados:

• acesso restrito;
• dupla aprovação;
• log imutável;
• motivo;
• versão;
• alerta;
• recertificação.

Limites da regulação. A existência de lei não garante conformidade. Certificação reduz risco, não substitui fiscalização contínua.

O público deve verificar autorização oficial, mas esta investigação não fornece guia de acesso a plataformas.

18 O que padrões internacionais esperam de um jogo auditável

18.1 UK Gambling Commission – RTS 7

O RTS 7 exige resultados aceitavelmente aleatórios. Entre os princípios:

• distribuição esperada;
• imprevisibilidade;
• ausência de correlação inadequada;
• proibição de comportamento adaptativo;
• regras conforme informação ao consumidor.

O documento rejeita intervenção automática ou manual que altere probabilidade durante o jogo, em contextos regulados.

Jogos compensados. A UKGC diferencia jogo aleatório e compensado. Em jogo compensado, probabilidade é ajustada com base em pagamentos ou arrecadação.

Em cassino on-line remoto, comportamento adaptativo é especialmente problemático porque quebra independência.

GLI-19. O padrão GLI-19 aborda sistemas interativos. Exige:

• RNG aprovado;
• independência;
• distribuição;
• segurança;
• logs;
• conta;
• transações;
• recuperação;
• revisão de código.

A auditoria de RNG não se resume a executar milhões de rodadas. Inclui fonte de entropia, mapeamento e uso.

NIST SP 800-90A. O NIST define geradores determinísticos criptográficos e requisitos. Aplicar biblioteca segura é melhor que Math.random(), mas a segurança do protocolo depende de:

• seed;
• entropia;
• tratamento de erro;
• proteção da chave;
• não reutilização;
• estado.

RFC 2104. HMAC é mecanismo de autenticação de mensagem. Usá-lo em provably fair é tecnicamente coerente, mas o RFC não afirma que uma seed escolhida pelo operador seja justa.

18.2 Estatística versus criptografia

Criptografia responde:

• dados foram alterados?
• resultado é reproduzível?
• segredo era imprevisível?

Estatística responde:

• distribuição corresponde?
• independência existe?
• frequência é compatível?
• viés apareceu?

Certificação precisa de ambas.

Auditoria contínua. Um jogo pode passar teste e depois mudar. São necessários:

• hash do binário;
• versionamento;
• monitoramento de RTP;
• alarmes de desvio;
• revisão de atualização;
• segregação de acesso.

18.3 O que políticas públicas poderiam exigir

Transparência de RTP. Mostrar RTP e volatilidade em linguagem simples.

Lucro líquido. Exibir retorno líquido, não apenas prêmio bruto.

Histórico consolidado. Mostrar:

• depósitos;
• saques;
• volume;
• resultado líquido;
• tempo.

Atraso deliberado. Introduzir pausa pode reduzir impulsividade.

Proibir prova social falsa. Contadores e vencedores devem ser auditáveis.

Identificar bots. Bots de demonstração devem ser marcados.

Afiliados. Divulgar modelo de remuneração.

Contas promocionais. Identificar saldos não próprios.

Painel. Toda alteração de RTP deve gerar log e recertificação.

Auditoria pública. Publicar resumo de certificado e versão.

Dados para investigação. Fornecer dados anonimizados para avaliar danos.

18.4 Educação

Ensinar diferença entre RTP e devolução individual.

Justiça não depende apenas do gerador aleatório. Se autenticação, autorização, saldo, cash-out e logs falham, o sistema financeiro também deixa de ser confiável.

19 Um jogo não pode ser justo se o dinheiro e os acessos não são íntegros

Por que segurança afeta justiça. Um motor matematicamente justo pode produzir injustiça se saldo for creditado incorretamente. Integridade abrange:

• resultado;
• aposta;
• cash-out;
• saldo;
• saque;
• registro;
• identidade.

Autenticação. Autenticação responde “quem é?”. Não aceitar user_id do corpo como verdade.

Autorização. Autorização responde “pode acessar esta aposta?”. Sempre comparar dono.

19.1 Atomicidade

A operação deve ocorrer por completo ou não ocorrer.

Para aposta:

1. validar rodada;
2. validar saldo;
3. debitar;
4. registrar.

Para cash-out:

1. validar dono;
2. validar não sacado;
3. marcar;
4. creditar.

Idempotência. Se cliente repete por timeout, resultado não deve duplicar. Uma chave identifica a operação.

Ledger. Saldo não deveria depender apenas de número mutável. Um ledger registra:

• débito;
• crédito;
• referência;
• versão;
• timestamp;
• assinatura.

Saldo é soma.

Logs imutáveis. Logs devem resistir a alteração pelo operador. Soluções:

• armazenamento WORM;
• assinatura;
• cadeia de hashes;
• replicação externa;
• timestamp.

Segregação de funções. Quem define configuração não deveria apagar log. Quem aprova saque não deveria alterar jogo. Segregação reduz abuso.

Monitoramento de RTP. RTP observado deve ser comparado ao teórico. Desvios podem indicar:

• bug;
• manipulação;
• amostra pequena;
• erro de integração;
• arredondamento.

Disponibilidade. Queda de servidor durante cash-out é risco financeiro. É necessário definir política de indisponibilidade.

19.2 Checklist prático para auditar outro jogo

Identificação

• [ ] Repositório e commit registrados
• [ ] Licença registrada
• [ ] Escopo definido
• [ ] Backend presente
• [ ] Motor localizado

Matemática

• [ ] House edge calculada
• [ ] RTP calculado
• [ ] Volatilidade descrita
• [ ] Arredondamento verificado
• [ ] Limites verificados
• [ ] Testes estatísticos avaliados

Aleatoriedade

• [ ] Fonte de entropia
• [ ] Erros tratados
• [ ] Seeds independentes
• [ ] Nonce persistente
• [ ] Mapeamento sem viés
• [ ] Resultado não descartado

Compromisso

• [ ] Hash antes da aposta
• [ ] Timestamp externo
• [ ] Revelação
• [ ] Verificador
• [ ] Histórico
• [ ] Versão da fórmula

Controle administrativo

• [ ] RTP alterável
• [ ] Win rate
• [ ] Dificuldade
• [ ] Resultado manual
• [ ] Perfil por usuário
• [ ] Log de mudança
• [ ] Aprovação

Financeiro

• [ ] Débito atômico
• [ ] Crédito atômico
• [ ] Idempotência
• [ ] Propriedade
• [ ] Saque
• [ ] Estado
• [ ] Mensagem coerente

Segurança

• [ ] Autenticação
• [ ] Autorização
• [ ] Rate limit
• [ ] Segredo
• [ ] Auditoria
• [ ] Escala
• [ ] Recuperação

Interface

• [ ] Lucro líquido
• [ ] Perda disfarçada
• [ ] Near miss
• [ ] Contador
• [ ] Bots
• [ ] Urgência
• [ ] Mensagens de chasing

Afiliados

• [ ] Modelo declarado
• [ ] Comissão
• [ ] Publicidade marcada
• [ ] Saldo promocional
• [ ] Conta diferenciada
• [ ] Conflito informado

Ficha reutilizável de auditoria

Identificação

• Repositório:
• Commit:
• Data:
• Linguagem:
• Licença:
• Autor:

Motor

• Arquivo:
• Função:
• Entrada:
• Saída:
• Fórmula:

Aleatoriedade

• Fonte:
• Seed:
• Erro:
• Nonce:
• Compromisso:

Controle

• Painel:
• Parâmetros:
• Logs:
• Usuário específico:

Financeiro

• Débito:
• Crédito:
• Saque:
• Atomicidade:

Interface

• Mensagem:
• Prova social:
• Continuidade:
• Transparência:

Conclusão

• Classe:
• Confiança:
• Limites:

19.3 Como classificar um achado técnico

Classe A — manipulação direta. Critérios:

• resultado forçado;
• usuário selecionado;
• painel define próximo resultado;
• probabilidade adaptativa.

Classe B — manipulabilidade. Critérios:

• servidor controla todas as seeds;
• RTP alterável;
• dificuldade oculta;
• ausência de log.

Classe C — não auditável. Critérios:

• motor fechado;
• sem seed;
• sem histórico;
• verificador interno.

Classe D — persuasão enganosa. Critérios:

• usuários simulados;
• vencedores falsos;
• mensagem incorreta;
• sucesso de saque antecipado.

Classe E — vantagem matemática. Critérios:

• expectativa negativa;
• house edge;
• odds com margem.

Uma plataforma pode ocupar várias classes.

19.4 Quem pode alterar o quê: um modelo de ameaças

19.5 Por que modelar ameaças

A auditoria tradicional procura erros. O modelo de ameaças pergunta quem possui capacidade, incentivo e oportunidade para explorar esses erros. Em jogos de aposta, diferentes agentes podem prejudicar a integridade:

• operador malicioso;
• administrador interno;
• desenvolvedor;
• fornecedor do jogo;
• afiliado;
• jogador fraudador;
• invasor externo;
• funcionário com acesso privilegiado;
• falha não intencional.

A mesma vulnerabilidade pode favorecer lados diferentes. A falta de vínculo entre usuário e aposta pode permitir fraude contra a plataforma. Uma condição impossível no saque pode prejudicar o jogador. Uma concorrência no cash-out pode creditar duas vezes. A integridade exige proteção bilateral.

Ativos. Os ativos são:

• saldo;
• aposta;
• resultado;
• seed;
• compromisso;
• histórico;
• identidade;
• configuração;
• certificado;
• log;
• reputação;
• dados pessoais.

Fronteiras de confiança. Principais fronteiras:

1. dispositivo para API;
2. API para motor;
3. motor para Redis;
4. motor para banco;
5. painel para configuração;
6. operador para certificadora;
7. afiliado para público;
8. jogo para carteira;
9. carteira para pagamento.

Cada fronteira deve autenticar e registrar.

Operador malicioso. Capacidades:

• alterar código;
• alterar configuração;
• descartar log;
• trocar versão;
• criar bot;
• controlar seed;
• selecionar resultado;
• atrasar saque.

Controles:

• certificação;
• assinatura de binário;
• segregação;
• log externo;
• fiscalização;
• reconciliação.

Administrador interno. Um administrador pode possuir credencial legítima. O risco não é invasão, mas abuso.

Controles:

• menor privilégio;
• dupla aprovação;
• MFA;
• revisão;
• alertas;
• gravação de sessão;
• impossibilidade de apagar log.

Fornecedor de jogo. A plataforma pode integrar jogo de terceiro. O operador recebe resultado e não conhece motor. A certificação deve cobrir fornecedor e versão.

Jogador malicioso. Pode tentar:

• modificar cliente;
• repetir requisição;
• falsificar user ID;
• explorar concorrência;
• manipular tempo.

O servidor deve ser autoritativo.

Afiliado. Pode:

• omitir comissão;
• prometer ganho;
• usar conta demo;
• editar vídeo;
• simular saque;
• direcionar vulneráveis.

Controles:

• contrato;
• monitoramento;
• responsabilidade do operador;
• identificação de publicidade.

Falha não intencional. Nem toda injustiça é intencional. Bugs de arredondamento, timezone, concorrência e cache podem alterar pagamento.

A intenção não muda o prejuízo. Sistemas financeiros exigem qualidade.

20 Como testar resultados sem cair em conclusões apressadas

Imagine que alguém acompanhe cem rodadas e veja vários crashes quase instantâneos. A sensação de perseguição é compreensível, mas a sequência, isoladamente, ainda não prova que o sistema escolheu aquela pessoa para perder. O erro oposto também existe: observar uma sequência visualmente “normal” e concluir que a plataforma é justa. Aleatoriedade produz agrupamentos, repetições e períodos estranhos; manipulação bem escondida também pode produzir números que parecem normais.

Por isso, uma auditoria precisa juntar duas lentes. O código-fonte revela a regra que foi escrita e os controles disponíveis ao operador. Os registros de muitas rodadas mostram como o sistema realmente se comportou. Uma lente sem a outra deixa um ponto cego: o código público pode não ser o código executado, enquanto uma amostra de resultados pode ser pequena demais para revelar desvios raros.

20.1 Amostragem

Vamos acompanhar um evento que, segundo a regra declarada, deveria ocorrer em 1% das rodadas — por exemplo, um resultado instantaneamente desfavorável. Em mil rodadas, a quantidade média esperada desse evento é calculada multiplicando o tamanho da amostra pela probabilidade:

Nessa expressão, X é a quantidade de vezes que o evento aparece, n é o total de rodadas observadas e p é a probabilidade declarada para cada rodada. O resultado 10 não é uma promessa de que toda sequência de mil rodadas conterá exatamente dez casos. É apenas o centro em torno do qual as contagens tendem a variar.

Para saber se observar 7, 12 ou 15 ocorrências seria estranho, precisamos medir o tamanho natural dessa oscilação. Quando cada rodada pode ser classificada como “o evento ocorreu” ou “não ocorreu”, usamos a variância binomial:

Substituindo n = 1000 e p = 0,01, chegamos a:

A variância está em uma escala quadrática e, sozinha, é pouco intuitiva. Tiramos sua raiz para obter o desvio-padrão, que volta à escala de “quantidade de ocorrências”:

Isso quer dizer que flutuações de alguns eventos para cima ou para baixo são normais. Encontrar 5 ocorrências em vez de 10 representa uma diferença de aproximadamente 1,6 desvio-padrão; encontrar 15 produz diferença semelhante na direção oposta. Nenhum dos dois resultados, sozinho, seria uma prova convincente de fraude. Também não provaria honestidade. A conclusão correta seria: mil rodadas ainda oferecem pouca resolução para um evento que ocorre apenas uma vez a cada cem, em média.

Com dez mil rodadas, a expectativa sobe para cem ocorrências. A incerteza proporcional diminui, mas não desaparece. É por isso que uma auditoria séria define o tamanho da amostra antes de olhar o resultado, preserva todas as rodadas e calcula um intervalo de confiança. Para proporções pequenas, métodos como Wilson ou o intervalo binomial exato costumam se comportar melhor do que a aproximação normal mais simples. O intervalo responde a uma pergunta concreta: quais probabilidades ainda são compatíveis com o que observamos, considerando o tamanho da amostra?

Antes de transformar os bits aleatórios em multiplicadores, também é preciso procurar sinais de que a fonte de números não se comporta como declarado. Cada teste enxerga um tipo diferente de defeito:

• frequência e qui-quadrado verificam se valores ou faixas aparecem nas proporções esperadas;
• Kolmogorov-Smirnov compara a distribuição acumulada observada com a distribuição teórica;
• teste de sequências, ou runs test, procura blocos longos demais e alternâncias incomuns;
• autocorrelação investiga se um resultado carrega informação sobre os próximos.

Passar nesses testes não certifica o jogo inteiro. Eles podem detectar padrões grosseiros, mas não enxergam automaticamente uma regra administrativa oculta, uma troca de algoritmo ou uma manipulação aplicada apenas a poucos usuários.

20.2 Teste da distribuição de Crash

No Crash, a pergunta não é apenas quantas rodadas “venceram”. Precisamos medir quantas chegaram a cada multiplicador. Para um limite x, a sobrevivência empírica é a quantidade de rodadas cujo multiplicador M alcançou ou ultrapassou x, dividida pelo total observado:

O acento sobre P indica que estamos estimando a probabilidade a partir dos dados. No modelo analisado anteriormente, essa frequência observada deve ser comparada com a curva teórica:

Em x = 2, por exemplo, o modelo prevê sobrevivência próxima de 49,5%; em x = 10, próxima de 9,9%. Repetimos a comparação em vários pontos — como 1,2; 1,5; 2; 5; 10 e 100 — e colocamos intervalos de confiança ao redor das frequências observadas. Comparar muitos limites aumenta a chance de achar uma diferença apenas por acaso, portanto a quantidade de testes também precisa entrar na análise.

Depois da distribuição, vem a independência. Cruzamos resultados com rodadas anteriores, nonces, horários e mudanças de configuração para procurar dependência temporal. Uma correlação linear próxima de zero não encerra o assunto: relações não lineares, regras condicionais e intervenções raras podem permanecer escondidas.

Também pode ser necessário comparar grupos de usuários, porque uma distribuição global aparentemente correta consegue ocultar tratamento desigual. Exemplos de cortes possíveis incluem:

• novo/antigo;
• depósito baixo/alto;
• afiliado;
• região;
• dispositivo.

Uma diferença entre grupos é um sinal para investigar, não um veredito automático. Usuários novos e antigos podem jogar valores, horários e produtos diferentes. Sem controlar essas variáveis, composição distinta pode parecer segmentação deliberada. Se existe um painel administrativo, a evidência fica mais forte quando a configuração é registrada e o mesmo experimento é repetido antes e depois da alteração.

Outra medida essencial é o RTP observado, calculado pela razão entre todo o dinheiro pago aos jogadores e todo o dinheiro apostado na amostra:

Se foram apostados R$ 100 mil e os pagamentos somaram R$ 94 mil, o RTP observado foi de 94% naquele conjunto — e os R$ 6 mil restantes formam a perda bruta agregada dos participantes antes de outros ajustes. Em jogos de alta volatilidade, um prêmio raro pode deslocar bastante essa proporção, por isso uma amostra curta não deve ser comparada de forma ingênua com o RTP teórico. Certificadoras definem volumes e procedimentos justamente para reduzir esse erro.

A integridade da amostra importa tanto quanto a fórmula. Não se pode remover:

• rodadas desconectadas;
• crashes instantâneos;
• apostas perdidas;
• sessões negativas.

Excluir sessões negativas, desconexões ou crashes instantâneos fabrica artificialmente um desempenho melhor. Esse recorte oportunista, conhecido como cherry-picking, é uma das formas mais simples de transformar um conjunto ruim em uma propaganda enganosa.

Para que outra pessoa consiga refazer a análise, cada rodada precisa deixar um registro com identidade, entradas criptográficas, resultado, horários e versão do motor:

round_id
commitment
client_seed
nonce
server_seed_revealed
result
bet_timestamp
cashout_timestamp
engine_version

Mesmo uma sequência compatível com a distribuição teórica não prova ausência de manipulação seletiva rara. O operador poderia alterar poucas contas, trocar versões ou omitir registros sem deformar visivelmente a média global. É por isso que estatística, código, logs imutáveis, histórico de configuração e controle independente precisam se confirmar mutuamente.

Há ainda um limite ético importante: esta análise não serve para descobrir “quando entrar”, montar uma estratégia ou procurar uma plataforma supostamente menos ruim. Confirmar a distribuição apenas mostra se a vantagem matemática declarada está se manifestando como esperado; não transforma expectativa negativa em oportunidade de ganho e tampouco prova manipulação.

20.3 Como preservar evidências de forma reproduzível

Por que preservar evidências. Uma conclusão técnica precisa sobreviver à alteração do repositório. Projetos podem ser apagados ou atualizados depois da análise.

Registro mínimo. Registrar:

• URL de origem em arquivo interno da investigação;
• proprietário;
• nome;
• branch;
• commit;
• data;
• licença;
• hash dos arquivos;
• captura;
• notas.

Neste documento público, links operacionais de repositórios podem ser omitidos, mantendo identificadores.

Hash de arquivo. Calcular SHA-256:

sha256(file_content)

O hash prova que o arquivo analisado não foi alterado no acervo mantido por quem conduz a auditoria.

Captura de contexto. Não capturar apenas a linha. Guardar função completa e imports, pois interpretação depende do contexto.

Cadeia de custódia. Documentar:

• quem coletou;
• quando;
• onde armazenou;
• quem acessou;
• alterações;
• cópias.

Dados pessoais. Redigir:

• telefone;
• e-mail;
• chaves;
• credenciais;
• nomes de usuários;
• IPs.

Divulgação responsável. Se a vulnerabilidade estiver ativa:

1. não explorar;
2. registrar;
3. informar mantenedor;
4. aguardar correção;
5. publicar de forma não operacional;
6. preservar interesse público.

Contraprova. Para cada achado, registrar explicação alternativa.

Exemplo:

• achado: pagamento automático inalcançável;
• alternativa: saque manual;
• verificação: procurar worker ou cron externo;
• conclusão: fluxo publicado não realiza automático, mas outro módulo pode existir.

Nível de certeza. Escala sugerida:

• 5: execução inequívoca;
• 4: fluxo claro;
• 3: inferência forte;
• 2: possibilidade;
• 1: suspeita.

21 Como seria uma arquitetura que exige menos confiança cega

Princípio de minimização de confiança. O jogador não deveria confiar em uma única entidade para:

• escolher resultado;
• guardar segredo;
• registrar;
• verificar;
• certificar.

21.1 Cadeia de seeds

O servidor pode criar cadeia:

Publica a raiz antes. Cada rodada revela próximo valor. Isso dificulta selecionar depois.

Ainda é necessário provar que a cadeia não foi escolhida buscando sequência conveniente. Uma fonte pública posterior ajuda.

Entropia externa. Pode-se combinar:

O beacon deve ser imprevisível no compromisso e verificável depois.

Client seed real. Permitir ao jogador escolher texto. Em multiplayer, combinar contribuições.

Ledger append-only. Eventos:

• rodada criada;
• compromisso publicado;
• aposta aceita;
• apostas fechadas;
• resultado;
• cash-out;
• liquidação;
• revelação.

Cada evento possui hash do anterior.

Verificador aberto. O verificador deve ser:

• pequeno;
• documentado;
• executável offline;
• independente da página;
• versionado.

Configuração assinada. A rodada deve registrar:

• RTP;
• tabela;
• dificuldade;
• versão;
• hash da configuração.

Transação de saldo. Modelo de máquina de estados:

PLACED -> CASHED_OUT
PLACED -> LOST

Nunca ambos.

Idempotência. Cada operação possui UUID. Repetição retorna mesmo resultado.

Observabilidade. Métricas:

• RTP;
• latência;
• cash-outs;
• erros;
• duplicidade;
• divergência;
• seeds ausentes.

Certificação contínua. Atualização exige:

• revisão;
• testes;
• assinatura;
• rollout;
• rollback;
• registro.

21.2 Quais fontes merecem mais confiança

Fonte primária de código. O arquivo executável ou fonte é a melhor evidência sobre a implementação publicada. Entretanto, ele não prova que a mesma versão foi implantada.

Prioridade:

1. commit imutável;
2. arquivo no commit;
3. teste;
4. configuração;
5. README;
6. postagem;
7. vídeo.

Documento regulatório. Leis, portarias e padrões oficiais possuem maior autoridade que reportagens. Reportagens podem ajudar a localizar, mas devem ser substituídas pela fonte.

Dado estatístico. Classificar:

• administrativo;
• transacional;
• pesquisa amostral;
• estimativa;
• opinião.

O dado do Banco Central é estimativa transacional preliminar. O DataSenado é pesquisa. Não misturar.

Artigo científico. Verificar:

• revisão por pares;
• método;
• amostra;
• conflito;
• replicação;
• ano.

README. README é declaração do autor. Pode estar desatualizado. No aviator-fun, a promessa de verificação deve ser confrontada com rotas.

Nome de variável. Nome é indício. comissaofake prova uma coluna com esse nome, não prova automaticamente exibição falsa.

Comentário. O comentário “exponential distribution” diverge da fórmula. Código executado prevalece.

Interface. Mensagem prova o que é mostrado, não o que é pago.

21.3 Ausência

Não encontrar não significa inexistência. Registrar escopo.

Depois da técnica, resta uma pergunta inevitável: é moralmente suficiente cumprir a regra quando uma das partes enxerga e controla muito mais que a outra?

22 O problema ético por trás da assimetria de informação

Legalidade e moralidade. Algo legal pode ser moralmente questionável. Algo ilegal não é automaticamente analisado corretamente por retórica exagerada.

A ética exige:

• verdade;
• precisão;
• proporcionalidade;
• proteção de vulnerável;
• prestação de contas.

22.1 Assimetria de informação

O operador conhece:

• fórmula;
• RTP;
• saldo agregado;
• comportamento;
• margem;
• configuração.

O jogador conhece:

• interface;
• histórico pessoal;
• propaganda.

Essa assimetria justifica regulação.

Consentimento informado. Para consentir, o usuário precisa entender:

• chance;
• perda esperada;
• volatilidade;
• regras;
• saque;
• publicidade;
• dados.

Termos longos não equivalem a compreensão.

Justiça distributiva. O lucro pode vir desproporcionalmente de pessoas em situação de dano. A OMS observa que jogadores em níveis nocivos podem representar parcela elevada das perdas.

Um modelo dependente de usuários vulneráveis merece avaliação.

Responsabilidade do desenvolvedor. O desenvolvedor não é neutro quando implementa:

• contador falso;
• resultado manual;
• saque impossível;
• estímulo a perseguição;
• marketing enganoso.

Princípios profissionais incluem não causar dano e comunicar limitações.

23 Uma leitura cristã que confronta o sistema sem humilhar pessoas

Método. A teologia não deve inventar informação técnica. A auditoria mostra como o sistema funciona; a teologia avalia fins e relações.

23.1 Ganância

Lc 12:15 adverte contra todo tipo de ganância e ensina que vida não consiste em bens. A promessa de ganho rápido explora desejo de abundância como segurança.

O texto não condena planejamento ou trabalho. Condena redução da vida ao possuir.

Serviço ao dinheiro. Mt 6:24 apresenta lealdades concorrentes. Quando decisão, humor e esperança são controlados pelo saldo, o dinheiro assume função de senhor.

Desejo de enriquecer. 1Tm 6:9–10 descreve armadilhas associadas ao desejo de enriquecer. O problema não é possuir recurso, mas orientar a vida pela busca.

Balança desonesta. Pv 11:1 condena balança desonesta. Em ambiente digital, a balança é algoritmo. Se probabilidade divulgada difere da aplicada, o princípio é diretamente relevante.

Verdade. Ef 4:25 orienta falar verdade. Contador falso, vencedor simulado ou publicidade que oculta comissão violam transparência.

Amor ao próximo. Fp 2:4 orienta considerar interesse dos outros. Um influenciador deve avaliar o dano dos indicados.

Domínio. 1Co 6:12 afirma não se deixar dominar. O ciclo de aposta pode dominar atenção, dinheiro e relacionamentos.

Mordomia. A mordomia entende recursos como responsabilidade. Apostar dinheiro essencial expõe terceiros dependentes.

Trabalho e provisão. A tradição bíblica associa provisão a trabalho, sabedoria, generosidade e justiça, não a promessa de enriquecimento instantâneo.

Esperança e acaso. A fé cristã não transforma Deus em mecanismo para validar aposta. Orar por resultado não converte expectativa negativa em bênção.

23.1.1 “Bet gospel”

A palavra inglesa bet significa aposta. Em nomes hebraicos, beit/bayit significa casa.

• Betel: casa de Deus;
• Betsaida: nome com elemento de casa;
• Betânia: etimologia discutida, mas não ligada ao verbo inglês apostar.

Usar semelhança sonora como justificativa espiritual é erro etimológico.

23.2 Pastoreio sem humilhação

A pessoa em dependência não deve ser chamada de burra. A vergonha pode afastar ajuda. Um alerta firme pode dizer:

Pare de financiar quem lucra com a sua perda.

Mas o cuidado pastoral deve:

• ouvir;
• proteger finanças;
• envolver família com consentimento;
• estabelecer limites;
• buscar tratamento;
• evitar exposição pública.

Igreja e patrocínio. Comunidades devem avaliar:

• fonte do dinheiro;
• mensagem transmitida;
• público vulnerável;
• conflito;
• testemunho;
• prestação de contas.

Conclusão teológica. O argumento cristão mais forte não depende de dizer que toda rodada é fraudada. Mesmo um jogo tecnicamente honesto pode alimentar ganância, dominar comportamento e transferir recursos de vulneráveis para uma estrutura de vantagem.

23.3 Orientações práticas para igrejas e famílias

Não reduzir a sermão. Dependência pode exigir cuidado clínico e financeiro.

Mapear impacto

• dívidas;
• empréstimos;
• contas;
• segredo;
• conflitos.

Proteger recursos. Com consentimento e orientação profissional, criar barreiras.

Evitar exposição. Não usar testemunho sem autorização.

Tratar influenciadores. Ensinar conflito de comissão.

Linguagem. Firme contra sistema, compassiva com pessoa.

Teologia correta. Não dizer que a sorte é poder espiritual. Explicar matemática e ética.

Betel. Ensinar diferença linguística.

Prestação de contas. Líderes que promovem produtos devem declarar vínculo.

Esperança. Recuperação não depende de “última aposta”.

24 Como comunicar achados fortes sem afirmar o que não foi provado

Pergunta não é imunidade. Um título em forma de pergunta reduz assertividade, mas não impede responsabilização se o contexto acusa pessoa identificável.

Delimitação. Iniciar:

Analisei repositórios públicos independentes que reproduzem jogos de aposta. Eles não são atribuídos a marcas específicas.

Verbo adequado

• “encontrei” para código observado;
• “permite” para capacidade;
• “poderia” para hipótese;
• “não demonstra” para ausência;
• “infere-se” para inferência.

Não atribuir crime. Evitar “roubo”, “golpe”, “fraude” sem prova direta e base jurídica.

Anonimização. Não exibir telefone de desenvolvedor, mesmo público. O contato não é necessário para demonstrar o código.

Preservação. Guardar:

• captura;
• hash;
• data;
• arquivo;
• contexto;
• cálculo.

Direito de resposta. Se citar empresa, buscar manifestação e incluir resposta.

24.1 Como separar crítica técnica de acusação

Uma investigação sobre apostas precisa manter precisão não apenas por prudência jurídica, mas por integridade científica. A expressão “sistema controlado” pode significar que o operador define regras gerais, algo verdadeiro em qualquer software, ou que escolhe individualmente cada derrota, alegação muito mais forte. Quem audita deve declarar qual sentido utiliza.

Há evidência de controle estrutural quando o código contém fórmulas, parâmetros de dificuldade, limites e configurações. Há evidência de controle administrativo quando o operador consegue alterar esses valores por painel ou banco. Há evidência de controle individual somente quando o resultado depende de conta, grupo ou intervenção específica. Há evidência de fraude efetiva quando se demonstra que uma regra oculta foi aplicada contra o divulgado ou que um resultado foi deliberadamente adulterado.

Essa gradação evita dois erros. O primeiro é minimizar o risco, como se a presença de RNG tornasse o jogo neutro. O segundo é exagerar, tratando toda expectativa negativa como crime. O argumento técnico mais resistente reconhece que a vantagem da casa é uma característica matemática, enquanto manipulação é uma questão de integridade e transparência.

Ao escrever sobre os repositórios, vale usar frases como:

• “Na versão pública examinada, o servidor controla ambas as seeds.”
• “O fluxo permite inferir possibilidade de seleção prévia.”
• “Não foi encontrado mecanismo explícito de derrota forçada.”
• “A configuração de dificuldade é controlada pelo operador.”
• “O código não permite atribuir o comportamento a uma marca comercial.”
• “O caminho automático de pagamento não é alcançado para valores positivos.”

Essas formulações são fortes porque descrevem fatos verificáveis. Não dependem de adjetivos como “golpe”, “roubo” ou “armação”. Quando a evidência é clara, a descrição técnica já revela a gravidade.

Também é importante distinguir intenção de efeito. Um bug de concorrência pode produzir saldo incorreto sem intenção. Uma mensagem de “saque realizado” pode ser resultado de desenvolvimento incompleto. A responsabilidade técnica existe mesmo sem prova de intenção criminosa, mas a classificação jurídica exige elementos adicionais.

A investigação deve ainda oferecer espaço para correção. Repositórios mudam, autores corrigem falhas e normas evoluem. Registrar commit e data permite que uma resposta do mantenedor seja comparada de forma justa. Se uma função foi corrigida posteriormente, o trabalho pode declarar que o achado se refere à versão examinada.

Por fim, a crítica pública deve preservar a dignidade de apostadores. A pessoa que perdeu dinheiro não é prova de falta de inteligência. Jogos de alta velocidade, publicidade, conflitos de interesse, expectativa de recuperação e vulnerabilidade financeira formam um ambiente poderoso. A prevenção eficaz combina firmeza contra práticas opacas com cuidado para que vergonha não impeça a busca por ajuda.

24.1.1 Um modelo seguro para apresentar a investigação publicamente

A análise analisa repositórios públicos independentes que reproduzem jogos de aposta. Os códigos não são atribuídos a marcas específicas. Os achados demonstram como determinados sistemas podem ser construídos e quais garantias estão ausentes. A presença de uma capacidade técnica não prova que ela tenha sido usada em uma plataforma distinta.

24.2 Perguntas que expõem o que a tela tenta esconder

As perguntas abaixo não são um checklist para escolher onde apostar. Nenhuma combinação de respostas elimina a vantagem da casa ou transforma o jogo em investimento. Elas servem para auditores, jornalistas, familiares e pessoas afetadas identificarem quantas informações decisivas ficam fora da tela colorida:

1. Qual é o RTP?
2. Qual é a house edge?
3. Quem certificou?
4. Qual versão?
5. O resultado é pré-calculado?
6. Quem escolhe seeds?
7. Existe verificador externo?
8. Há histórico?
9. O afiliado recebe como?
10. O influenciador usa dinheiro próprio?
11. O saldo mostrado é sacável?
12. Há limite?
13. Há autoexclusão?
14. Como reclamar?
15. O jogo é autorizado?
16. O painel altera dificuldade?
17. Mudanças são auditadas?
18. O contador é real?
19. O saque está pago ou processando?
20. O lucro exibido desconta aposta?

Ao juntar todas as camadas, saímos das respostas fáceis. O quadro não é “sorte pura”, mas também não autoriza a alegação genérica de que tudo foi diretamente manipulado.

25 O que aparece quando juntamos matemática, código e incentivo econômico

A hipótese da “sorte pura”. Os repositórios demonstram que chamar jogos digitais de “sorte pura” é simplificação. Mesmo quando a seleção contém aleatoriedade, o resultado passa por:

• fórmula;
• vantagem;
• arredondamento;
• limites;
• estado;
• tempo;
• configuração.

A sorte opera dentro de regras programadas.

25.1 A hipótese de “tudo manipulado”

A afirmação oposta também é excessiva. No aviator-fun, o código público utiliza fonte criptográfica e não contém lógica explícita de derrota por usuário.

Uma crítica verdadeira é mais forte:

• há house edge;
• há controle unilateral das seeds;
• há resultado pré-calculado;
• há falta de auditoria completa;
• há falhas de produção.

25.1.1 Operador e painel

O subway-pay confirma dificuldade no banco. Isso demonstra que um operador de clone pode modificar condição sem alterar interface.

Não foi comprovada uma retenção exata de 90%. Um exemplo hipotético de 10% deve ser apresentado como ilustração, não como configuração encontrada.

Visualização como narrativa. A tela não é o cálculo. O avião é animação. O slot é apresentação. O motor pode ter decidido antes.

Essa descoberta é pedagogicamente poderosa. O usuário acredita reagir ao evento; na realidade, reage à representação.

Criptografia como marketing. “Provably fair” pode funcionar como selo. A maioria não distingue:

• hash;
• HMAC;
• seed;
• nonce;
• compromisso.

A expressão pode transmitir mais garantia que o protocolo fornece.

Código público como evidência parcial. O código público permite revisão, mas:

• servidor real pode ser diferente;
• branch muda;
• módulos privados;
• configuração ausente;
• banco não fornecido;
• deploy desconhecido.

Transparência exige correspondência entre fonte e execução.

Integridade financeira. As falhas de cash-out e saque mostram que justiça não se limita ao RNG. Um resultado honesto com saldo inseguro continua inadequado.

Conflito econômico. House edge, GGR e revenue share alinham interesses:

• plataforma ganha com perda agregada;
• afiliado pode ganhar com receita;
• jogador busca lucro.

A assimetria não prova crime, mas exige transparência.

Teologia e técnica. A teologia contribui ao perguntar quem é servido e quem é prejudicado. A técnica evita que o sermão dependa de afirmações falsas.

25.2 Respostas diretas às objeções mais comuns

“Mas eu conheço alguém que ganhou”. Ganhos individuais são compatíveis com house edge. A casa depende de vencedores para atrair e pagar.

“RTP alto significa segurança”. RTP não garante resultado individual nem integridade de saque.

“Provably fair prova tudo”. Prova aquilo que o protocolo inclui. Pode não provar seleção inicial.

“O avião caiu porque saquei”. No clone, o crash point é calculado antes. Seu clique não altera.

“Depois de perder muito, vai pagar”. Não em evento independente. Pode continuar perdendo.

“Influenciador ganha comigo”. Pode receber fixo, cadastro ou participação. Exigir declaração.

“A bet é gospel”. Rótulo religioso não muda matemática.

“Se é regulada, não há risco”. Regulação reduz alguns riscos; house edge e dano continuam.

“Código aberto é justo”. Código aberto permite auditoria, mas execução pode diferir.

“Todo jogo é fraude”. Não é conclusão sustentada. Vantagem matemática já basta para alerta.

26 Conclusão: o jogador não está em um ambiente neutro

Depois de toda a análise, a recomendação não é “apostar com consciência”. É não apostar. A linguagem de moderação pode soar confortável, mas não muda o mecanismo econômico: a plataforma, os fornecedores e os afiliados são pagos com o dinheiro que o conjunto dos jogadores perde. Quanto mais longa a permanência e maior a repetição, mais oportunidades a vantagem matemática encontra para consumir o saldo.

Este artigo partiu de uma pergunta popular: jogos de aposta digitais são sorte ou sistema controlado? Depois de acompanhar fórmulas, seeds, painéis, transações e mensagens, a resposta fica mais clara: eles são sistemas programados que podem conter aleatoriedade. A aleatoriedade não elimina regras, vantagem, parâmetros nem decisões administrativas.

A análise do nutcas3/aviator-fun encontrou fórmula de Crash com house edge explícita, HMAC-SHA256 e compromisso. Não encontrou resultado forçado por usuário. Entretanto, o servidor gera as duas seeds, calcula o ponto antes de abrir apostas e não oferece garantia contra seleção prévia. A arquitetura demonstra consistência posterior, não imparcialidade total. Falhas de autenticação, autorização, concorrência, timeout, persistência e escala tornam o protótipo inadequado para dinheiro real.

A análise do daanrox/subway-pay encontrou dificuldade controlada pelo operador, campos de simulação, mensagens de continuidade, estrutura de afiliados e condição impossível no pagamento automático de saque positivo. Não foi encontrada prova conclusiva de que toda rodada seja forçada. O sistema demonstra assimetria e falta de auditabilidade.

Esses achados pertencem a essas versões públicas e a esses repositórios. Eles demonstram que tais arquiteturas podem ser construídas e ajudam a formular perguntas de auditoria, mas não revelam como operam os servidores de empresas comerciais cujo código não foi examinado. Portanto, não sustentam a afirmação de que grandes plataformas roubam, manipulam jogadores ou reproduzem os mesmos mecanismos.

Os casos comparativos mostram que muitos projetos são frontends ou demos. A palavra “provably fair” em README não substitui o motor. Um clone não prova comportamento de marca.

A vantagem da casa é suficiente para produzir expectativa negativa. Um RTP de 96% não devolve 96% a cada pessoa; é média agregada. A repetição aumenta volume e perda esperada. A casa opera com grandes amostras; o jogador, com capital limitado.

No campo comportamental, animações, mensagens, prova social e incentivos reduzem percepção de risco. Afiliados em revenue share podem possuir conflito porque a comissão deriva da receita gerada pelos indicados.

No campo regulatório, o Brasil exige autorização, certificação, medidas chamadas de “jogo responsável” e controle publicitário. Essas exigências podem reduzir fraude e dano, mas não convertem uma aposta de expectativa negativa em produto benéfico. Padrões como UKGC RTS 7 e GLI-19 reforçam aleatoriedade, independência, logs e proibição de adaptação; nenhum deles promete lucro ao jogador.

No campo teológico, o alerta mais sólido não precisa afirmar fraude universal. A combinação de ganância, domínio, opacidade e lucro sobre perdas já exige prudência. A semelhança entre “bet” inglês e “beit” hebraico não oferece fundamento para “bet gospel”.

A síntese final é:

O jogador não disputa em ambiente neutro. Ele participa de regras definidas pela casa, com expectativa matemática favorável ao operador. Quando código, configuração e auditoria permanecem sob controle unilateral, ele não possui base suficiente para verificar a imparcialidade. Não procure uma estratégia secreta, um horário que “paga” ou uma forma mais cuidadosa de continuar: não aposte. Vitórias pontuais são o combustível visual que mantém muitos participantes tentando; a sustentabilidade do negócio continua dependendo da perda agregada deles.

26.1 Dez princípios para não perder o essencial

1. Um resultado pode ser aleatório e desfavorável.
2. Uma animação pode mostrar resultado já calculado.
3. Um hash pode ser verdadeiro e incompleto.
4. Um painel pode alterar regras invisíveis.
5. Um nome de variável exige rastreamento.
6. Um clone não representa uma marca.
7. Uma vitória não invalida a house edge.
8. Um influenciador pode possuir conflito.
9. Uma plataforma regulada ainda envolve risco.
10. Um alerta verdadeiro é mais forte que exagero.

26.2 A pergunta que permanece

A tecnologia dos jogos de aposta não deve ser tratada como magia. Ela é formada por funções, configurações, bancos, filas, interfaces e decisões humanas. Quando o público compreende esse fato, a pergunta deixa de ser “qual horário paga?” e passa a ser “quais regras foram programadas, quem pode alterá-las e quem verifica?”.

A investigação dos códigos públicos oferece uma janela para essas possibilidades. Ela não autoriza acusações universais, mas desmonta a ideia de que o apostador esteja diante de um fenômeno natural fora do controle humano. A aleatoriedade, quando existe, opera dentro de limites definidos pela casa.

A prevenção mais eficaz começa por não participar e combina alfabetização matemática, transparência técnica, regulação, cuidado clínico, responsabilidade publicitária e formação ética. Para quem já foi afetado, interromper a perseguição das perdas e procurar apoio de pessoas de confiança, atendimento clínico e orientação financeira é mais importante do que tentar recuperar no próprio jogo o que o jogo ajudou a retirar. Nenhum desses elementos deve atuar isoladamente.

Para quem audita cristão, a tarefa inclui duas fidelidades: fidelidade aos fatos e fidelidade ao cuidado com pessoas. Exagerar compromete a verdade; minimizar compromete a proteção. O caminho responsável é demonstrar o que o código prova, reconhecer o que não prova e aplicar o conhecimento para evitar que esperança, renda e relacionamentos sejam entregues a sistemas cuja sustentabilidade econômica depende da perda agregada de seus participantes.

26.3 O método inteiro em sete perguntas

A investigação de um jogo digital pode ser resumida em sete perguntas:

1. Qual é a matemática? Calcular RTP, house edge, frequência e volatilidade.
2. Quando o resultado nasce? Antes, durante ou depois da aposta.
3. Quem controla as entradas? Servidor, jogador, fonte externa ou todos.
4. O que o compromisso prova? Não alteração posterior ou imparcialidade completa.
5. Quem pode mudar as regras? Desenvolvedor, administrador ou fornecedor.
6. O dinheiro é íntegro? Débitos, créditos e saques são atômicos e auditáveis.
7. O usuário compreende? A interface comunica risco, resultado líquido e conflito comercial.

Aplicando essas perguntas aos casos, o aviator-fun apresenta matemática explícita e compromisso, mas mantém todas as entradas sob controle do servidor e possui fragilidades operacionais. O subway-pay apresenta dificuldade controlada, mensagens de repetição e incoerência no fluxo de saque. Nenhum dos dois fornece base para acusar todas as plataformas comerciais; ambos fornecem material para demonstrar a necessidade de auditoria independente.

A principal contribuição desta análise é substituir a oposição simplista “sorte ou fraude” por uma leitura em camadas. Um jogo pode ser aleatório, possuir vantagem da casa, ser pré-calculado, ser não auditável e ainda não conter derrota forçada. Cada camada exige evidência própria.

Material técnico complementar para pesquisa, revisão e apresentação

Para quem quiser levar a análise além do código público

Pergunta principal. Quais controles de resultado e mecanismos de transparência aparecem em clones públicos de jogos de aposta?

Perguntas secundárias

1. Quantos publicam backend?
2. Quantos possuem house edge explícita?
3. Quantos permitem client seed?
4. Quantos têm verificador?
5. Quantos possuem painel de dificuldade?
6. Quantos usam prova social simulada?
7. Quantos tratam cash-out atomicamente?

Amostra. Selecionar repositórios já identificados, com critérios:

• públicos;
• código disponível;
• jogo funcional ou motor;
• commit registrado;
• licença;
• atividade.

Por segurança, não publicar guia de implantação.

26.4 Instrumento de codificação

Planilha:

Campo	Tipo
Repo	texto
Commit	hash
Backend	sim/não
RNG	categoria
House edge	número
Client seed	origem
Precomputed	sim/não
Admin controls	lista
Auth	nível
Ledger	nível
Evidence	A–E

Dupla codificação. Dois revisores classificam de forma independente. Calcular concordância de Cohen.

Entrevistas. Entrevistar:

• desenvolvedores;
• auditores;
• reguladores;
• psicólogos;
• pastores;
• ex-apostadores adultos.

Perguntas não devem solicitar técnicas de fraude.

Ética em pesquisa

• anonimizar participantes;
• consentimento;
• não coletar credenciais;
• não apostar dinheiro;
• não explorar sistemas;
• não publicar vulnerabilidade ativa sem divulgação responsável.

Perguntas para desenvolvedores, auditores, psicólogos e pastores

Para desenvolvedor

1. Onde o resultado é calculado?
2. Quem controla seeds?
3. Como versões são assinadas?
4. Como alterações são registradas?
5. Como cash-out é sincronizado?
6. Como RTP é monitorado?
7. Como conflitos são tratados?

Para auditor

1. Quais testes mínimos?
2. Como detectar seed grinding?
3. Como certificar painel?
4. Qual amostra estatística?
5. Como monitorar depois?

Para psicólogo

1. Quais características aumentam dano?
2. Como mensagens afetam chasing?
3. Como prova social influencia?
4. Como orientar famílias?

Para pastor

1. Como alertar sem humilhar?
2. Como diferenciar pecado, dano e dependência?
3. Como tratar recursos familiares?
4. Como responder a “bet gospel”?

Como testar se as conclusões continuam de pé

Validade interna. A reconstrução temporal está apoiada em código. Porém, pode existir módulo não examinado.

Validade externa. Dois repositórios não representam todo setor.

Validade de construto. “Manipulação” foi dividida em categorias para evitar ambiguidade.

Confiabilidade. Outra pessoa deve conseguir repetir a análise usando o mesmo commit.

Viés de quem conduz a auditoria. O objetivo preventivo pode favorecer achados críticos. Por isso foram registradas ausências de manipulação direta.

Triangulação. Combinar:

• código;
• documentação;
• testes;
• normas;
• dados;
• entrevistas.

Atualização. Este documento é válido para material consultado até 18 de julho de 2026. Regulação e repositórios podem mudar.

Perguntas úteis para revisar criticamente os achados

Questões de matemática

• A relação entre RTP e house edge está correta?
• O cenário de 10% distingue frequência e valor?
• A distribuição do Crash foi descrita corretamente?
• O truncamento foi considerado?

Questões de computação

• A ordem temporal foi reconstruída?
• A função de seed está correta?
• A concorrência é real?
• Há middleware não examinado?
• O Redis é usado como ledger?

Questões jurídicas

• O trabalho evita atribuição?
• As normas estão atualizadas?
• O mercado ilegal é separado do autorizado?
• A publicidade é tratada com precisão?

Questões sociais

• Dados possuem período?
• Fluxo bruto não é chamado de perda?
• Beneficiários não são estigmatizados?

Questões teológicas

• Textos estão contextualizados?
• A pessoa é tratada com compaixão?
• A crítica é ao sistema e à ganância?
• A etimologia está correta?

26.5 Uma versão curta para apresentar a análise

1. O trabalho não afirma fraude universal.
2. House edge gera expectativa negativa.
3. RTP é média coletiva.
4. Resultado pré-calculado não é automaticamente fraude.
5. aviator-fun controla ambas as seeds.
6. Compromisso prova não alteração posterior.
7. Seed grinding não é impedido.
8. Manipulação direta não foi encontrada.
9. Há falhas críticas de segurança.
10. subway-pay possui dificuldade controlada.
11. Mensagens incentivam continuidade.
12. Saque automático positivo é inalcançável no fluxo.
13. Campos fake existem no esquema.
14. Clones não provam código de marcas.
15. Afiliados podem ter conflito.
16. Dados oficiais mostram grande escala.
17. Brasil exige certificação.
18. UKGC proíbe adaptação.
19. Teologia reforça verdade e domínio próprio.
20. A conclusão recomenda não participar de sistemas opacos e de expectativa negativa.

Roteiro de apresentação em onze partes

Slide 1 — Problema. Jogos digitais são apresentados como sorte. Código revela regras invisíveis.

Slide 2 — Método. Auditoria de dois casos centrais e dois comparativos.

Slide 3 — Matemática. RTP não é devolução individual. House edge é margem agregada.

Slide 4 — Aviator. Resultado pré-calculado e seeds controladas pelo servidor.

Slide 5 — Limite. Não foi encontrado force loss por usuário.

Slide 6 — Subway Pay. Dificuldade administrativa e saque contraditório.

Slide 7 — Interface. Persistência, prova social e visualização.

Slide 8 — Afiliados. Revenue share pode alinhar comissão à perda.

Slide 9 — Regulação. Certificação, logs, publicidade e jogo responsável.

Slide 10 — Teologia. Verdade, mordomia, domínio próprio e cuidado.

Slide 11 — Conclusão. Não é necessário provar fraude universal para demonstrar risco.

26.6 Se o conteúdo também for usado em uma publicação acadêmica

Este artigo examina mecanismos matemáticos e arquiteturais em repositórios públicos que reproduzem jogos de aposta on-line. Mediante auditoria manual, reconstrução temporal e comparação regulatória, são analisados um backend de Crash anunciado como provably fair e uma plataforma PHP com painel, dificuldade e fluxo de saque. No primeiro, o servidor utiliza HMAC-SHA256, mas controla tanto a server seed quanto a variável denominada client seed e calcula o ponto de queda antes da abertura das apostas. O compromisso criptográfico impede alteração posterior, mas não demonstra seleção imparcial anterior. Também são identificadas falhas de autenticação, autorização, atomicidade e persistência. No segundo, são observados parâmetro de dificuldade, campos de simulação, mensagens de continuidade e condição incompatível no caminho de pagamento automático. Os achados não comprovam manipulação de marcas comerciais nem resultado forçado em toda rodada. Demonstram superfícies de controle, não auditabilidade e expectativa negativa. O artigo discute house edge, RTP, seed grinding, design persuasivo, afiliados, legislação e ética cristã.

26.6.1 De onde vem a contribuição original desta análise

A contribuição desta investigação não está em afirmar que “a casa sempre ganha” de modo genérico. Está em criar uma estrutura de análise que separa:

• matemática;
• aleatoriedade;
• compromisso;
• seleção;
• visualização;
• saldo;
• saque;
• marketing;
• ética.

A matriz evita que crítica social substitua perícia. Também evita que criptografia seja confundida com justiça.

26.6.2 Notas finais para quem quiser aproveitar o material em uma pesquisa

Antes da entrega à instituição:

1. inserir autor, instituição e orientador;
2. adaptar margens e estrutura à norma local;
3. verificar se a instituição exige ABNT NBR 6023;
4. registrar hashes de commits;
5. anexar capturas com dados pessoais ocultos;
6. submeter a revisão jurídica se nomes comerciais forem acrescentados;
7. revisar cálculos com professor de estatística;
8. evitar usar clones como prova contra marcas;
9. indicar que dados de mercado possuem metodologias diferentes;
10. revisar as citações bíblicas conforme a edição autorizada.

27 Fontes, normas, pesquisas e repositórios consultados

27.1 Fontes oficiais brasileiras

BANCO CENTRAL DO BRASIL. Análise técnica sobre o mercado de apostas online no Brasil e o perfil dos apostadores. Estudo Especial nº 119, 2024. Disponível em:
https://www.bcb.gov.br/conteudo/relatorioinflacao/EstudosEspeciais/EE119_Analise_tecnica_sobre_o_mercado_de_apostas_online_no_Brasil_e_o_perfil_dos_apostadores.pdf
Acesso em: 18 jul. 2026.

BRASIL. Lei nº 13.756, de 12 de dezembro de 2018. Dispõe sobre loterias e apostas de quota fixa. Disponível em:
https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13756.htm
Acesso em: 18 jul. 2026.

BRASIL. Lei nº 14.790, de 29 de dezembro de 2023. Dispõe sobre a modalidade lotérica de apostas de quota fixa. Disponível em:
https://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/lei/l14790.htm
Acesso em: 18 jul. 2026.

BRASIL. MINISTÉRIO DA FAZENDA. Portaria SPA/MF nº 1.207, de 29 de julho de 2024. Requisitos técnicos dos sistemas, jogos on-line e estúdios. Relação oficial disponível em:
https://www.gov.br/fazenda/pt-br/composicao/orgaos/secretaria-de-premios-e-apostas/apostas-de-quota-fixa/legislacao
Acesso em: 18 jul. 2026.

BRASIL. MINISTÉRIO DA FAZENDA. Portaria SPA/MF nº 1.231, de 31 de julho de 2024. Jogo responsável, comunicação, publicidade e direitos. Disponível na relação oficial:
https://www.gov.br/fazenda/pt-br/composicao/orgaos/secretaria-de-premios-e-apostas/apostas-de-quota-fixa/legislacao
Acesso em: 18 jul. 2026.

BRASIL. MINISTÉRIO DA FAZENDA. Questões técnicas sobre apostas de quota fixa. Disponível em:
https://www.gov.br/fazenda/pt-br/composicao/orgaos/secretaria-de-premios-e-apostas/apostas-de-quota-fixa/questoes-tecnicas
Acesso em: 18 jul. 2026.

BRASIL. MINISTÉRIO DA FAZENDA. Indicadores do mercado regulado de apostas de quota fixa — primeiro semestre de 2025. Disponível em:
https://www.gov.br/fazenda/pt-br/composicao/orgaos/secretaria-de-premios-e-apostas/apresentacoes/copy_of_apresentacao_spamf_relatoriodo1osemestre_versao1.pdf
Acesso em: 18 jul. 2026.

BRASIL. MINISTÉRIO DA FAZENDA. Nota Técnica SEI nº 229/2025/MF — recompensas e GGR. Disponível em:
https://www.gov.br/fazenda/pt-br/composicao/orgaos/secretaria-de-premios-e-apostas/apostas-de-quota-fixa/sei_47749330_nota_tecnica_229
Acesso em: 18 jul. 2026.

TRIBUNAL DE CONTAS DA UNIÃO. Levantamento sobre jogos de apostas on-line — BETS. Processo TC 024.852/2024-4, 2025. Disponível em:
https://portal.tcu.gov.br/data/files/AC/11/6D/7C/5D817910E5B0C269F18818A8/024.852-2024-4-JPJ-%20Jogos%20de%20Apostas%20online-BETS.pdf
Acesso em: 18 jul. 2026.

SENADO FEDERAL; DATASENADO. Pesquisa sobre apostas esportivas e jogos on-line, 2024. Disponível em:
https://www12.senado.leg.br/noticias/materias/2024/10/01/mais-de-22-milhoes-de-pessoas-apostaram-nas-bets-no-ultimo-mes-revela-datasenado
Acesso em: 18 jul. 2026.

27.2 Padrões e documentos internacionais

GAMBLING COMMISSION. Remote Gambling and Software Technical Standards: RTS 7 — Generation of random outcomes. Reino Unido. Disponível em:
https://www.gamblingcommission.gov.uk/standards/remote-gambling-and-software-technical-standards/rts-7-generation-of-random-outcomes
Acesso em: 18 jul. 2026.

GAMBLING COMMISSION. Definition of terms: compensated and adaptive behaviour. Disponível em:
https://www.gamblingcommission.gov.uk/standards/remote-gambling-and-software-technical-standards/2-definition-of-terms
Acesso em: 18 jul. 2026.

GAMING LABORATORIES INTERNATIONAL. GLI-19: Standards for Interactive Gaming Systems, Version 3.0. 2024. Disponível em:
https://gaminglabs.com/wp-content/uploads/2024/06/GLI-19-Interactive-Gaming-Systems-v3.0.pdf
Acesso em: 18 jul. 2026.

KRAWCZYK, H.; BELLARE, M.; CANETTI, R. HMAC: Keyed-Hashing for Message Authentication. RFC 2104. Internet Engineering Task Force, 1997. Disponível em:
https://www.rfc-editor.org/info/rfc2104/
Acesso em: 18 jul. 2026.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90A Rev. 1. Disponível em:
https://csrc.nist.gov/pubs/sp/800/90/a/r1/final
Acesso em: 18 jul. 2026.

WORLD HEALTH ORGANIZATION. Gambling: fact sheet. 2024. Disponível em:
https://www.who.int/news-room/fact-sheets/detail/gambling
Acesso em: 18 jul. 2026.

27.3 Literatura acadêmica

AUER, Michael; GRIFFITHS, Mark D. The relationship between structural characteristics and gambling behaviour: an online gambling player tracking study. Journal of Gambling Studies, v. 39, p. 265–279, 2023. DOI: 10.1007/s10899-022-10115-9. Disponível em:
https://pubmed.ncbi.nlm.nih.gov/35553316/
Acesso em: 18 jul. 2026.

MATHUR, Arunesh et al. Dark Patterns at Scale: Findings from a Crawl of 11K Shopping Websites. Proceedings of the ACM on Human-Computer Interaction, 2019. Disponível em:
https://arxiv.org/abs/1907.07032
Acesso em: 18 jul. 2026.

NEWALL, Philip W. S. Structural characteristics of online gambling platforms. Journal of Gambling Issues, 2023. Disponível em:
https://cdspress.ca/wp-content/uploads/2023/11/V52_JGI-May-23-LETTER-003_Newall_Proof_FINAL.pdf
Acesso em: 18 jul. 2026.

TORRANCE, Jack et al. The structural characteristics of online sports betting: a scoping review of current product features and utility patents as indicators of potential harm. 2024. Disponível em:
https://orca.cardiff.ac.uk/id/eprint/161498/
Acesso em: 18 jul. 2026.

27.4 Repositórios analisados

NUTCAS3. aviator-fun. Repositório público de software. Arquivos analisados: internal/game/provably_fair.go, internal/game/manager.go, internal/game/provably_fair_test.go, internal/server/handlers.go e internal/server/game_routes.go. Consulta em: 18 jul. 2026.

DAANROX. subway-pay. Repositório público de software. Arquivos analisados: README.md, painel/index.php, play/win.php, play/loss.php, saque/saque.php e sql_subway.sql. Consulta em: 18 jul. 2026.

TANH1C. stake-originals-clone. Repositório público demonstrativo. Consulta em: 18 jul. 2026.

AKASHMAHLAZ. aviator-crash. Repositório público. Consulta em: 18 jul. 2026.

27.4.1 Referências bíblicas

BÍBLIA SAGRADA. Nova Versão Internacional. Referências utilizadas de forma breve: Pv 11:1; Mt 6:24; Lc 12:15; 1Co 6:12; Fp 2:4; Ef 4:25; 1Tm 6:9–10.