Every FiveM anticheat vendor claims framework-agnostic support. The reality is that ESX, QBCore, vRP, and QBox each have their own conventions, and the configuration that works cleanly on one can produce false positives on another. Here is what changes between them and what to actually configure.
The shared setup, before framework-specifics
Whichever framework you run, the anticheat resource itself drops into the same place. Add the resource folder under resources/, then add it to your server.cfg:
# Start your anticheat early so it is loaded before framework resources
ensure rac
ensure es_extended # or qb-core, qbx_core, vrp, etc.
ensure ...your other resourcesOrder matters. If the anticheat starts after framework events are registered, the first few seconds of every player connect window are unprotected. Most modern FiveM anticheats handle this with auto-detection on startup, but if you are setting one up by hand, this is the single most important detail.
ESX-specific gotchas
Server events with global handlers
ESX broadcasts a lot of events through esx:* handlers. Many community scripts hook into esx:onPlayerJoined or esx:setJob, which means the same event can be fired by dozens of different resources. Aggressive event-rate detection can flag a busy login window as suspicious.
The fix: most anticheats let you whitelist specific event names from rate-limit detection. For ESX servers, whitelist esx:onPlayerJoined and the framework's known broadcast events. Do not whitelist economy events like esx:giveMoney - those are exactly the ones you want monitored.
Inventory event calls
Older ESX inventory implementations (esx_inventory, esx_inventoryhud) use client-side TriggerServerEvent calls for moves and drops. The new ox_inventory does this server-side and is much safer. If you are still on a legacy ESX inventory, expect to see more inventory-related event traffic in the anticheat logs and be prepared to triage false positives.
QBCore-specific gotchas
Player metadata events
QBCore relies heavily on QBCore:Server:UpdatePlayer and QBCore:Player:SetPlayerData to keep state in sync. Both fire frequently during normal play. Some anticheats classify high-frequency state-update events as suspicious by default - you may need to tune the threshold up or whitelist these specifically.
The QBCore:GetObject export
QBCore exposes QBCore:GetObject as a client-side export that returns an object with player data and methods. Cheats sometimes call this to read player state for visualization. If your anticheat scans for client-side calls to framework exports, expect false positives from legitimate UI scripts that also call this - most are HUDs and admin tools.
vRP / QBox-specific gotchas
vRP uses a proxy-based event model that makes it harder to whitelist by event name. Most modern anticheats handle vRP-specific event patterns out of the box, but if you are running a heavily customised vRP setup, expect to spend an afternoon tuning per-event thresholds.
QBox is the modern successor to QBCore and shares most of its event surface, but the resource manifest format and event naming have small differences. Anticheats that auto-detect framework on startup usually identify QBox correctly; ones that key off resource names alone may misidentify it as QBCore and use slightly wrong defaults.
The settings to always check
Whichever framework you run, audit these specific config values before going live:
- Event rate limits. The default may be tuned for a specific framework. If you run a different one, expect to raise or lower the threshold based on observation.
- Whitelisted event names. Add framework-broadcast events here, never economy or inventory events.
- Trust score recovery rate. Defaults assume average playtime. If your server has long sessions or short ones, the trust score curve may need adjusting.
- Position-delta thresholds. Vehicle-heavy servers (especially racing or PvP modes) produce higher legitimate position deltas. Default thresholds are tuned for RP and may false-positive on speed.
- Resource exception list. Some custom resources (admin menus, debug tools) trigger detections. Add them to the exception list with admin-only grants, not server-wide ones.
Auto-detection vs manual config
The strongest anticheats auto-detect ESX, QBCore, vRP, QBox, and Standalone on startup and apply framework-aware defaults. Raven Anticheat does this from the resource manifest scan; some others read framework exports at runtime. If your AC requires you to manually pick a framework in a config file, you are doing work the product should be doing for you, and you are also likely to misconfigure when you upgrade frameworks.
The practical takeaway: pick an AC that auto-detects, run observation mode for 24 hours, audit the noise that comes out, tune the few framework-specific thresholds, and only then enable enforcement. Skip any of those steps and you will spend the next two weeks in your appeals channel.