View Key Safety: Why You Should Never Send Your Whole Monero Wallet to an Auditor

View Key Safety: Why You Should Never Send Your Whole Monero Wallet to an Auditor

Every so often someone posts the same question: “My accountant needs to verify my holdings. Can I just send them my seed phrase or my wallet file?” The answer is no, and the reason is not paranoia. It is how Monero’s credentials are structured. Handing over the wrong artifact gives the other party permanent, silent control of every future output you will ever receive. Here is what each credential actually grants, and what to send instead.

Three artifacts that get confused

People say “private key” and mean three different things. In Monero they are not interchangeable:

• The mnemonic seed (25 words). This is the master credential. Anyone holding it can spend every existing output and every future output that ever lands on any account derived from it. There is no revocation. There is no spending limit. There is no way to detect that it has been copied.
• The wallet files (keys file plus cache). The .keys file contains the spend key and view key in encrypted form, and the password you choose for it is often weaker than you think. The cache file leaks your entire transaction history, contacts, labels and notes, which the seed alone does not.
• The private view key, or a view-only wallet. This lets a third party see incoming outputs and balances, but they cannot spend, they cannot prove outgoing payments, and they cannot see where funds went after they left.

An auditor who only needs to confirm holdings needs exactly the third artifact and nothing more. An auditor who also needs to verify outgoing payments needs something different again, covered below.

Why the view key is not the whole story

A view-only wallet sees what came in. It does not see what went out. Because Monero amounts are blinded and outputs are one-time keys, a viewer cannot distinguish a genuine spend from an unspent change output. To a view-only wallet, funds that left years ago can still appear to sit in the account. This trips up accountants constantly: they reconcile a Monero view wallet against a fiat statement, the balance looks inflated, and they conclude money is missing. Nothing is missing. The view key simply cannot prove a spend.

If outgoing verification is required, the correct tool is a signed transaction proof. In the official wallet CLI, the command get_tx_proof produces a signature for a specific transaction that any third party can verify with check_tx_proof, without ever exposing keys. For a whole set of payments, get_spend_proof and check_spend_proof do the same for individual spends. This is the mechanism to use when a counterparty, exchange or auditor asks for evidence that you paid someone.

What a third party with your seed can actually do

It is worth stating plainly, because people underestimate it. With your 25 words, a holder can:

• Spend all current outputs immediately, from anywhere, with no action or notification on your side.
• Sweep funds the moment any future deposit arrives, including deposits to addresses you have already published to customers.
• Derive every subaddress and account you use, so moving to fresh addresses does not escape them.

The last point is the one that catches people who think they have a workaround. After a scare, they move funds to a “new” wallet, but if the new wallet is a subaddress of the same seed, the compromise travels with it. Restoring from the same mnemonic into a new install changes nothing. The seed is the wallet.

Practical procedure for an audit

A workable, low-risk process looks like this:

1. Create a view-only wallet from your main wallet (in the GUI: Settings, then Wallet, then Create a view-only wallet; in the CLI: generate-from-view-key or use the view key export under the same menu). Give the auditor the view-only wallet files or the view key plus address, never the spend key.
2. For each outgoing payment the auditor questions, produce a spend proof with get_spend_proof <txid> and send the signature string alongside.
3. For incoming payments under dispute, produce a transaction proof with get_tx_proof <txid> <address>.
4. If a regulator demands an attestation of balance at a point in time, export the view wallet’s balance at a stated block height and pair it with the block hash from a public block explorer so the snapshot is anchored.

None of these steps expose a spend credential. Every step produces evidence a third party can independently verify.

Common failure modes

Three patterns show up repeatedly. First, people screenshot a wallet balance and call it evidence; a screenshot proves nothing cryptographically and auditors who accept it are being negligent on your behalf. Second, people paste their seed into “verification” portals run by counterparties, which is a classic drainer setup; no legitimate verification service needs a seed. Third, people send the wallet cache file because it is “just data”, forgetting it contains the complete transaction history and address book, which may itself be commercially sensitive even where balances are not.

The one-line rule

If the other party needs to see, give them a view-only wallet. If they need to verify a payment, give them a signed proof. If anyone asks for your seed phrase, for any reason, in any wording, including “temporary”, “escrow” or “compliance”, the conversation is over. In Monero there is no such thing as read-only access to a seed.

Related reading: our earlier breakdown of ring size 16 vs 11 and what extra decoys actually buy, and the practical guide to Dandelion++ and IP protection.