# How to receive XMR privately

> Subaddresses per payee, view-key disclosure trade-offs, integrated addresses, and the receive-side mistakes that link your payments together on chain.

Canonical URL: https://xmr.club/guides/receive-xmr-privately

## Overview

Monero's privacy guarantees on the sender side are strong by default. On the receive side they depend on you. The biggest leak is reusing the same address across counterparties — even on Monero, that gives whoever pays you a permanent label they can attach to all future activity. This is what to do instead.

## Body

Why receive-side matters Sender privacy on Monero is provided by the protocol: ring signatures, stealth addresses, confidential amounts. Receive-side privacy is provided by your wallet hygiene . If you hand the same primary address to your employer, a marketplace, and a friend, all three know about each other's payments to you (via a service-side ledger), and any future shared address derivation is correlatable. Use a new subaddress per payee One subaddress per relationship. Wallet → "New subaddress" → label it ("ACME payroll", "OTC desk", "Mom"). Hand each party a distinct one. Never reuse a subaddress that's been shared publicly (forum post, donation page) for a private payment. Treat public-facing addresses as one-way mailboxes. Subaddresses cost nothing to generate. Generate as many as you want. They all sweep into the same wallet balance. View-keys: handle with care Private view key = ability to see all incoming transactions for a wallet (but not spend). Useful for accountants / auditors / disclosing to a counterparty. Once disclosed, you can't take it back. Public view-key proofs let you prove a specific tx exists without revealing the whole wallet — use get_tx_proof for one-off receipts (refunds, customer-support disputes). Don't paste the view key into a block-explorer field on the clearnet — the explorer operator now has it. Use a self-hosted node or a privacy-respecting explorer. Integrated addresses (legacy, mostly obsolete) Pre-subaddress workflow used "integrated addresses" — primary address + payment ID baked into one string. Exchanges still hand these to you on deposit. They work, but subaddresses are strictly better for everything else: each subaddress is its own stealth address, doesn't require the sender to do anything special, and doesn't leak the payment ID format on chain. Receive-side checklist Use a wallet that supports subaddresses (every modern wallet — see wallet picker ). Generate a fresh subaddress per counterparty. Label it. Sync your wallet against a remote node over Tor , or your own node — public clearnet nodes can correlate your IP with the subaddresses they serve scans for. ( Tor setup → ) For public donation addresses, rotate annually. Old one stays valid; new payments go to the fresh address. Limits how much historical context any one party builds about you. Never publish your primary address (the one ending in unique suffix) — always a subaddress. Mobile wallets — extra caveats Mobile wallets default to remote nodes for speed. Pick one that lets you set a Tor remote node ( Cake , Monerujo ). Push-notification "incoming TX" features almost always run via a centralized server with your view key — disable unless you accept the trade. Background sync over cellular leaks timing — consider syncing only on a known network. Receiving wallets — picks

## Recommended picks

- [Feather](https://xmr.club/wallets/feather) · /llm/wallets/feather.txt — Desktop XMR wallet. Subaddress UX + Tor + view-key tools built in.
- [Cake Wallet](https://xmr.club/wallets/cake-wallet) · /llm/wallets/cake-wallet.txt — Mobile (iOS/Android). Subaddress labels + Tor remote node.
- [Monerujo](https://xmr.club/wallets/monerujo) · /llm/wallets/monerujo.txt — Android XMR wallet. Coin-control + subaddress per payee.
- [Monero GUI](https://xmr.club/wallets/monero-gui) · /llm/wallets/monero-gui.txt — Official desktop wallet. View-key + tx-proof tooling for disclosures.

## License

CC-BY-4.0. Attribute "xmr.club".