Monero (XMR) Blockchain v6.1.7

Release Date: September 2, 2026 Tags: WITHDRAWALS, DEPOSITS, DIAGNOSTICS, RPC, DIGEST-AUTH, DOCUMENTATION, MONERO, XMR

Overview

A withdrawal release, and both halves of it move money. Every completed XMR withdrawal has been paying the customer short: the network fee was taken off the amount sent and off the platform's cut, so one fee was charged twice. A 0.01 XMR withdrawal carrying a 0.001 fee arrived as 0.009944. The customer now receives the full amount and the gas is funded from the withdrawal fee, so your XMR fee revenue drops by the network fee.

The other half bites only off mainnet: withdrawals to valid stagenet and testnet addresses could be refused as Invalid Monero address, and XMR could be missing from the deposit currency list, with nothing saying why. Validation now decodes the address and checks its checksum instead of reading its first character.

The admin chain-requirements test is fixed too — it reported 401 after Digest auth against credentials that were correct, because monerod and monero-wallet-rpc hold the Digest session on the TCP connection. Read the Upgrade Notes before updating.

Requires Core v6.7.5 and Ecosystem v6.4.9.

Update Instructions

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

No schema change and no seeder. Re-run Admin → Ecosystem → Blockchains → Requirements → Monero afterwards, and check the backend log at startup — it now prints the network monerod reports and compares it against XMR_NETWORK.

Upgrade Notes

Every completed XMR withdrawal has paid the customer short

The network fee was subtracted twice. It came off the amount sent to the customer, and the platform's cut was independently reduced by the same fee — so the customer paid the gas and the platform paid it again. A 0.01 XMR withdrawal carrying a 0.001 fee reached the recipient as 0.00994424.

The withdrawal route debits amount + withdrawalFee and nothing else, on every chain, and every other chain covers the network cost out of that fee. Monero was the one that did not.

• Fixed the customer to receive the full amount requested, with the network fee funded from the withdrawal fee — so the wallet now spends exactly what the customer was debited.
• Changed what the platform earns on an XMR withdrawal. It is the withdrawal fee minus the network fee, where it used to be the whole withdrawal fee. At current Monero fees that is a fraction of a cent per withdrawal.
• Review your completed XMR withdrawals if you intend to make customers whole. Each was short by that transaction's own network fee, which is recorded on the platform-fee entry raised alongside it.
• If the network fee ever exceeds the withdrawal fee you charge, the platform now absorbs the difference and logs a warning rather than refusing the withdrawal. Raise the XMR withdrawal fee if that warning appears.

Withdrawals refused, and XMR missing from deposits, on a stagenet or testnet install

Two symptoms with one cause: the platform's idea of which Monero network it runs on did not match the network your addresses belong to, and nothing on either path said so.

Address validation read XMR_NETWORK without trimming it, and any value it did not recognise fell back to the mainnet rules silently — so a genuine stagenet address was refused as Invalid Monero address, blaming the customer's address for a server setting. On the deposit side a currency is offered only while its token's network label agrees with XMR_NETWORK, so an XMR token still labelled mainnet on a stagenet install was dropped from the picker with nothing but a log line to explain it.

• Fixed address validation to read the network out of the address itself and to report a network mismatch as a mismatch, naming both networks, instead of as an invalid address.
• Added a startup line comparing XMR_NETWORK against the network monerod reports, so a mismatch is visible in the log before a customer finds it.
• Set XMR_NETWORK to the network monerod actually runs, then confirm it reached the process — a value already present in the environment wins over the one in your .env file, so a process manager holding an older copy keeps serving it however the file reads. pm2 restart <app> --update-env forces a re-read. The new startup line prints what the process actually resolved.
• If XMR is missing from the deposit currency list, open Admin → Ecosystem → Blockchains → Requirements → Monero. The new token-network row names the currency and the two values that disagree. Correct whichever side is wrong — the XMR token's network field, or XMR_NETWORK.

A Monero row that was red may simply turn green

If the requirements test has been telling you XMR_RPC_USER / XMR_RPC_PASSWORD are wrong while deposits credited normally, the credentials were never wrong and there is nothing to repair — re-run the test after updating.

If it still reports a rejection after this release, read which of the two it now names. "rejected user …" means the service judged the pair and refused it, and the fix is in --rpc-login. "challenge marked stale" means the pair was accepted and the connection was the problem: something between the backend and the service — a reverse proxy, a load balancer, a tunnel that drops idle connections — is not keeping the challenge and the answer on one connection. The addon's own calls fail through that path too, so that one is a real fault.

Every daemon in XMR_<NETWORK>_RPC is now probed

If you named more than one daemon in 6.1.6, the test used to probe a single address. It now probes them all and reports any that are unreachable, unsynchronised or on a different network. Those daemons were already in use by the running platform; only the reporting has caught up, so a newly red row is describing a fault that predates this release.

Fixed

The network fee taken from the customer and from the platform at once

A Monero transfer pays its fee on top of the destinations, out of the sending wallet — so a withdrawal has to decide who funds it. This one charged it to both sides: the recipient's destination was set to amount - networkFee, and the platform's cut was set to withdrawalFee - networkFee.

The result was a wallet that spent amount + withdrawalFee - networkFee against a customer debit of amount + withdrawalFee — the books did not balance, and the difference came out of the customer's payout. The fee probe compounded it by measuring a transfer of the short amount rather than the one about to be sent.

• Fixed the recipient's destination to the full amount requested, leaving the network fee funded from the withdrawal fee the customer already paid.
• Fixed the balance requirement to account for the network fee as a real outflow, since it is no longer absorbed by shrinking the customer's payout.
• Fixed the fee probe to measure a transfer the size of the one that is actually broadcast.
• Added a warning when the network fee exceeds the withdrawal fee charged, naming the shortfall the platform is covering.

