Certificação de slots explicada: o que os laboratórios de fato testam
Guides · 2026-05-23 · 5 min read · By CROCO Games
O que a certificação de RNG e RTP cobre sob testes no estilo GLI-19, o que um certificado garante e o que não garante, e o que exigir de um provedor.
Um certificado de slot é a declaração assinada de um laboratório de que um build específico de um jogo específico atende a um padrão técnico definido — mais comumente que seu RNG é estatisticamente sólido e que seu RTP medido bate com o RTP declarado. É evidência, não garantia, e saber exatamente o que ele cobre (e o que deliberadamente não cobre) é o que separa uma due diligence real de arquivar um PDF que você nunca leu. Este artigo percorre o que os laboratórios credenciados testam sob padrões no estilo GLI-19, os limites do que um certificado garante e os documentos específicos a exigir antes de integrar.
O que os laboratórios de fato testam
Casas de teste independentes — GLI, iTech Labs, eCOGRA, BMM e outras — avaliam o software de jogo contra padrões publicados. O GLI-19 é o padrão amplamente referenciado para sistemas de jogo interativo; os critérios específicos de RNG ecoam também no GLI-11 e nas regras de jurisdição. O núcleo do que examinam:
- Aleatoriedade e imprevisibilidade do RNG. Baterias de testes estatísticos (distribuição uniforme, independência, ausência de correlação serial) rodam sobre amostras enormes para confirmar que os resultados não são previsíveis nem enviesados.
- Escalonamento e mapeamento do RNG. Que a conversão de números aleatórios brutos em paradas de rolo ou compra de cartas não introduza viés — um RNG correto ainda pode ser arruinado por um mapeamento ruim.
- Verificação de RTP. Que o retorno simulado e/ou medido ao longo de milhões de rodadas bata com o RTP declarado dentro da tolerância, para o modelo matemático exato submetido.
- Integridade das regras do jogo. Que a tabela de pagamentos, os recursos e o max win se comportem como a tela de regras afirma, e que o jogo não possa pagar fora de sua faixa definida.
- Memória crítica e recuperação. Que uma desconexão no meio de um recurso se resolva corretamente e o jogador não seja lesado — relevante especialmente para Hold and Win e rodadas de crash.
Uma aprovação significa: neste build, a matemática é honesta e a aleatoriedade é real.
O que um certificado NÃO garante
É aqui que os operadores ficam acomodados. Um certificado é estreito por design:
- Ele não cobre um build diferente. A certificação é por versão do jogo e por modelo matemático. Um build de 96% e um de 92% são certificados separadamente; um build corrigido precisa de novo teste. O certificado que lhe mostraram pode não bater com o binário que você está prestes a rodar.
- Ele não garante que o jogo é licenciado no seu mercado. Certificação técnica e aprovação jurisdicional são portões diferentes. Um jogo certificado pela GLI ainda pode não estar aprovado em Ontário, por exemplo.
- Ele nada diz sobre a integração. O certificado cobre o jogo; sua carteira, fluxo de sessão e relatórios são uma questão de certificação separada (veja o teste de integração abaixo).
- Ele não é uma promessa de justiça ao jogador em linguagem simples. "Certificado" não significa "generoso" — um jogo de 92% certificado está certificado para reter 8%. A certificação é sobre a honestidade da matemática declarada, não sobre a simpatia para com o jogador.
- Ele não prova que o jogo está rodando a versão certificada em produção. Isso requer correspondência de hash de build e controles de plataforma, não apenas um PDF.
Trate um certificado como necessário e insuficiente. Ele elimina uma classe de risco (matemática viciada ou quebrada) e é silencioso sobre várias outras.
O conjunto de documentos a exigir
Não aceite "nossos jogos são certificados" como resposta. Peça especificidades e verifique-as:
| Peça por | Por que importa |
|---|---|
| Certificado para o build exato + modelo de RTP que você vai rodar | Certificados são por versão, por RTP; a alegação geral não basta |
| Nome do laboratório credenciado e do padrão (ex.: GLI-19) | Confirma que é uma casa reconhecida, não uma autoavaliação |
| Data do certificado e referência de versão/hash | Confirma que bate com a produção atual, não um build superado |
| Lista de aprovação jurisdicional | Certificação técnica não é licenciamento de mercado |
| Descrição do RNG e política de reteste em correções | Diz se as atualizações são recertificadas |
| Escopo da certificação de integração/plataforma | Cobre sua carteira e camada de sessão, não só o jogo |
Certificados são frequentemente compartilhados sob NDA neste setor — isso é normal e não é, por si só, um sinal de alerta. O RNG da CROCO é testado de forma independente com certificados disponíveis sob NDA; o teste é se um provedor de fato produzirá o documento correspondente para o build específico quando você pedir, não se ele agita a palavra "certificado" por aí. Um provedor que não consegue mapear um certificado ao build exato que você está implantando é o que deve preocupar.
Lendo um certificado: os campos que importam
Quando o PDF chegar, não apenas o arquive — leia cinco campos. O nome do jogo e o ID de versão/build devem bater com o que você está implantando, caractere por caractere. O modelo de RTP deve bater com a variante que você selecionou. O laboratório e o padrão devem ser uma casa reconhecida e um padrão nomeado (GLI-19, GLI-11, ou o próprio da jurisdição). A data de emissão deve ser recente o suficiente para corresponder ao build atual, não a uma versão superada de dois anos atrás. E a declaração de escopo diz o que foi testado — só RNG, RNG mais RTP, ou lógica completa do jogo. Um certificado que cobre "RNG" mas não a matemática específica do jogo é um documento mais estreito do que parece. Se qualquer um desses cinco não bater, volte ao provedor antes de integrar; uma incompatibilidade aqui é exatamente o que um auditor encontrará depois.
Como a certificação se encaixa no seu onboarding
Encaixe a certificação em um portão de onboarding repetível, em vez de tratá-la como algo pontual:
- Pré-integração: colete certificados para cada título e modelo de RTP, confirme laboratório e padrão, cheque as datas contra os builds atuais.
- Checagem de jurisdição: cruze cada jogo com seus mercados licenciados; um jogo certificado que você não está aprovado a oferecer ainda é uma violação.
- Certificação de integração: garanta que a própria integração de plataforma e carteira seja testada — muitas jurisdições certificam a conexão operador-provedor, não só os jogos.
- Controle de mudança: obtenha compromisso por escrito de que builds corrigidos são recertificados e de que você será notificado sobre mudanças de versão.
- Verificação em produção: onde sua plataforma suportar, verifique que o build em execução bate com a versão certificada.
Esse portão leva uma tarde por provedor e o salva dos dois piores desfechos: enviar um build não certificado para um mercado regulado, ou descobrir durante uma auditoria que seus papéis não batem com seus binários.
Perguntas frequentes
Um único certificado cobre todas as variantes de RTP de um jogo?
Não. A certificação é por versão do jogo e por modelo matemático, então um build de 96% e um de 92% são certificados separadamente, e um build corrigido precisa de novo teste. Peça o certificado que corresponde ao build e ao modelo de RTP exatos que você pretende implantar, não uma declaração geral de que o portfólio é certificado.
É um sinal de alerta quando os certificados só são compartilhados sob NDA?
Não, certificados sob NDA são normais neste setor. O teste que importa é se o provedor de fato produz o documento correspondente ao build específico que você está implantando quando você pede. Um provedor que não consegue mapear um certificado ao seu build é o que deve preocupar.
Um certificado técnico significa que o jogo é legal no meu mercado?
Não. Certificação técnica e aprovação jurisdicional são portões diferentes: um jogo certificado pela GLI ainda pode não estar aprovado em um mercado como Ontário. Cruze cada título com seus mercados licenciados e peça a lista de aprovação jurisdicional do provedor junto com o próprio certificado.
O que devo checar quando o PDF do certificado chega?
Leia cinco campos antes de arquivá-lo: o nome do jogo e o ID de versão/build, o modelo de RTP, o laboratório e o padrão nomeado, a data de emissão e a declaração de escopo dizendo o que foi testado. Se algum deles não bater com o build que você implanta, volte ao provedor antes de integrar.
Principais conclusões
- A certificação prova que o RNG é sólido e que o RTP medido bate com o RTP declarado para um build específico e um modelo matemático.
- Ela não prova licenciamento de mercado, solidez da integração, simpatia ao jogador, nem que a produção roda a versão certificada.
- Exija o certificado para o build e o RTP exatos que você implanta, além do laboratório, padrão, data e lista de jurisdição — não um genérico "somos certificados".
- Certificados restritos por NDA são normais; o teste real é se um provedor mapeia um certificado ao seu build específico quando solicitado.
- Faça da certificação um portão de onboarding repetível cobrindo jogos, jurisdição, integração e controle de mudança.
Trabalhe com a CROCO Games
Um certificado só é útil se o provedor conseguir mapeá-lo ao build exato que você implanta. Os títulos da CROCO são certificados por GLI, BMM, eCOGRA e iTech Labs, e produzimos o documento correspondente ao build e ao modelo de RTP específicos que você vai rodar.
A documentação matemática por título — divisão de RTP, frequência de acerto com desmembramento abaixo da aposta, cadência de recursos e probabilidade do ganho máximo — está disponível sob NDA, junto com a lista de jurisdições por trás de mais de 50 mercados ativos. Comece o papelório antes da integração, não durante a auditoria.