{
  "version": "v1",
  "slug": "receive-xmr-privately",
  "title": "How to receive XMR privately",
  "description": "Subaddresses per payee, view-key disclosure trade-offs, integrated addresses, and the receive-side mistakes that link your payments together on chain.",
  "intro": "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_plain": "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",
  "body_html": "\n      <section>\n        <h2 class=\"section-h\">Why receive-side matters</h2>\n        <p>Sender privacy on Monero is provided by the protocol: ring signatures, stealth addresses, confidential amounts. Receive-side privacy is provided by <em>your wallet hygiene</em>. 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.</p>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">Use a new subaddress per payee</h2>\n        <ol class=\"bullet-list\">\n          <li><strong>One subaddress per relationship.</strong> Wallet → \"New subaddress\" → label it (\"ACME payroll\", \"OTC desk\", \"Mom\"). Hand each party a distinct one.</li>\n          <li><strong>Never reuse</strong> a subaddress that's been shared publicly (forum post, donation page) for a private payment. Treat public-facing addresses as one-way mailboxes.</li>\n          <li><strong>Subaddresses cost nothing</strong> to generate. Generate as many as you want. They all sweep into the same wallet balance.</li>\n        </ol>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">View-keys: handle with care</h2>\n        <ul class=\"bullet-list\">\n          <li><strong>Private view key</strong> = ability to see all incoming transactions for a wallet (but not spend). Useful for accountants / auditors / disclosing to a counterparty. <strong>Once disclosed, you can't take it back.</strong></li>\n          <li><strong>Public view-key proofs</strong> let you prove a specific tx exists without revealing the whole wallet — use <code>get_tx_proof</code> for one-off receipts (refunds, customer-support disputes).</li>\n          <li><strong>Don't paste the view key into a block-explorer field</strong> on the clearnet — the explorer operator now has it. Use a self-hosted node or a privacy-respecting explorer.</li>\n        </ul>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">Integrated addresses (legacy, mostly obsolete)</h2>\n        <p>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.</p>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">Receive-side checklist</h2>\n        <ol class=\"bullet-list\">\n          <li>Use a wallet that supports subaddresses (every modern wallet — see <a href=\"/guides/pick-a-monero-wallet\">wallet picker</a>).</li>\n          <li>Generate a fresh subaddress per counterparty. Label it.</li>\n          <li>Sync your wallet against a <strong>remote node over Tor</strong>, or your own node — public clearnet nodes can correlate your IP with the subaddresses they serve scans for. (<a href=\"/guides/tor-for-crypto-safely\">Tor setup →</a>)</li>\n          <li>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.</li>\n          <li>Never publish your <strong>primary address</strong> (the one ending in unique suffix) — always a subaddress.</li>\n        </ol>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">Mobile wallets — extra caveats</h2>\n        <ul class=\"bullet-list\">\n          <li>Mobile wallets default to remote nodes for speed. Pick one that lets you set a Tor remote node (<a href=\"/wallets/cake-wallet\">Cake</a>, <a href=\"/wallets/monerujo\">Monerujo</a>).</li>\n          <li>Push-notification \"incoming TX\" features almost always run via a centralized server with your view key — disable unless you accept the trade.</li>\n          <li>Background sync over cellular leaks timing — consider syncing only on a known network.</li>\n        </ul>\n      </section>\n\n      <section>\n        <h2 class=\"section-h\">Receiving wallets — picks</h2>\n      </section>\n    ",
  "picks": [
    {
      "category": "wallets",
      "id": "feather",
      "name": "Feather",
      "url": "https://xmr.club/wallets/feather",
      "markdown_twin": "https://xmr.club/llm/wallets/feather.txt",
      "why": "Desktop XMR wallet. Subaddress UX + Tor + view-key tools built in."
    },
    {
      "category": "wallets",
      "id": "cake-wallet",
      "name": "Cake Wallet",
      "url": "https://xmr.club/wallets/cake-wallet",
      "markdown_twin": "https://xmr.club/llm/wallets/cake-wallet.txt",
      "why": "Mobile (iOS/Android). Subaddress labels + Tor remote node."
    },
    {
      "category": "wallets",
      "id": "monerujo",
      "name": "Monerujo",
      "url": "https://xmr.club/wallets/monerujo",
      "markdown_twin": "https://xmr.club/llm/wallets/monerujo.txt",
      "why": "Android XMR wallet. Coin-control + subaddress per payee."
    },
    {
      "category": "wallets",
      "id": "monero-gui",
      "name": "Monero GUI",
      "url": "https://xmr.club/wallets/monero-gui",
      "markdown_twin": "https://xmr.club/llm/wallets/monero-gui.txt",
      "why": "Official desktop wallet. View-key + tx-proof tooling for disclosures."
    }
  ],
  "url": "https://xmr.club/guides/receive-xmr-privately",
  "markdown_twin": "https://xmr.club/llm/guides/receive-xmr-privately.txt"
}