Skip to content
SCULKANTICHEAT
Sign up
FiveM documentation§8 Frameworks (ESX, QBCore & More)
  1. 1Getting Started
  2. 2Installing the Resource
  3. 3Configuration
  4. 4Commands & Permissions
  5. 5In-Game Admin Panel
  6. 6Rollout Planning
  7. 7Event Policy Worksheet
  8. 8Frameworks (ESX, QBCore & More)
  9. 9Entity Incident Playbook
  10. 10Staff Review Workflow
  11. 11Migrating from Another Anticheat
  12. 12Plans, Billing & the Hard Stop
  13. 13Troubleshooting

Elsewhere

§8

Frameworks (ESX, QBCore & More)

How Sculk's policy model applies to ESX, QBCore, QBox, vRP, and custom FiveM frameworks — what carries over and what to inventory per framework.

On this page5 entries

Sculk FiveM has no framework dependency. Its detections read engine state and game events — entities, explosions, movement, weapons, health — which are the same under ESX, QBCore, QBox, vRP and fully custom stacks, so no framework is "unsupported". The one framework-aware check, antiMoneyInjection, watches the money/cash/bank shape ESX and QBCore mirror to players. Where frameworks differ is their server events, and Sculk does not police those by name: the inventory below is for hardening your own handlers and choosing honeypot traps (Config.ExtraHoneypots) — each framework has known hot spots worth inventorying first.

§8.1ESX

Priority inventory:

  • Money paths — the classic society/account deposit, withdraw, and transfer events, plus anything a custom job script adds on top. ESX economies are usually drained through job-society events, not the core wallet.
  • Job grants — setJob-style flows and boss-menu actions. Policy: who may promote, from which context.
  • Shops and inventories — most ESX servers run third-party inventory resources (ox_inventory and friends); include their events in the inventory, not just core ESX ones.

ESX servers migrating from signature-based tools: your old config told you which menus to fear; the worksheet asks which events move value. See Migrating from Another Anticheat.

§8.2QBCore / QBox

Priority inventory:

  • Callbacks and server events with money side-effects — bank, cash, and crypto adjustments live in more places than the core functions; job resources add their own.
  • Item metadata — duplication via crafting/stacking metadata is the QBCore-specific classic. Validating the exact item and metadata shape in your own handlers matters more here than anywhere.
  • Job and gang state — grade changes and boss actions deserve permission-context rules.

QBox largely mirrors QBCore's shapes; treat its bridge layers as extra resources to inventory rather than a separate model.

§8.3vRP and custom frameworks

The model is identical — only the naming is yours. Budget a little more time for Step 1 of Rollout Planning, because nobody has pre-mapped your event surface for you. Custom frameworks actually end up with the tightest policies: no legacy events you're afraid to touch.

§8.4What does not vary by framework

  • Entity and world integrity (spawns, explosions, ownership) — native layer, framework-independent.
  • Player-state signals (movement, health, weapons) — native layer.
  • Staff review workflow — process, not code.

§8.5The honest limits

A framework bridge can rename or wrap events faster than any vendor's default list can track — which is exactly why Sculk ships a policy worksheet instead of pretending a universal config exists. If a resource you rely on has unusual event patterns, bring it to support; mapping odd resources is a normal support ticket.