Confirmed: your private Monero view key is transmitted to their server on every API request. Transaction destination addresses are substituted server-side. 15+ documented victims. $2M+ estimated stolen. Operating since 2016.
Every step documented with real captured traffic. From the moment you enter your key to the moment funds disappear.
The site asks for your wallet address and private view key "for syncing". Both are sent in plaintext via POST to their PHP server. No client-side encryption. Visible in DevTools → Network tab.
Server returns a session_key — not a random token. It contains your address and private view key encoded in Base64, re-sent to the server 40+ times per session.
Every balance check, transaction view, page reload — your private view key is transmitted again. Includes an automatic request to /support_login.html with a different session_id not initiated by you.
Client builds a transaction but the result is discarded (raw_tx_and_hash.raw = 0). Only metadata sent to server, which builds its own transaction and redirects funds to any address.
Google Tag Manager allows the operator to push any JavaScript without changing source code or committing to GitHub. Auditing the repo is useless — real code loads from GTM.
8 years of operation. 5.3-year GitHub blackout. Banned from Reddit. 50+ paid articles. A "volunteer project" with zero donation wallet.
| TYPE | VALUE | NOTES |
|---|---|---|
| Domain | xmrwallet.com | NameSilo, paid until 2031 |
| Tor | xmrwalletdatuxms.onion | Historical |
| IP | 186.2.165.49 | DDoS-Guard subsidiary AS59692 |
| MX | mail.privateemail.com | Namecheap private email |
| Cookies | __ddg8_, __ddg9_, __ddg10_, __ddg1_ | DDoS-Guard tracking |
| GitHub | nathroy (ID: 39167759) | 5.3yr commit gap — facade repo |
| admin@xmrwallet.com | also: support@, feedback@ | |
| u/WiseSolution | Banned from r/Monero | |
| session_key | [blob]:[b64_address]:[b64_viewkey] | Key exfiltration vector |
| raw_tx_and_hash.raw | = 0 | TX discarded client-side |
| type == 'swept' | server TX marker | Theft signature |
| /support_login.html | session_id=8de50123dab32 | Operator backdoor |
Operating since 2016. GitHub facade with 5.3-year commit gap. 50+ paid SEO articles, zero donation wallet. Banned from r/Monero 2018. Deletes GitHub evidence. Directs theft victims to CLI wallets where they find empty balances. Conservative estimate: 10,000–50,000+ accounts over 8 years. Total stolen: 5,000–50,000+ XMR ($1.5M–$15M+ at historical prices).
A "private" Monero wallet loading 4 Google trackers. Every page inside your wallet reported to Google.
Collected from Trustpilot, Sitejabber, Reddit, BitcoinTalk. Operator response to every report is identical: "you used a phishing clone."
xmrwallet.com Terms of Service (last updated September 27, 2021) make 5 specific technical claims about how the service works. Every single one is contradicted by observed network behavior.
"temporarily stored in memory"
Implies the view key exists only client-side in RAM during the session. Standard behavior for a legitimate light wallet.
session_key = [blob]:[base64(address)]:[base64(viewkey)]
The view key is Base64-encoded into session_key and transmitted to xmrwallet.com servers on every single API request — 40+ times per session across 6 different endpoints. This is not "in memory". This is active exfiltration.
"cryptographically impossible for our company to spend funds on your behalf"
Standard non-custodial wallet guarantee. If true, even a compromised server cannot move your funds.
raw_tx_and_hash.raw = 0
if(type == 'swept') { ... }
The client builds a transaction locally — then discards it (raw = 0). Only metadata is sent to the server. The server constructs its own transaction and broadcasts it. The type='swept' marker indicates server-initiated fund transfer. The claim of cryptographic impossibility is directly contradicted by the production code.
"your requested transaction"
Implies the transaction broadcast is exactly what you constructed and authorized — standard relay behavior.
// client TX → discarded (raw=0)
// server TX → broadcast instead
The transaction broadcast to the Monero network is not your transaction. It is a transaction constructed server-side using your metadata. The destination address can be anything the server chooses. You never signed the transaction that gets broadcast.
"third-party attacks"
Standard liability disclaimer — reasonable protection against external hackers, network failures, etc.
// victim reports stolen funds
// xmrwallet: "third-party attack"
// → not our problem
When victims lose funds and report to xmrwallet.com support, the response is invariably "sync problem" or "third-party issue". This clause is pre-positioned legal cover for theft the operator controls. 15+ documented victims received this response.
"Notices to company may be sent to lr@xmrwallet.com"
Legal arbitration contact. Not the same as admin@, support@, or feedback@. The initials lr likely correspond to operator initials — potentially Loi Roy or a variant of Nathalie Roy's legal name. Separately, operator contacted PhishDestroy from royn5094@protonmail.com.
"does not keep any records of your transactions"
Footer claim directly contradicted by 4 active Google tracking scripts inside the wallet UI: GTM · UA-116766241-1 · GA4 · DoubleClick. Google Tag Manager alone allows pushing arbitrary tracking code to all users without any code changes. Every wallet session generates analytics events sent to Google.
Document everything: wallet address, TxID, TX Key, timestamps, screenshots. Do NOT pay any "recovery service" — that is a second scam targeting victims.
Use these tools to analyze xmrwallet.com yourself and share results as additional evidence.
Keys never leave your device. You connect to your own Monero node or a trusted remote node. Most private option.
These wallets share your view key with a remote node for fast sync — faster and lighter than full node, slightly reduced privacy.
Private keys stored on a dedicated hardware device and never exposed to the host machine. Most secure option for large amounts.