Valid stagenet and testnet addresses refused as invalid

Monero's address prefix is network-specific — mainnet addresses open with 4 or 8, stagenet with 5 or 7, testnet with 9, A or B — and the check chose which set to accept from XMR_NETWORK. It compared only the first character, and it looked that value up without trimming it, with the mainnet set standing in for anything it did not recognise. A stray space, a spelling other than the three expected, or a value that never reached the process therefore refused every stagenet and testnet address on the install — and reported it as Invalid Monero address, which sends the operator to inspect an address that was correct all along.

• Fixed the check to decode the address and take the network from the address itself, so a single character is no longer the evidence.
• Fixed XMR_NETWORK to be trimmed and case-folded the way the rest of the platform already read it, so address validation and the deposit currency list can no longer disagree about which network you are on.
• Changed the refusal for a genuinely wrong-network address to name the address's network and the platform's, and to point at XMR_NETWORK.
• Changed an unrecognised XMR_NETWORK to stop quietly meaning mainnet. A well-formed address is now let through and the misconfiguration is logged for the operator; monero-wallet-rpc refuses a foreign-network transfer in any case, so nothing leaves the platform on a guess.

A mistyped address accepted at the withdrawal form

Because the check read one character, any string starting with the right one counted as an address. A truncated paste or a single wrong character passed the form, and the withdrawal was accepted and queued before monero-wallet-rpc refused to send it.

• Fixed validation to decode the address and verify the four-byte checksum Monero appends to it, so a typo is caught at the form instead of becoming a failed withdrawal.

Correct credentials reported as wrong

monerod and monero-wallet-rpc do not accept credentials up front. The first call is anonymous, the service answers 401 with a challenge, and the caller repeats the request with a digest computed over that challenge. The part that is easy to miss is where the challenge lives: the service keeps the nonce and its request counter per TCP connection, and treats a valid digest for a nonce that connection did not issue as stale rather than as authenticated.

The diagnostics were built on a pooled HTTP client, which gives no guarantee the second request reuses the first one's socket. When it did not, the service saw a nonce from someone else's connection and answered 401 — which the check reported as bad credentials. The addon's own client has always talked to Monero over a keep-alive connection and so never hit this, which is exactly why the screen and the deposit monitor disagreed.

• Fixed both Monero probes — monero-wallet-rpc get_version and monerod get_info — to send the challenge and the answer over one connection.
• Added the stale-versus-rejected distinction to the failure message, so a proxy that breaks the handshake is no longer reported as a wrong password.
• Fixed an unreachable service to report the socket error and the host:port instead of a bare client error, and to say that a Monero process answering local tools proves it is running rather than that .env points at it.
• Fixed the wallet and daemon rows to name the .env key each one came from, so the row and the line to edit agree.

One daemon probed where the platform uses a pool

Since 6.1.6 a configured XMR_<NETWORK>_RPC builds a failover pool, and the platform will dial any endpoint in it. The check probed one address, so a second daemon that was stale, unreachable or on the wrong network passed unnoticed until it served a real query.

• Fixed the daemon check to probe every endpoint in the list and report how many answered.
• Added a failure when endpoints in one pool report different networks, and made a network mismatch on any of them reach the XMR_NETWORK comparison rather than being hidden by a healthy sibling.

https:// URLs refused as unusable

The addon passes the host, port and path to a plain HTTP connection and never reads the scheme, so https://host:18081/json_rpc reaches a stock daemon exactly as http:// does — its --rpc-ssl autodetect default accepts plaintext on the same listener. Only a URL with no port genuinely breaks, because it then resolves to port 80.

• Fixed the URL rule to refuse only that case — which includes an explicit :443, since the parser erases a scheme's default port — and to warn on the rest that the URL claims TLS the connection never negotiates.

Changed

The backend says at startup which network Monero is really on

A disagreement between XMR_NETWORK and the network monerod runs breaks withdrawals and hides XMR from the deposit picker, and neither symptom named the cause. The requirements screen has carried this comparison for some releases, but it only answers when somebody opens it already suspecting the chain — by which point the working theory is usually that the address is bad.

• Added the network monerod reports to the startup log, and an error line when it disagrees with XMR_NETWORK that names both values and the one to set.
• Added a warning when XMR_NETWORK is absent, or holds something other than mainnet, stagenet or testnet, naming the network the daemon reports so the correct value is on screen rather than guessed at.

Documentation that 6.1.6 left behind

The 6.1.6 upgrade notes said in so many words that the admin screen and the Monero documentation still described XMR_<NETWORK>_RPC as display-only and were now wrong. Both have been corrected.

• Changed the RPC connection guide and the environment reference to describe XMR_<NETWORK>_RPC and its _FALLBACK as the keys they became: a daemon list that replaces XMR_DAEMON_RPC_URL for every daemon query. Both were removed from the "keys that do nothing" tables, where they had been left.
• Changed the description of how a multi-daemon pool picks. It is not a preference order: an endpoint that has never been tried is preferred, then the fastest measured one. Every entry must therefore be healthy and on the same network — a stale daemon anywhere in the list will be dialled.
• Changed the account of XMR_DAEMON_RPC_URL under a configured pool. It is not simply ignored: it remains the address monero-wallet-rpc is first pointed at, until a pool daemon answers.
• Changed the https:// guidance to describe what the addon actually does with the scheme, in place of the claim that such a URL always fails.
• Added the connection-scoped Digest behaviour to the RPC connection guide and the troubleshooting page, including what a stale challenge proves: the credentials were accepted, and the connection was not the one that issued the nonce.