Bottom line: before sending XMR from a Monero wallet to an exchange, verify the live order, the recipient address, the requested amount, and any identification data shown with that address. Then confirm that the wallet is synchronized and holds enough unlocked XMR to cover both the transfer and the network fee. This review covers transaction preparation and verification; it cannot establish a current exchange rate, service fee, limit, required confirmation count, or compliance requirement without a live quote.
How the claims were checked
Stable technical points were matched against Monero’s official documentation, user guides, wallet RPC reference, source-code repository, and release materials. Dynamic service conditions were treated differently: if a rate, pair, limit, confirmation policy, or verification request could change between orders, it was not inferred from general documentation.
Freshness matters most for wallet software and service terms. The official Monero download page listed GUI version 0.18.5.2 when reviewed, and the corresponding release post was dated July 21, 2026. That version number is useful only as a reminder to check the current official release, not as proof that every wallet implementation must use the same numbering. [1]
What can be confirmed before creating the exchange
Start with a synchronized wallet and unlocked balance
The official Monero payment guide states that the wallet and its node must be synchronized before a GUI transaction is sent. The selected account must also have an available, unlocked balance. A displayed total balance is therefore not enough if part of it is temporarily unavailable for spending. [2]
Check the amount against the balance after the wallet finishes refreshing. The sender pays the Monero network fee, and the fee is not determined solely by the XMR amount. Official guidance describes it as dependent on factors including network conditions and transaction data size. The exact fee displayed by the wallet is separate from any exchange service fee or spread shown in the order. [2]
Treat the generated deposit address as order-specific data
Copy the XMR recipient address from the active order rather than from an old message, screenshot, browser history entry, or previous exchange. Monero software validates address structure and checksum, but a structurally valid address may still belong to the wrong recipient. A successful wallet validation does not prove that the address matches the current order. [3]
Official Monero software recognizes standard, subaddress, and integrated-address formats. The user guide notes that normal mainnet recipient addresses commonly begin with 4 or 8. An integrated address is longer and embeds a compact payment ID, allowing the recipient to associate a payment with an internal record. Do not reject or modify an address merely because it differs from one used previously; compare it with the service’s current instructions instead. [4]
If the order separately displays a payment ID, memo, tag, or other identifier, determine whether the wallet actually provides a corresponding field. Do not append text to an address or substitute an order number for a technical payment ID. Monero documentation explicitly distinguishes an integrated address’s payment ID from business identifiers such as invoice or order numbers. [4]
Review the wallet’s final confirmation screen
After pasting the address, compare the beginning, middle, and end of the string with the order page. Checking only the first and last few characters is a useful quick filter, but it is not a complete comparison. Clipboard-replacement malware can insert another valid-looking Monero address, so the value displayed by the wallet—not merely the text originally copied—must be reviewed.
Confirm the XMR amount and the estimated network fee before authorizing the transaction. If the exchange requires an exact incoming amount, do not assume that selecting “send all” will preserve that figure: the wallet must also fund the network fee. Conversely, if the order defines the amount the recipient should receive, use the wallet’s recipient-amount field rather than performing an undocumented deduction.
Monero transactions become irreversible once confirmed in a block. A mistaken payment can then be returned only through cooperation from the recipient, not through a blockchain cancellation or chargeback. This makes the final address-and-amount review the last practical control before broadcast. [2]
Claim registry
| Claim | Verification status | Primary source type and name | Publication or update date | Limitation | What could change the conclusion |
|---|---|---|---|---|---|
| A synchronized wallet and unlocked balance are required to prepare a normal outgoing payment in Monero GUI. | Confirmed | Official project user guide, “How to make a payment” [2] | Page-level publication date not displayed | The instructions describe the official GUI; labels and workflow may differ in other wallets. | A later official wallet release or revised payment guide. |
| The sender pays a variable Monero network fee that is not based only on the amount sent. | Confirmed | Official project user guide, “How to make a payment” [2] | Page-level publication date not displayed | No exact fee can be derived without constructing a transaction in the user’s wallet. | Protocol fee-rule changes, wallet estimation changes, or current network conditions. |
| An integrated Monero address contains a compact payment ID and is distinct from an exchange order number. | Confirmed | Official Monero Docs, “Integrated Address” [4] | Page-level update date not displayed; documentation repository listed as updated September 11, 2026 [5] | The recipient may instead issue a standard address or subaddress, with no separate payment ID required. | A protocol or wallet-policy change affecting integrated-address support. |
| A confirmed Monero payment cannot be reversed through the network. | Confirmed | Official project user guide, “How to make a payment” [2] | Page-level publication date not displayed | The recipient can voluntarily make a separate return transaction. | A fundamental protocol change; none is established by the reviewed sources. |
| A particular XMR exchange direction, rate, service fee, minimum, maximum, expiry time, or required number of confirmations is currently available. | Unknown until a live order is reviewed | Transaction-specific exchange quote and current service terms | Must be generated or consulted immediately before sending | No current order data was supplied, and general Monero documentation cannot establish commercial terms. | Liquidity, operational availability, quote expiry, service policy, or the selected destination asset and network. |
| The transaction will proceed without additional compliance checks. | Dependent on conditions | Current order flow and applicable compliance requirements | Must be checked before creating and funding the order | Requirements can depend on the exchange direction and the outcome of compliance screening. | Transaction details, risk signals, service rules, and rules applicable in the user’s country. |
What the findings mean in practice
A safe sequence begins with the exchange order, not the wallet’s send button. Record the selected input asset as XMR, the intended output asset, the displayed destination network, the recipient amount or sending amount, and the order’s validity conditions. If any of these fields are missing or ambiguous, pause before copying the deposit address.
- Open the Monero wallet and allow synchronization to finish.
- Confirm that the spendable or unlocked balance covers the intended amount and the wallet’s fee.
- Generate or refresh the exchange order and read its current requirements.
- Copy the XMR deposit address directly from that order.
- Verify the complete address after pasting it into the wallet.
- Check whether the service requires a separate identifier or has already embedded one in the address.
- Compare the final recipient amount, address, and fee on the wallet confirmation screen.
- After broadcast, save the transaction ID and order reference until the exchange is completed.
A transaction ID helps identify the outgoing transaction, while Monero wallet tools can also generate or check transaction proofs. Because Monero conceals public transaction details such as recipient address and amount from ordinary blockchain observers, troubleshooting does not always resemble checking a transparent-chain explorer. The official RPC documentation also warns that a transaction proof alone does not guarantee that associated funds are spendable, so it should be treated as evidence with defined limits rather than a universal settlement guarantee. [2]
Risks and the repeat-check procedure
Wrong address or substituted clipboard data: compare the address inside the wallet with the active order. A valid checksum cannot reveal whether malware replaced the intended recipient with another valid address.
Wrong asset or destination network: confirm that the order explicitly requests native XMR from the Monero network. Do not infer compatibility from a ticker, familiar brand name, or an address saved during another operation.
Expired or changed quote: repeat the commercial check if the order page has refreshed, its validity period has passed, or the amount was altered. Rates, limits, fees, and available directions are dynamic and should not be copied from an earlier transaction.
Compliance interruption: inspect the current requirements before sending. Verification conditions may vary by direction and by compliance results. A transaction already broadcast on Monero cannot be recalled simply because the service later requests information or delays processing.
Phishing or compromised wallet software: use the official release channel and verify downloaded wallet files where practical. Monero publishes a GPG-signed hash list and recommends checking both its signature and the downloaded archive’s hash before using the software. [1]
Disclosure of wallet secrets: an exchange support request may legitimately refer to an order number or transaction ID, but it does not need the mnemonic seed or private spend key to identify a deposit. The private spend key authorizes spending, while the mnemonic represents wallet recovery material; exposing either can compromise control of the wallet. [6]
Immediately before authorizing the transfer, repeat four checks from fresh screens: current order status, exact XMR address, final wallet amount, and displayed network fee. After sending, retain the transaction ID and monitor the order through its stated processing stages. If the service’s live terms conflict with an old guide or screenshot, the transaction-specific instructions require clarification before any XMR is broadcast.
Once these checks are complete, use the service page to review currently available XMR exchange directions and live order requirements. This step is operational rather than evidentiary: the page should be used to obtain a current quote, not to prove general claims about Monero.
