Monero (XMR) Blockchain v6.1.6

Release Date: August 27, 2026 Tags: CONFIGURATION, RPC, FAILOVER, DEPOSITS, MONERO, XMR, ECOSYSTEM

Overview

An environment-variable release: this changes which .env key chooses the monerod the addon talks to.

XMR_MAINNET_RPC — or XMR_STAGENET_RPC / XMR_TESTNET_RPC, whichever matches XMR_NETWORK — now drives every daemon call, accepts a list of daemons to fail over between, and moves monero-wallet-rpc to whichever one is answering.

If you have never set that key, nothing changes and there is nothing to do. XMR_DAEMON_RPC_URL is still the default and still behaves exactly as it does today.

If you have set it, read Upgrade Notes before you update. Until this release nothing in the Monero service read it — it lit the RPC indicator on the admin ecosystem overview and did nothing else — and on upgrade it takes over silently, taking monero-wallet-rpc, deposit crediting and withdrawal fee estimation with it.

Requires Core v6.7.3.

Update Instructions

# 1. Update the addon in Admin → System → Extensions
# 2. Restart the backend
pnpm updator

Check your .env before you restart — see Upgrade Notes. No schema change, no seeder, nothing to repair.

Upgrade Notes

Check XMR_<NETWORK>_RPC before you upgrade

Until this release nothing in the Monero service read XMR_MAINNET_RPC. It drove exactly one thing: the RPC indicator on the admin ecosystem overview. Anyone who filled it in to turn that indicator green, or parked a public node or a placeholder in it, will find it silently taking over the moment they upgrade — it replaces XMR_DAEMON_RPC_URL for every daemon query, and on the first call that succeeds the platform tells monero-wallet-rpc to follow it too, marking it trusted and handing it XMR_RPC_USER and XMR_RPC_PASSWORD as the daemon login. Wallet syncing, deposit crediting and withdrawal fee estimation all move with it. A placeholder that was harmless yesterday becomes the node your customers' deposits depend on.

• Check your .env for XMR_MAINNET_RPC — or XMR_STAGENET_RPC / XMR_TESTNET_RPC, whichever matches XMR_NETWORK — and for XMR_MAINNET_RPC_FALLBACK.
• If the key is not set, do nothing. XMR_DAEMON_RPC_URL keeps working unchanged.
• If it is set to anything other than the monerod you actually run, either remove it or point it at the same daemon as XMR_DAEMON_RPC_URL, then restart the backend. Leaving a stale value in place sends all Monero daemon traffic there and repoints monero-wallet-rpc at it, stalling deposit crediting and withdrawal fee estimation.
• Every URL you leave in that key must be the full JSON-RPC address including the /json_rpc path.
• The admin chain-requirements screen and the Monero documentation both still describe XMR_<NETWORK>_RPC as display-only and say the service reads only XMR_DAEMON_RPC_URL. Neither was updated, and both are now wrong.

Added

More than one monerod, with the wallet process dragged along

XMR_MAINNET_RPC now accepts a list rather than a single address — comma separated, in preference order, as many daemons as you care to name. Duplicates are dropped, and anything that is not http:// or https:// is discarded.

Moving the wallet process is the point of it. Deposit scanning never asks the daemon anything; it asks monero-wallet-rpc. Without the second half the platform would report the chain healthy from a fallback daemon while monero-wallet-rpc sat on the dead one, unable to sync, and deposits would quietly stop being credited.

• Added failover across the daemons named in XMR_MAINNET_RPC (or the stagenet/testnet spelling matching XMR_NETWORK). When the daemon in use stops answering, the addon moves to the next one and immediately tells monero-wallet-rpc to follow it. That instruction is only issued when the daemon actually changes.
• A daemon that answers with a JSON-RPC error has answered — the fault is in the request, not the node — so the call is not replayed against every other endpoint in the list.
• Two things ask the daemon anything: the health check at startup, and the fee estimate taken when a customer withdraws. A monerod that dies while the platform is running is therefore noticed, and failed over, at the next withdrawal or the next restart.

Changed

Which key selects the Monero daemon

• Changed the daemon connection to be configured with XMR_MAINNET_RPC and XMR_MAINNET_RPC_FALLBACK (or the stagenet/testnet spelling, following XMR_NETWORK). When either holds an http:// or https:// address it replaces XMR_DAEMON_RPC_URL for every daemon query — the old key is not tried at all, not even as a fallback.
• A ws:// value is not taken, and XMR_DAEMON_RPC_URL continues to be used.
• On its own, XMR_DAEMON_RPC_URL still behaves exactly as before: one attempt against the same daemon, the same errors, byte for byte. The newer key ships in no example configuration, so an installation that never set it by hand is untouched by this release.