How should FiveM money scripts prevent duplication?

Most money dupes aren't clever exploits; they're race conditions. Two operations touch the same balance at nearly the same moment, each reads the pre-change value, and both write — creating money out of a gap that had nothing to do with hacking. The fix is atomicity: a single SQL statement that checks and updates the balance together, such as `UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?`, then checking the affected row count, closes the window that a select-then-update-in-Lua pattern leaves open.

The second failure mode is the crash: a transfer is really two writes — debit one account, credit another — and if the server process dies between them, money is created or destroyed with no exploit involved. Wrapping both writes in a database transaction, and writing an append-only ledger entry alongside every mutation, is what makes that failure recoverable: a reconciliation query comparing the sum of ledger entries to the stored balance turns "the economy feels inflated" into a specific, attributable discrepancy instead of a mystery.

The rule that prevents nearly everything else: the client may ask, never tell. Prices, rewards, and amounts are computed and looked up server-side; a client-supplied amount reaching a database write is the single most common root cause of duplication in commercial FiveM economy scripts. Testing this directly — firing a burst of concurrent transfers at a single balance and confirming exactly one succeeds, then killing the server mid-transfer repeatedly and confirming zero reconciliation drift — is the only way to know a script's ledger holds up rather than assume it does.

Vice Drip's banking product, MoneyTrail, is built around this same pattern: atomic balance updates and an append-only ledger. It remains in development, with no runtime proof published — pending Shadow bench — and no purchase path today.