The FiveM Economy Integrity Checklist
Most FiveM economies fail from concurrency and crashes, not hackers. This checklist gives three reproducible tests — a concurrent-transfer race, a kill-mid-transaction crash cycle, and a ledger reconciliation query — for exposing a dupe or drift in any economy script, including ours. It states our own two dated results plainly, and just as plainly states what they don't cover.
A corrupted FiveM economy usually isn't the work of an attacker. It's two legitimate transfers touching the same balance at the same instant, or a server restart landing in the middle of a write that debits one account and credits another. Either way, money gets created or destroyed, and nothing about a feature demo will show you it happened — it only shows up under deliberate stress.
The three tests below are a controlled, repeatable procedure, meant to be run against a test or staging copy of any economy script — a trial, a demo server, or your own product before you trust its balances. They are not a runtime capture on a live, populated server; that's a different, separate claim with its own methodology. These tests answer a narrower question: can the money math survive concurrency and a crash.
This is also the one place in our published research where we disclose our own results rather than only the method. Both are stated below with their dates, their exact scope, and — as plainly as the results themselves — what they don't yet cover.
Reproducible, step by step.
- 01Isolate a test accountFund it with exactly enough balance for one transfer, on a non-production database you can safely corrupt.
- 02Fire the raceSend a burst of identical, concurrent transfer requests from that account — roughly 20 at once from a script or load tool. This is also the scale of our own published result below.
- 03Count successesA sound system produces exactly one success. Record the exact number of successes and rejections; 'about one' is not a result.
- 04Reconcile the ledgerIndependently sum every ledger entry for the account and compare the total to the stored balance. The query is one SUM grouped by account — any mismatch is drift.
- 05Run the crash cycleStart a steady stream of transfers, then kill — not gracefully stop — the server process mid-stream.
- 06Restart and reconcile againRepeat the sum-versus-balance check immediately after every kill.
- 07Repeat the crash cycle multiple timesDrift compounds gradually, so a single clean cycle is weak evidence. Our own measured result (below) used ten cycles; more cycles is stronger evidence, not redundant confirmation.
- 08Publish the exact counts, the ledger size, the frameworks tested, and the dateA result with no date and no row count can't be reproduced or checked, and shouldn't be trusted as evidence — including when the result is ours.
What this measures — and what it does not.
The second column is the one that matters. A method that only advertises its reach is a brochure; the limits are what let you judge whether a result means anything for your server.
What it measures
- Whether concurrent requests against one balance produce more than one success — a dupe.
- Whether a mid-write crash creates or destroys money — drift, measured as the gap between summed ledger entries and stored balances.
- Whether a ledger exists at all that can be independently reconciled against balances.
What it does NOT measure
- Performance cost of the transfer path under load — concurrency correctness and CPU cost are different questions; see the runtime test methodology for the latter.
- Protection against a compromised database administrator or server host — this tests application-level integrity, not infrastructure trust.
- Behavior under real player load on a live, populated server — these are controlled tests against an isolated account on a test or staging environment, not a runtime capture.
What counts as a pass, and what does not.
| Criterion | Pass | Fail |
|---|---|---|
| Race test | Exactly one success out of N concurrent attempts against a single-transfer balance, with the remainder cleanly rejected rather than silently dropped or half-applied. | More than one success, or any transfer that appears in a balance change but not in the ledger, or vice versa. |
| Crash test | Reconciliation drift equals zero across every kill-mid-transaction cycle, including the first. | Any nonzero drift on any cycle. Drift on cycle one is a finding, not a fluke to retest away. |
| Reconciliation query | A single query sums ledger entries per account and matches the stored balance at every check. | No append-only ledger exists to query, or the ledger and the balance table are allowed to diverge without raising an error. |
Our own results against this method.
- Exactly two dated results exist anywhere in this catalog, both against the same product — MoneyTrail (vf_banking), currently in beta — and both are stated here in full: a 20-concurrent-transfer race test producing exactly 1 success and 0 duplicates, verified against a 584-row audit ledger symmetric on Qbox and standalone builds (measured 2026-07-05); and ten kill-mid-transfer crash cycles reconciling to drift = 0 (measured 2026-07-06).
- No other economy-relevant product in the catalog has been put through this method yet. Treat every other product — ours or anyone else's — as unmeasured on economy integrity until it has its own dated race and crash result.
- Both results come from a controlled test and staging setup, not from a runtime capture on a live, populated server. That is a distinct, still-unmeasured claim — see the runtime test methodology.
- Neither result has been independently reproduced by a third party as of this writing. Publishing the exact method above is what makes that possible.
- Reconciliation was run as a one-time measurement on each of the two dates above, not — yet — as a recurring, automated, continuously published process.
Why does concurrency break FiveM economies more often than hacking does?
Because it doesn't require an attacker. Two legitimate transfers touching the same balance at the same instant, or a restart landing mid-write, is enough on its own. Both are testable deliberately, which is the point of this checklist.
What is ledger drift?
The gap between what a transaction ledger says an account's balance should be and what the balance table actually holds. A sound system reconciles to zero drift even after repeated mid-write crashes.
Can I run this against a product before buying it?
Yes, if the seller offers a trial, a demo server, or open components. The race test and the reconciliation query take under an hour combined; the multi-cycle crash test takes longer but reuses the same setup.
Has Vice Drip run this against its whole catalog?
No. As stated above, exactly one product has a dated result. That's the honest current state, not a target description — every other economy-relevant product is unmeasured by this method today.
Published 2026-09-02 · Last reviewed 2026-09-02 · All methodology