Monero / Development / Merchant Security
Monero GUI Developers Propose Double-Spend Warnings for Merchants
Monero developers are adding double-spend warnings to the GUI wallet's Merchant Mode. Learn what the proposed changes mean for payment safety.
Monero developers are working on a warning for merchants accepting payments through the official GUI wallet. The proposed Monero double spend warning would alert users when the wallet flags an incoming payment as potentially conflicting.
The Core and GUI proposals, submitted on November 4, 2026, connect existing detection information to Monero GUI Merchant Mode. Both remained open in our November 9 source check. The reviewed official releases do not include the warning.
Why double spending matters
When someone sends Monero, the transaction normally enters a node's memory pool, or mempool, before inclusion in a block. During this period, the recipient may see the incoming payment even though it has no blockchain confirmation.
For merchants, that creates a decision: wait for confirmation or accept the payment immediately. A coffee shop might prefer a quick checkout, but an unconfirmed payment is not guaranteed to reach the blockchain.
A double-spend attempt involves conflicting transactions trying to spend the same funds. Only one conflicting spend can remain valid in the accepted blockchain. If a merchant delivers goods based on a payment that never confirms, they could lose money.
What the developers are changing
Core PR #11679 exposes existing detection information through the wallet API, the interface applications use to read wallet data. It copies the double-spend flag into transaction-history entries for incoming pool payments.
GUI PR #4767 brings that information into Merchant Mode. When the wallet flags a conflict, the payment's status would read “Possible double spend” in red, replacing its usual status text.
The proposal also refreshes transaction history during wallet refreshes when merchant tracking is active, even without a new block. That helps status changes appear while a payment remains unconfirmed.
These changes present information the wallet already collects. They do not introduce a new consensus rule or change Monero's transaction privacy.
Does this make zero-confirmation payments safe?
No. A warning can identify some suspicious payments, but it cannot guarantee detection of every double-spend attempt.
The wallet can only act on information available to it. Network propagation, node connectivity and the timing of conflicting transactions influence what it sees. Our wallet connection guide explains how wallets get network information from nodes.
A payment without a warning is not necessarily safe. Merchants accepting Monero zero-confirmation transactions still take more risk than merchants who wait for confirmations. The warning changes the display, leaving the decision to accept a payment with the merchant.
What merchants should do
Businesses accepting Monero should establish a confirmation policy based on the payment's value and the consequences of failure. Some may accept unconfirmed low-value purchases as a business risk. Higher-value sales justify waiting before releasing goods or services.
Monero's payment guidance recommends waiting for enough confirmations. Keep wallet and node software updated, verify wallet downloads, and match incoming payments to the correct invoice.
Once available, use the warning when reviewing a payment. A clear screen does not replace your confirmation policy. If a warning appears, pause fulfillment and investigate. Check your own wallet instead of relying on a customer's screenshot.
When will the feature arrive?
As checked on November 4, Core has two developer approvals and 18 successful automated checks, including its Ubuntu test job. GUI has no reviews, eight failed build checks and one successful source-archive check.
GUI also needs the Core change and an updated bundled Core dependency. The submitted API method names differ between the two patches, so integration still needs correction.
The patches do not add tests specifically for these changes. We did not run a live conflict test. The failed GUI jobs alone do not establish a security flaw.
The latest official GUI release, v0.18.5.4, predates both proposals. A “next release” label is not a confirmed release or date. The reviewed discussions do not establish a new widespread double-spending attack.