Item and currency duplication usually comes from business logic flaws, not memory hacks. Two requests arrive at nearly the same moment, both pass a check, and both succeed. The fix is to make each economy operation atomic on the server, idempotent when repeated, and visible in an audit log so abuse shows up quickly.
How a duplication bug happens
Imagine a trade endpoint. It reads the player's inventory, confirms they own the item, grants the item to the other player, then removes it from the sender. If a second identical request arrives between the check and the removal, both requests see the item present. The item is granted twice.
The same pattern appears in withdrawals, gift codes, daily rewards, marketplace listings and refunds. The OWASP Web Security Testing Guide lists business logic testing as its own area, including process timing and the number of times a function can be used. Those are the categories where economy bugs live.
Design rules that prevent most of it
Make the operation atomic. Do the check and the change inside one database transaction, with locking or a conditional update that fails if the state is no longer what you expected. For example, remove the item with a statement that only succeeds if the item still belongs to the sender, and grant only if that succeeded.
Make it idempotent. Give each operation a unique ID created for that action. If the same ID arrives again, return the first result instead of doing it twice. This also protects you from network retries.
Keep a single source of truth. If several services hold copies of inventory, a trade can succeed in one and fail in another. Pick one owner for each piece of state.
Use a ledger. Record each change as an entry: who, what, how much, why, before and after. A ledger makes duplicates detectable by reconciling totals.
Limit one time items. One use codes and rewards need a unique constraint, so the database rejects the second redemption even when the application code misses it.
Test for it
Send the same request many times at once against a test environment and see whether state stays correct. Test trades, purchases, withdrawals, redemptions and refunds. Test cancellation halfway through a multi step flow. Test retrying after a timeout.
The WSTG test pages on business logic describe the approach of checking how many times a function can be used and what happens when steps are repeated or reordered.
Detect it in production
Log suspicious business activity, such as exceeding action limits or bypassing workflow steps. OWASP's logging guidance lists those among events worth recording. Then build simple alerts:
- Total supply of a currency or item type that grows faster than your sources explain.
- Many identical operations from one account within a second.
- A new account that suddenly holds rare items.
Respond calmly
When you find a duplication exploit, fix the flaw first, then decide how to correct the economy. Rolling back everyone punishes players who did nothing wrong, so use your ledger to identify and reverse only the duplicated items where you can.
Quick checklist
- Wrap check and change in one transaction.
- Add idempotency keys to every economy call.
- Add unique constraints for one time rewards.
- Reconcile totals daily.
- Run a concurrency test before each release that touches the economy.
Safeguard does not find economy logic flaws. It can scan the libraries around your services and enforce policies and gates in your pipeline. Free scan: https://gold.safeguard.sh/scan.
Quick check
What is the simplest defence against a trade race condition?
Make the ownership check and the transfer a single atomic operation, so a second request cannot pass the same check.
Sources
Last reviewed: 19 October 2026.
