MMashDiv

Monero Blockchain 6.2.1

1 October 2026

This release has upgrade notes. Read them before updating — they describe behaviour changes that need your attention.

DEPOSITSWITHDRAWALSMONEROXMRWALLET-RPC

Monero (XMR) Blockchain v6.2.1

Release Date: October 1, 2026 Tags: DEPOSITS, WITHDRAWALS, MONERO, XMR, WALLET-RPC

Overview

Monero deposits could be credited to the wrong customer. monero-wallet-rpc keeps one wallet open at a time, and the backend and the cron process shared it without coordinating, so one process could read the wallet the other had just opened and credit that wallet's incoming transfers to its own customer as well. Every such credit was extra balance the platform paid for. Every Monero operation now holds a lock shared by all processes and checks which wallet is open first.

Withdrawals change too: one whose outcome is unclear is now held for you instead of refunded. See Upgrade Notes.

Requires Core v6.7.9 and Ecosystem v6.5.3, up from v6.7.6 and v6.5.0. On an older Core the Monero service does not load. See Upgrade Notes.

Update Instructions

pnpm updator

Update Core to v6.7.9 or later first, or in the same window. No schema change, no seeder, no .env change. pnpm updator restarts the backend and the cron process together, which is what the lock needs: an older process still running beside a new one is outside it.


Upgrade Notes

Core v6.7.9 and Ecosystem v6.5.3 are now the minimum

  • This package loads three shared helpers from Core's backend/src/utils/, and Core v6.7.9 is the first release that has all three. On an older Core the Monero service does not load: the backend log says Failed to load module @b/blockchains/xmr: Cannot find module …, no XMR address is created, no deposit is checked, and XMR withdrawals fail before anything is sent.
  • Ecosystem v6.5.3 is the first release whose withdrawal queue itself refuses to fail or refund a withdrawal that carries a recorded, unconfirmed transaction hash. This release records that hash before every relay and never refunds over it; on an older Ecosystem that check of its own is the only one.
  • It was released on the same day as Core v6.8.2 and Ecosystem v6.5.6, and the Monero documentation describes that combination.

Withdrawals that now wait for you

  • A withdrawal whose outcome is unclear stays in TIMEOUT with "Manual review required" and the built transaction's hash in its description. Check the hash on chain and resolve the row by hand.
  • Credits made before the update are not reviewed or reversed. The fix prevents new wrong credits only.
  • Anything else that drives the same monero-wallet-rpc — a script, or curl run by hand against it — is outside the lock. The new checks then refuse to credit or send and log WALLET IDENTITY MISMATCH or OWNERSHIP MISMATCH.

Rotating the master wallet's keys

  • Move the master_wallet file out of wallet-rpc's wallet directory before creating the master again. Otherwise its old keys are now adopted, with an ALERT line in the log saying so.

Changed

Withdrawals when wallet-rpc is busy

  • Changed a withdrawal that cannot start within 90 seconds (wallet-rpc busy with another wallet, or Redis unreachable) to return to pending with nothing sent and be retried, instead of holding up the withdrawals behind it. One that can never be sent, because the wallet's file or recorded address is wrong, is failed and refunded after 24 hours of refusals with an ALERT in the log (XMR_WITHDRAWAL_REFUSAL_FAIL_AFTER_HOURS, default 24).

Mining payouts are not deposits

  • Changed deposit detection to ignore coinbase outputs (a block reward paid straight to a deposit address by solo mining or P2Pool). Ordinary pool payouts are credited as before.

Fixed

Deposits credited to the wrong customer

  • Fixed by making every Monero operation hold a lock shared by all processes, check which wallet is open before every read and send, and refuse to credit a transfer not paid to that wallet's own address. The rightful owner was always credited; the wrong credits were extra.

Withdrawals

  • Fixed a withdrawal being failed and refunded when wallet-rpc answered the send with an error after the transaction may already have been broadcast. The transaction is now built first, its hash recorded on the withdrawal, then relayed; an unclear outcome is checked with the daemon and otherwise held for manual review instead of refunded.
  • Fixed a withdrawal requested while freshly deposited coins were still locked being failed and refunded instead of waiting until they unlocked. The "enough unlocked?" check compared text, so it never fired.

Wallet creation

  • Fixed address creation failing for good with "already exists" after an earlier attempt had created the wallet file but not saved it. The existing file is now verified and adopted.