Design the class model and public APIs for the in-process core of a digital wallet: the object graph that owns accounts and their balances and lets a caller deposit, withdraw, and transfer money, while an immutable ledger records every movement. This is the domain kernel a service or API layer would drive, not the HTTP surface or the database.

Operating context. Many accounts live in one process, each holding one or more per-currency balances. Money is integer minor units (cents) — never floating point. A caller asks the wallet to deposit into an account, withdraw from it, or transfer between two accounts, and each such command carries a client-supplied idempotency key, because callers retry on timeout and the same logical command may arrive more than once; a replay must return the original result rather than move money twice. Some flows reserve funds first with a hold (available drops, posted balance does not), then later capture part or all of the hold or release it. Multiple threads issue commands against the same account concurrently, so balance updates must be safe under contention. A caller can also ask for an account's current balances and for a paginated statement of its past ledger entries.

Out of scope. Persistence and any database schema, network/RPC transport and serialization, authentication and authorization, currency conversion (assume same-currency transfers), and fraud or compliance scoring. Assume commands arrive already validated and authenticated; model only the in-process object graph.

What to produce. The class hierarchy (Account, Balance, the wallet/service facade, Money as a value type, ledger Entry and Transaction, Hold, and the idempotency seam), the public method signatures each class exposes, and the state transitions for a transaction (pending -> posted / failed) and a hold (active -> captured / released / expired). Be explicit about: how a transfer debits one balance and credits another as one atomic, all-or-nothing unit; how concurrent debits on the same account can never both overdraw past zero; how the idempotency key dedupes retried commands; how balances are derived from or reconciled with the ledger rather than being a lone mutable counter; and how a new command type or a new overdraft policy can be added without editing the existing money-movement code.