PRIVACY ANALYSIS

Your view key was never meant to leave your device

xmrwallet.com sent your private view key to their server 47 times per session. Here's exactly what that means for your privacy.

47
View key leaks per session
139
API requests captured
8
Years of operation
100%
Transactions visible
Step 1

What the operator sees with your view key

The moment you log in, xmrwallet sends your private view key to the server inside every API request. The server then scans the Monero blockchain — and sees everything you see.

xmrwallet-operator ~ blockchain scanner
$ scan_blockchain --viewkey 7a4f...stolen...e8b2
[scanner] Connecting to Monero daemon...
[OK] Connected. Scanning from block 3,670,000...
 
Block 3,670,142 FOUND +10.000000 XMR from 4Af3...82d1 (Kraken hot wallet)
Block 3,670,891 SPENT -9.500000 XMR to 8Bc7...f4a9 (unknown — Tor session)
Block 3,672,003 FOUND +25.000000 XMR from 4Ce1...11bf (mining pool payout)
Block 3,672,210 SPENT -24.800000 XMR to 8Dd9...7e23 (unknown — Tor session)
Block 3,674,500 FOUND +3.200000 XMR from 4Bf7...cc40 (P2P exchange)
 
SCAN COMPLETE
Total received: 38.200 XMR | Total spent: 34.300 XMR | Balance: 3.900 XMR
Unique senders: 3 | Unique recipients: 2 | TX count: 5
 
ASSESSMENT: Victim receives from KYC exchange + mining.
Sends to unknown 8... subaddresses via Tor. Pattern: laundering.
Recommended action: WAIT for next large deposit, then sweep.
_
Step 2

How your real identity connects to your "anonymous" wallet

You used a VPN. You used Tor. You changed browsers. None of it matters. The session_key contains your view key — it's tied to your wallet, not your IP.

REAL IDENTITY

IP194.35.12.45
ISPDeutsche Telekom
CityBerlin, Germany
BrowserChrome 125 / Win11
Time14:30 UTC
ActionDeposit 10 XMR from Kraken
Kraken requires KYC: passport, selfie, bank account. This IP is linked to a real person.

XMRWALLET.COM

session_key contains
view key for BOTH sessions

SAME WALLET = SAME PERSON

"ANONYMOUS" SESSION

IP185.220.101.34
ISPTor Exit Node
CityUnknown
BrowserTor Browser 13.0
Time23:15 UTC (8h later)
ActionWithdraw 9.5 XMR to 8Bc7...
User thinks this is anonymous. It's not. The view key in session_key is identical to the Berlin session.

OPERATOR'S CONCLUSION

1. IP 194.35.12.45 (Berlin, DE) logged into wallet 4x7f...a3d1
2. Deposited 10.0 XMR from Kraken address 4Af3...82d1
3. Same wallet accessed from Tor 8 hours later
4. Withdrew 9.5 XMR to subaddress 8Bc7...f4a9
5. Hans Mueller, Berlin = owner of 8Bc7...f4a9
6. Kraken KYC identity linked to darknet deposit address
Step 3

Attack timeline — from login to identity exposure

Every action the user takes is logged. The view key connects all sessions. The session_key connects all IPs. The result: complete deanonymization.

Day 1, 14:30 UTC
User creates wallet from home IP
Logged in from Berlin, Chrome, real IP. Created new wallet. Seed immediately captured via session_key.
POST /auth.php session_key=[blob]:base64(addr):base64(viewkey)
Day 1, 14:32 UTC
Deposits 10 XMR from Kraken
Funds arrive from Kraken hot wallet. Operator's scanner detects incoming TX via stolen view key.
SCANNER: +10.0 XMR from 4Af3...82d1 (Kraken) at block 3,670,142
Day 1, 23:15 UTC
User switches to Tor, sends to "anonymous" address
8 hours later, same wallet accessed from Tor exit node. User sends 9.5 XMR to subaddress. Thinks it's private.
LOGIN from 185.220.101.34 (Tor) | SAME session_key = SAME view key
Day 3
Mining pool payout arrives
25 XMR from mining pool. Operator now knows: this person mines Monero, uses Kraken, and sends to darknet addresses.
Day 3, +2 hours
Operator executes theft
With the full seed (captured at login), operator sweeps 24.8 XMR. User sees balance drop. "Synchronization error. Try again in 6 days."
SWEEP: 24.8 XMR to operator wallet. Victim sees sync error.
Day 9
User returns — funds gone
Balance is 0. The "sync error" was cover for the theft. Seed was stolen on Day 1. Privacy was destroyed on Day 1. Every transaction was monitored since Day 1.
The difference

Server-side scanning vs. client-side scanning

"We need your view key to scan the blockchain" is a lie. Every legitimate Monero wallet scans locally.

xmrwallet.com (server-side)

View key sent to server in every request
Server scans blockchain — sees all your TX
Operator knows your balance in real-time
All IPs linked via session_key
Traffic routes through DDoS-Guard (Russia)
Full seed captured = can steal anytime

Monero GUI / Feather (client-side)

View key never leaves your device
WASM/native code scans blockchain locally
No server knows your balance
No session tracking between connections
Direct connection to Monero nodes
Seed encrypted locally, never transmitted
It gets worse

The data chain doesn't end at xmrwallet

Your session_key (containing your view key) passed through multiple third parties before reaching xmrwallet's server.

DDoS-Guard

All traffic to xmrwallet.com was routed through DDoS-Guard — a Russian DDoS protection service. Every session_key, every view key, every request passed through their infrastructure. They could log everything.

Nathalie Roy

The registered operator was a Canadian government employee. Whether she was the real operator or a front — the WHOIS data linked to a government identity. An "anonymous privacy wallet" registered to a government worker.

Google Analytics

The landing page loaded Google Analytics (UA-116766241-1). Google could correlate: IP visits xmrwallet.com → same IP visits gmail.com → real identity linked to crypto wallet usage.

8 years of data

xmrwallet operated from 2018 to 2026. Every wallet created, every view key captured, every IP logged, every transaction visible. A complete surveillance database of Monero users who trusted a web wallet.

The surveillance map

One operator, 8 years of connections

Every wallet that used xmrwallet gave the operator their view key. Cross-reference IPs, timestamps, deposit sources, withdrawal destinations — and you get a complete intelligence graph. This is what 8 years of data looks like.

xmrwallet Person IP Address Wallet Exchange/Service Unknown addr

See it for yourself

Create a test wallet, make transactions, then open the operator panel to see exactly what was captured — including the view key scanner.