Saving while a hold is open loses the held money

TryHold debits immediately and hands back a token. A save captures balances only, so a snapshot taken while a hold is open records the already-reduced balance and nothing records the token that would have returned it. Load that file and the money is gone — not refunded, not still held, because the hold does not exist in the loaded process.

This is not a limitation of one save component. No currency persistence surface carries hold state, because a hold is keyed by a runtime token and an owner GameObject, and neither survives a reload.

If your game can save while a hold is open — a timed shop reservation, a pending trade — resolve holds before saving: Commit them, or Release them so the amount returns to the wallet the snapshot then captures.

A currency left out of a save used to be free money

CurrencyPersistence.Capture writes one line per id it is handed and nothing else — it cannot know what it was not told about. Every caller therefore worked from a curated list, and naming only some of the currencies was worse than it looked: an unlisted one was neither written to the save nor set by a restore, so its balance simply survived a load. Spend a premium currency on an item, load an earlier save, and the item is gone but the money is back. Both operations reported success.

ICurrencyWalletQuery.TryGetHeldCurrencies is what makes the question answerable, and both shipped save paths — CurrencyJsonSave and the save system's CurrencySaveParticipant — now capture the configured ids plus whatever each wallet actually holds. The configured list is still a floor rather than a fallback: a wallet has no entry for a currency it has never held, so only the list can write one at zero, and that line is what lets a restore put a wallet back to zero.

CurrencyPersistence.Capture itself is unchanged and still captures exactly what you pass it. A service that cannot enumerate answers "cannot tell", never "holds nothing", and the callers fall back to their configured ids alone.

WalletSnapshot cannot be saved with JsonUtility — it looks like it can

Everything points the obvious way and the obvious way does not work. The type is [Serializable], it is documented for save/load, and its backing field name is deliberately kept stable for JsonUtility. But WalletSnapshotLine is a readonly struct with readonly fields, and Unity's serialiser skips readonly fields entirely.

So a round trip gives you the right number of lines with every field at its default. The save looks correct written to disk, and the load fails with Invalid snapshot line — and because CurrencyPersistence.Restore validates a whole snapshot before applying any of it, that single defect refuses every balance in the wallet, not just the line that caused it.

[Serializable] does not save you here: it makes the container serialisable, not its readonly contents.

Flatten to your own type, converting each CurrencyId to a string. Both shipped save paths do exactly that — CurrencyJsonSave and the save system's CurrencySaveParticipant each keep a private line DTO for it. If you are writing your own persistence, copy that shape rather than assuming this has been fixed; immutability is the right design for a captured value and is staying.

Currency does not guarantee

• ❌ True multi-operation atomicity across decorators
• ❌ Network replication
• ❌ Server authority enforcement
• ❌ Deterministic rollback across policy + authority + idempotency
• ❌ Automatic escrow integration (must compose explicitly)
• ❌ Cross-scene ownership safety. Wallets are keyed by GameObject; persistence maps owners via StableId.Id. Adding a StableId is necessary but not sufficient — it is stable for scene-authored objects only. A runtime-spawned object gets a different id every launch unless you call StableId.AssignId with a durable value, and duplicating an object copies its id, so two wallets can claim one identity. The Save system's guarantees matrix carries the full identity contract; Tools ▸ RevGaming ▸ RevFramework ▸ Validate ▸ Duplicate Stable Ids finds collisions.
• ❌ Strong transactional guarantees under arbitrary decorator reorder
• ❌ A WalletSnapshot that survives JsonUtility — its lines are readonly structs, which Unity skips; flatten to your own type, as both shipped save paths do. See §10.

It is not

• A database
• A networking framework
• A financial-grade ACID system