Raven Anticheat
RavenAnticheat
DocumentationDiscord
All detection topics
How it works

Server-side event validation: how Raven Anticheat blocks Fivem event abuse

Server-side event validation rejects events from disallowed sources, blocks event payloads outside plausible bounds, and pattern-matches event sequences against known exploits - even when every client check is bypassed.

Why server-side event validation matters

Most Fivem economy and gameplay exploits work by triggering server events that the legitimate game flow would not trigger - giving the player money, spawning items into their inventory, teleporting them, granting them vehicles. The cheat does not need to defeat the anticheat's client layer to do this; it just needs the server to accept the event. Server-side event validation is the single biggest gap between "fancy admin panel" and "actually protects the economy."

Three validation passes

Raven validates every server event in three passes. The first pass checks the event source: events that should only come from server-internal scripts are rejected when they arrive from a client. The second pass checks the event payload against plausible bounds - item quantities, money deltas, vehicle spawn rates per minute, distance teleported - rejecting and logging anything that exceeds the configured threshold for that event. The third pass runs pattern detection across event sequences, catching exploits that work by chaining several individually-legal events into one illegal outcome (the 2026-04-21 advisory describes one such Redengine pattern).

Framework-aware rule packs

Validation rules are framework-aware. ESX has its own set of economy event names and plausible bounds; QBCore has another; vRP and QBox have their own. Raven auto-detects the framework on server start (see /how-it-works/dual-layer-architecture) and ships the matching rule pack. Custom event names from server-specific resources can be added to the rule pack via the cloud panel without touching server code.

How violations are surfaced

When event validation fires, the violation is logged with full evidence (event name, payload, source player, timestamp) and the configured response runs. The response is tiered the same way as the heartbeat anti-tamper: warn, kick, or auto-ban depending on severity and the player's prior trust score. Repeat offenders are queued for promotion to the Global Ban Database after admin review.

Why this layer cannot be bypassed from the client

Server-side event validation runs on the server. A cheat running on the client cannot bypass it by patching client memory, hooking client functions, or disabling the client anticheat layer. The only way to defeat it is to send an event payload that the validation rules consider legitimate - which, by definition, is not the exploit the cheater wanted to perform. This is why server-side validation is the foundation of any serious Fivem anticheat and why our /vs/phoenix comparison gives Phoenix credit specifically for its server-event focus.

Frequently asked questions

What is server-side event validation in a Fivem anticheat?

Server-side event validation rejects server events that come from the wrong source, carry implausible payloads, or chain into known exploit patterns. Because the validation runs on the server, it cannot be bypassed by patching the client.

Does Raven Anticheat protect against money exploits and item duplication?

Yes. Event payloads carrying money deltas or item-quantity changes are validated against framework-aware plausible bounds. Anything outside the bounds is rejected and logged with evidence; repeat violations escalate to auto-ban.

Does this work with custom resource events?

Yes. The validation rule pack ships with framework defaults for ESX, QBCore, vRP, and QBox, plus a custom-event editor in the cloud panel where server admins can add their own event names and plausible bounds without touching server code.

Want this protecting your server?

Two-minute install. ESX, QBCore, vRP, QBox auto-detect. $100 lifetime.