How do you plan on doing that, if current bad people can see and replicate what you send C->S. In fact, there is a tool in the client console that does exactly that! (showing the events, not the contents).
The most secure (and imo the only correct way) is to secure the events server-side, so clients can’t just trigger events however they want.
For example, here is an event that I use for a racing script, that gets triggered by the client whenever they reach a checkpoint in a race.
Here, I only give the server the checkpoint ID, then
- I check if the player is actually in a tournament.
- I Check if the player if actually racing, and if the race is not finished.
- Then I check if the checkpoint that the client thinks it reached, is the same checkpoint that the server expects the client to reach.
- Only then, I consider the event valid.
You can go even further than this and check server-side for the player’s coords, to make sure that they triggered the event in the correct place. And even save the time between checkpoints server-side to check for speed boosts.
This is how you should structure your scripts. Use the client for UI and gameplay related stuff, but only trust the server data when it comes to things like XP, money, or progression.
If you only use the server to save / load stuff (like how some frameworks used to do, and how many job resources still do to this day), then you only invite bad actors to take advantage of your server. The client should only request stuff, not decide on it.
Scrambling events can help, but not that much, since they can see whenever the event is triggered and corelate that to what the event does.
If the user receives $5000 at the end of the job, and the event viewer shows
TriggerServerEvent("N(_)V*$WngrHG(*7)GRE", 5000)
, you you exactly what it did.