Anti-Dupe and Anti-Exploit

Vouchers are items, and items can be duplicated (creative copies, inventory bugs, client exploits). ProVouchers can stamp a voucher with a unique id and verify it against the database on redeem, so a copied voucher cannot be redeemed twice.

Anti-dupe is chosen per voucher, because it trades off against stacking.

Stackable or anti-dupe

Each voucher has a stackable flag:

stackable: true (the default): items carry only their voucher id, so they stack freely (within a give and across gives) and are not dupe-tracked.
stackable: false: each item is stamped with its own unique id at give time. On redeem that id is recorded; if an id is seen twice, the second redeem is a duplicate and is rejected. Because a unique id makes every item different, these vouchers do not stack.

vouchers/reward.yml

id: reward
item:
  material: PAPER
stackable: false   # stamp each item, catch duplicates (these will not stack)

The reason for the trade-off is simple: a dupe glitch makes a byte-for-byte copy of an item, so anything unique enough to detect a copy is also unique enough to stop the item from stacking. Use stackable: false for high-value vouchers, and leave the default for everything else.

How it works

When stackable: false, ProVouchers writes a unique id into the item's hidden persistent data as it is created. On redeem, the id is checked against the database:

Unseen means valid: the redemption proceeds and the id is recorded.
Already recorded means duplicate: the redemption is rejected.

A duplicated item shares the original's id, so once either is redeemed the other resolves as a duplicate. The check runs off the main thread, so it never lags the server.

Configuration

config.yml

anti-dupe:
  # When a duplicate is detected on redeem, remove the item instead of returning it.
  remove-on-discovery: true
  warning:
    # When a returned duplicate is detected, append a warning line to its lore.
    enabled: false
    text: "<red>This item has been duplicated"
  notify:
    # Alert staff (provouchers.notify) when a duplicate is caught.
    enabled: true

remove-on-discovery: true (default) destroys a duplicate voucher when it is caught, so it cannot be passed around and tried repeatedly.
remove-on-discovery: false returns the item to the player and refuses to redeem it. With warning.enabled: true, the returned item also gets a lore line marking it as duplicated, which helps against resale scams.

Staff alerts

Players with the provouchers.notify permission receive a chat alert when a duplicate is detected, including who attempted it, which voucher, and the world. Turn the alert off with anti-dupe.notify.enabled: false, or change its wording by editing the staff.duplicate-alert key in your language file.

Built-in exploit guards

Independently of the stackable choice, ProVouchers blocks a few common abuse vectors:

Guard	Behaviour	Override
Game-mode gate	Creative and spectator cannot redeem	`provouchers.bypass.gamemode`
Item frames	Placing a voucher in an item frame is blocked	(none)
Crafting and stations	A voucher cannot be used as a crafting ingredient or placed into an anvil, grindstone, smithing table, loom, cartography table, stonecutter, or brewing stand	(none)
Inventory clones	A cloned anti-dupe item shares its id, so the copy resolves as a duplicate	(inherent)

The game-mode gate matters because creative lets players middle-click to clone items freely. Blocking redemption in creative, combined with the id check on anti-dupe vouchers, removes the easy duplication path.

Networked anti-dupe

If you run several servers, point them all at the same MySQL, MariaDB, or PostgreSQL database (see Storage). The used-id records are then shared, so an anti-dupe voucher redeemed on one server cannot be redeemed again on another.

Limits to be aware of

Protection applies only to stackable: false vouchers. Stackable vouchers are not dupe-tracked by design.
Items spawned by other means (for example a raw /give of a look-alike) are not ProVouchers vouchers and are ignored.
Anti-dupe protects redemption, not the economy your rewards grant. Pair it with sensible cooldowns and use limits.