The node, and the peers it trusts least.
We run our own daemon because the alternative is asking a stranger what the chain says. The fork is monerod 0.18.5.3 with the restricted-RPC surface from this morning’s release, and it seeds from a fixed list rather than open discovery.
Why not just use a public RPC
The monero.fail listing opens with a warning, not a feature list: there has been an influx of nodes operated by chain-analysis firms and government agencies, some of them are certainly in the directory, and it is impossible to tell which. The site’s own conclusion is that you should run your own node.
That advice applies with more force to us than to an individual user. A wallet querying a hostile node leaks one person’s activity. A coordinator querying a hostile node leaks the batch — every intent in the window, their sizes, and their relative timing, which is most of what an attacker would need to unpick the routing.
So the peers below are not a dependency, they are a cross-check. We sync from them, compare tips, and treat divergence as a reason to stop routing rather than a reason to pick a winner. Several of them are almost certainly watching. That is fine, as long as none of them is the only thing we believe.
Seed peers
Drawn from the 40 German nodes in the monero.fail directory, of which 38 were healthy and 2 had failed their last check-in. Lag is measured against the highest tip any peer in this set reported.
| Endpoint | Location | Transport | Height | Lag |
|---|---|---|---|---|
| https://node.chaoswg.dev | Germany | TLS | 3,778,298 | tip |
| https://monero-rpc.cheems.de.box.skhron.com.ua:18089 | Germany | TLS | 3,778,292 | −6 |
| http://xmr-in-berlin-2.boldsuck.org:18081 | Berlin | plaintext | 3,778,263 | −35 |
| http://5.189.143.209:18089 | Nuremberg, Bavaria | plaintext | 3,778,263 | −35 |
| http://188.166.192.175:18081 | Frankfurt am Main, Hesse | plaintext | 3,778,263 | −35 |
| http://static.63.34.245.188.clients.your-server.de:18089 | Germany | plaintext | 3,778,266 | −32 |
| https://xmr.apschneider-it.eu:443 | Germany | TLS | 3,778,254 | −44 |
| http://owl.lc:18089 | Germany | plaintext | 3,778,254 | −44 |
| http://node3.monerodevs.org:18089 | Germany | plaintext | 3,778,234 | −64 |
| http://monero.homelinux.org:18081 | Germany | plaintext | 3,778,217 | −81 |
| http://nodex.monerujo.io:18081 | Nuremberg, Bavaria | plaintext | 3,778,212 | −86 |
| http://hantaan.fullm00n.de:18089 | Düsseldorf, NRW | plaintext | 3,778,159 | −139 |
| https://mainnet.xmr.kernal.eu:18089 | Germany | TLS | 3,778,159 | −139 |
| http://atm.rabbithole2.net:18089 | Gunzenhausen, Bavaria | plaintext | 3,778,149 | −149 |
| https://xmr.privacygateway.io:443 | Düsseldorf, NRW | TLS | 3,778,082 | −216 |
| https://xmr5.doggett.tech:18089 | Germany | TLS | 3,778,082 | −216 |
Snapshot taken 2026-10-06 from monero.fail, which marks a node failing once it is unresponsive or more than 1,500 blocks behind the highest reported block. These heights are a point-in-time reading and will be stale by the time you read them — that is the point of showing the lag column rather than a green tick.
Build
Verify the upstream artifact against the signed hash list before you build anything on top of it. The hashes page is GPG-signed and the key lives in the source tree under /utils/gpg_keys.
# upstream artifact, pinned
curl -O https://downloads.getmonero.org/cli/monero-linux-x64-v0.18.5.3.tar.bz2
# expected sha256 — cross-check against the signed list
# https://www.getmonero.org/downloads/hashes.txt
echo "3333d0e04c9cbe3023e7e2b6dd369c407f36bb8df5b05fb0a19d7685b3d56dfc monero-linux-x64-v0.18.5.3.tar.bz2" \
| sha256sum --check
# restricted mode, fixed peer set, no open discovery
./monerod \
--restricted-rpc \
--no-igd \
--add-exclusive-node node3.monerodevs.org:18089 \
--add-exclusive-node nodex.monerujo.io:18081 \
--zmq-pub tcp://127.0.0.1:18083--restricted-rpc is what activates the filtering described on the overview page. Running the fork without it gives you a fast node and none of the properties this project depends on.