Event Policy Worksheet

Server events are where FiveM servers get robbed. A client that can trigger yourshop:buyItem with an arbitrary payload doesn't need a mod menu to drain your economy — it needs one TriggerServerEvent. Policy means writing down, per event, what a legitimate call looks like so anything else becomes an incident.

The worksheet

For every event on your inventory list (from Rollout Planning), answer five questions:

1 · Who may call it?

Job, gang, ace permission, admin group — whatever your framework uses. "Anyone" is a valid answer for genuinely public events, but write it down deliberately rather than by omission.

2 · What does a legitimate payload look like?

Types, ranges, and identifiers. If amount should never exceed 5,000 or go negative, that's policy. If itemName must exist in your items table, that's policy. Most economy exploits are payloads a developer never imagined, sent to an event that trusted the client.

3 · What has to happen first?

Real players follow call paths: you can't sell a car you haven't entered, can't withdraw from a register you haven't opened. Note the expected preceding events — impossible sequences are among the strongest abuse signals because legitimate clients simply don't produce them.

4 · How often can it legitimately fire?

Per player, per minute. A shop purchase every second is a script, not a shopper. Rate expectations catch grinding exploits that pass every other check.

5 · What should happen on exception?

Block, flag, or review-first — per event, not globally. Money-creating events usually justify block after observation; ambiguous ones deserve review.

Example policy entry

event: bank:withdraw
callers: any player with an open session at a bank zone
payload: amount: integer 1..10000, account: owned by caller
sequence: requires bank:openSession within last 5 minutes
rate: max 6/minute per player
on-exception: observe for 2 weeks, then block + incident

Keep entries this short. A policy nobody can read is a policy nobody maintains.

Common mistakes

• Trusting the client's identity claims. Permission context comes from the server's own state, never from the payload.
• Writing policy for cheaters instead of for the event. You don't need to imagine every attack; you need to describe legitimate use precisely. Everything else is the exception path.
• Blocking on day one. Observation first — see the rollout guide. Your restart sequence will fire events in orders you didn't predict.

What Sculk FiveM does with this

At rollout, these entries become your protected-event configuration: the build compares live calls against caller, payload, sequence, and rate expectations, and routes exceptions into the incident stream with the context staff need to decide. The worksheet is portable — it's just your server's truth, written down.