Skip to content

ESX, QBCore & Frameworks

Sculk FiveM works at the event layer, which every framework shares: ESX, QBCore, QBox, vRP, and fully custom stacks all move money, items, jobs, and world state through server events. Policy is written against your event names, so no framework is "unsupported" — but each has known hot spots worth inventorying first. ESX and QBCore are the reference environments the early-access build is tested against.

ESX

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 grantssetJob-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.

QBCore / 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. Payload policy (exact item + metadata shape) 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.

vRP 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.

What 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.

The 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 early-access ticket.