StormyCloud (xmr.stormycloud.org)

StormyCloud is one of the few public Monero node operators whose day job is literally running privacy infrastructure — which is exactly the kind of operator you want when you can't run your own node and have to trust someone else's.

Background StormyCloud operates public infrastructure across multiple privacy networks (Tor and I2P) and runs a widely-cited public Monero remote node at `xmr.stormycloud.org`, used as a default by several wallets. Mainnet, with an I2P endpoint for clients that prefer to reach it without touching clearnet.

What you trust A remote node is a real but bounded trust decision. It cannot see your private keys, spend your funds, or decrypt your amounts and recipients — Monero's privacy holds at the node level. What it *can* observe is your IP address and the timing of the transactions your wallet broadcasts/queries, which is a metadata-linkability risk. StormyCloud's I2P endpoint (and Tor more broadly) is the mitigation, and a privacy-focused operator's incentives are better-aligned than a random node's.

Operational specs Public Monero RPC node, mainnet, reachable over clearnet and I2P. Serves the standard wallet flows as a default for users who haven't set up their own node. Operated by an entity whose broader mission is privacy-network infrastructure.

Philosophy Shared, privacy-aligned infrastructure exists so that the majority who won't run a full node still get a sane, non-hostile default instead of an unknown logger. StormyCloud's multi-network presence makes it a coherent choice for users who already route through Tor/I2P.

Grade rationale Grade A. A reputable, privacy-mission operator with an I2P endpoint and broad wallet adoption — about as good as a *remote* node gets. It is graded as an excellent default, with the standing caveat that any remote node is a metadata trade-off versus your own.

Useful when You can't or won't run your own node; you want a default operated by a privacy-focused org; you route over I2P/Tor and want a matching node endpoint; you need a reliable fallback node.

Caveats A remote node sees your IP and tx-broadcast timing — connect over Tor/I2P, not bare clearnet, to blunt that. Running your own node is strictly more private and is the end-goal; a public node is the pragmatic interim. Trust in any "no logs" posture is ultimately a trust assumption — reputable, but unverifiable from the outside.