Might Vaults

Might Vaults

Player vaults for Paper 1.21.11 on Java 21, stored in an embedded H2 database, with a full admin audit trail of every item that moves in or out and deliberate hardening against duplication exploits.

---

The jar is self-contained: H2 is shaded in, so nothing is downloaded at runtime.

Commands

Command	Permission	Description
/pv [number]	mightvaults.vaults.<number>	Open one of your own vaults. Defaults to vault 1. Aliases: /playervault, /pvault
/mightvaults help	mightvaults.admin	Command list
/mightvaults open <player> <number>	mightvaults.admin	Open someone else's vault. Every change you make is logged as an ADMIN_ action
/mightvaults logs <player> [number|all] [page]	mightvaults.admin	What went in and out of a vault, newest first. Hover an item to see the exact stack
/mightvaults recent [page]	mightvaults.admin	Newest activity across every vault
/mightvaults info <player>	mightvaults.admin	How many vaults a player has and where that number comes from
/mightvaults clear <player> <number> confirm	mightvaults.admin	Delete every item in one vault. Requires confirm, and logs every removed stack
/mightvaults stats	mightvaults.admin	Storage totals
/mightvaults reload	mightvaults.admin	Re-read config.yml

Aliases for the admin command: /mvaults, /pvadmin.

Permissions

Node	Meaning
mightvaults.vaults.<number>	Grants that vault and every lower-numbered one
mightvaults.vaults.*	Every vault number up to max-vaults
mightvaults.admin	Every admin command, plus access to every vault number
mightvaults.bypass.cooldown	Ignore the /pv cooldown

mightvaults.vaults.5 gives vaults 1, 2, 3, 4 and 5. This is not just a plugin-side check: at startup the plugin registers mightvaults.vaults.1 .. max-vaults with each node holding the node below it as a child, so the inheritance is real inside Bukkit's own permission engine and is visible to LuckPerms and friends.

Permissions are the only way to grant vaults. There is no per-player override, so the count is always fully explained by the config plus the player's permissions.

With the shipped config, default-vaults is 0, so a player with no permissions has no vaults.

Configuration

config.yml is commented in full. The settings worth knowing about:

• default-vaults: 0 - vaults granted with no permission at all.
• max-vaults: 100 - ceiling, and how many permission nodes get registered.
• rows: 6 - vault size (1-6). Raising it grows existing vaults; lowering it never shrinks a vault that already holds items in the upper rows, so a config change cannot delete items.
• sounds.* - the copper chest sounds, as plain registry keys. Any sound key works; block.copper_chest.oxidized_open / _weathered_open also exist if you prefer those.
• saving.mode: IMMEDIATE - see below.
• security.* - the open-time gate and the item blacklist.
• logging.* - audit detail and retention.

How duplication is prevented

Vault plugins dupe in a small number of well-known ways. Each one is closed here:

1. Two copies of one vault. There is at most one VaultSession per vault, and everyone looking at it, owner or admin, shares the exact same Inventory object. Two inventories holding the same items can never exist. By default allow-simultaneous-viewers: false goes further and refuses the second viewer outright, which also keeps the audit log unambiguous.
2. Racing the load. Concurrent open requests for the same vault are collapsed into a single load; a vault that is mid-load or mid-save is locked and every click on it is cancelled.
3. Opening a vault out of another inventory. /pv is refused while another inventory is open or while an item is on the cursor, the classic "open a GUI from a GUI" vector.
4. Crash rollback. In the default IMMEDIATE save mode the vault is written to H2 straight after every change, and H2's write delay is set to 0, so a crash cannot restore a vault to a state where its items also still exist in a player inventory. autosave-seconds is a backup.
5. Reload overtaking a write. Every database operation runs on one FIFO thread, so a re-read can never pass a pending write of the same vault. Vault rows also carry a revision that is used as a compare-and-set guard; a mismatch is logged loudly and the in-memory state (the authority) is rewritten rather than discarded.
6. Corrupt reads. A payload that fails to decode aborts the open. A vault is never presented as empty and then saved back over good data. Corruption is recorded as LOAD_FAILED.
7. Oversized stacks. Stacks above their legal maximum are split when the vault loads, which is where shift-click merge exploits land. If the split does not fit, the original stack is restored untouched - the plugin never destroys items to satisfy a limit.
8. Automation. InventoryMoveItemEvent involving a vault is cancelled, so no hopper or plugin can pipe items through one.
9. Disconnect and shutdown. Quitting closes and saves the vault, and onDisable closes every open vault (returning cursor items) before queueing the final writes and draining the database queue.

Deliberately not claimed: nothing here can stop a dupe that lives in the server, in another plugin, or in a client exploit that never touches a vault inventory.

Auditing

Every open, close, deposit, withdrawal, blocked item, admin action and load failure goes into mv_audit with a timestamp, the actor, the owner, the vault number, the quantity, and a serialised copy of the item so /mightvaults logs can show the exact stack on hover.

Item movement is derived from a net before/after comparison of the vault rather than from individual clicks, so shift-clicks, drags, hotbar swaps and stack merges are all reported correctly, and simply rearranging a vault produces no log entries.

Storage and backups

Data lives in plugins/MightVaults/data/mightvaults.mv.db (tables mv_vaults, mv_players, mv_audit, mv_meta). Stop the server before copying it.

H2 is intentionally not relocated in the shaded jar. H2's MVStore writes the fully qualified class names of its own internal types into the database file, so under a relocation the file can only ever be reopened by a jar using that exact shade prefix; no standard H2 tool could read it, and renaming this plugin's packages would orphan every stored vault. Because the package stays org.h2, any H2 2.5.x jar can open the file directly:

java -cp h2-2.5.250.jar org.h2.tools.Shell -url "jdbc:h2:file:/path/to/mightvaults" -user mightvaults

Limitations

• The database is embedded, so it belongs to exactly one server. Do not point two servers at the same file; H2's file lock will refuse the second one. A shared network setup would need a real database server instead.
• Folia is not supported (folia-supported: false); the plugin assumes a single server thread.
• storage.file is only applied at startup, not on /mightvaults reload.
• Item movement inside a vault is attributed per tick. If allow-simultaneous-viewers is turned on and two people click in the same vault during the same tick, that tick's changes are attributed to one of them.