Monero privacy
Structural privacy, not a toggle
Monero obscures sender, receiver, and amount at the protocol layer: CLSAG ring signatures with mandatory decoys break input linkability, dual-key stealth addresses generate one-time outputs for receivers, and RingCT/Bulletproofs hide values while preserving balance. Electrum XMR follows these rules verbatim—there is no transparent path to fall back on.
Protocol pillars
Inputs are signed with CLSAG ring signatures that include mandatory decoys from the UTXO set, so observers cannot know which member is the true spend. The ring size is enforced network-wide; wallets do not expose a “mixins” slider. Output destinations are one-time stealth addresses derived from the receiver’s public spend/view keys, so no published address ever appears on-chain.
Amounts are hidden with RingCT using Pedersen commitments and Bulletproofs for range proofs. Validators can prove sums balance without learning the value. Fee and size reflect the cryptographic data, but the privacy guarantees are not optional per-transaction.
What observers see
On-chain data shows encrypted commitments, a ring of candidate inputs, and one-time outputs. Observers cannot map a ring member to the spender, cannot read the amount, and cannot map an output to a public address. Balances are only derivable with the private view key; there is no “address balance” endpoint.
Network-side, a remote node can see timing, IP metadata, and the fact you are scanning, but not your keys or balances. Using your own node reduces metadata leakage; Tor/VPN can further obfuscate path information. Electrum XMR never sends seeds or spend/view keys; view-key scanning is local.
How the wallet keeps it
Electrum XMR adheres to consensus defaults: mandatory ring size, stealth outputs, and RingCT on every spend. There is no transparent send path. View-key scanning, proof creation, and subaddress derivation are local; telemetry is absent. Node choice defines the network metadata you expose, not the cryptographic privacy set.
Restore height controls scan scope; pick a height near first use to cut sync time without losing coverage. Use subaddresses to separate contexts—on-chain they remain unlinkable. When you need attestations, generate payment proofs locally; sharing them is an explicit act.
Good practice
Run your own node when possible. If using a remote node, assume it observes timing and IP; add Tor/VPN to reduce correlation. Keep seeds offline and tested; do not store them in synced notes. Rotate subaddresses for invoices and counterparties—no on-chain linkage is created, but your local labels keep you organized.
Share a view key only when you intend audit visibility; prefer a view-only wallet export. Avoid screenshots or logs that capture addresses, timestamps, or node endpoints. Treat every convenience feature (clipboard history, cloud sync) as a potential leak path for keys.