Porque é que a validação de eventos no servidor importa
A maioria dos exploits de economia e de jogo no FiveM funciona disparando eventos de servidor que o fluxo legítimo do jogo não dispararia (dar dinheiro ao jogador, criar itens no inventário dele, teleportá-lo, dar-lhe veículos). O cheat não precisa de derrotar a camada de cliente do anticheat para isto. Só precisa que o servidor aceite o evento. A validação de eventos no servidor é a maior diferença entre «painel de admin bonito» e «protege mesmo a economia».
Três passagens de validação
O Raven valida todos os eventos de servidor em três passagens. A primeira verifica a origem do evento: os eventos que só deviam vir de scripts internos do servidor são rejeitados quando chegam de um cliente. A segunda verifica o payload do evento contra limites plausíveis (quantidades de itens, variações de dinheiro, spawns de veículos por minuto, distância teleportada) e rejeita e regista tudo o que exceda o limiar configurado para esse evento. A terceira corre deteção de padrões ao longo de sequências de eventos, apanhando exploits que funcionam encadeando vários eventos individualmente legais num único resultado ilegal (o aviso de 2026-04-21 descreve um desses padrões do Redengine).
Pacotes de regras conscientes da framework
As regras de validação conhecem a framework. O ESX tem o seu próprio conjunto de nomes de eventos de economia e de limites plausíveis. O QBCore tem outro. O vRP e o QBox têm os seus. O Raven deteta a framework automaticamente no arranque do servidor (ver /how-it-works/dual-layer-architecture) e entrega o pacote de regras correspondente. Nomes de eventos personalizados de recursos específicos do servidor podem ser adicionados ao pacote de regras através do painel na cloud, sem tocar no código do servidor.
Como as violações são apresentadas
Quando a validação de eventos dispara, a violação é registada com provas completas (nome do evento, payload, jogador de origem, timestamp) e corre a resposta configurada. A resposta tem os mesmos níveis do heartbeat anti-adulteração: aviso, kick ou ban automático, consoante a gravidade e o trust score anterior do jogador. Os reincidentes ficam em fila para promoção à Base de Dados Global de Bans depois da revisão de um admin.
Porque é que esta camada não pode ser furada a partir do cliente
A validação de eventos no servidor corre no servidor. Um cheat a correr no cliente não a consegue furar alterando a memória do cliente, pondo hooks em funções do cliente ou desativando a camada de anticheat do cliente. A única forma de a derrotar é enviar um payload de evento que as regras de validação considerem legítimo, o que por definição não é o exploit que o cheater queria executar. É por isso que a validação no servidor é a base de qualquer anticheat de FiveM sério.