38,628 Crypto Orders. 10,139 IPs. What Wagyu’s Alleged Leak Means for Monero Privacy.
Monero’s cryptography was not broken. But newly examined order records show how a privacy-focused swap service can retain the exact connections its customers hoped to conceal.
Can Monero users be traced through a hacked exchange? Not by magically decrypting Monero’s blockchain. But potentially by reading what a swap service knows before coins ever enter the privacy network — and what it records when those coins leave.
That is the central finding of Hudson Rock’s review of purported Wagyu.xyz transaction data supplied alongside a WhiteArmor-associated claim. The files contain order histories, cryptocurrency destinations, transaction identifiers, connection metadata and an IP-level activity index. They do not demonstrate an attack on the Monero protocol, and their alleged breach provenance has not been independently authenticated.
Hudson Rock calculations from the provided CSVs; records span July 18–October 26, 2026. An order is not necessarily a completed trade, and an IP address is not necessarily a customer.
WhiteArmor’s claim raises a different question than its ransom note.
On October 27–28, 2026, ransomware-tracking services indexed WhiteArmor listings naming Wagyu.xyz, including a second entry called “wagyu.xyz unfairness.” The associated text concentrates on alleged unfair coin-flip odds and undisclosed swap fees. Its accusations are not proof of intrusion, ransomware deployment or financial misconduct, and Hudson Rock has not independently verified how the supplied files were obtained.
Wagyu presents itself as a no-KYC route between Monero (XMR), other cryptocurrencies and cross-chain infrastructure. Its service records therefore sit at a particularly sensitive boundary: a transparent blockchain on one side and a privacy-preserving cryptocurrency on the other. A leak at that boundary can expose relationships that Monero deliberately keeps off its public chain.
The security story isn’t “Monero has been cracked.” It is that a service handling private-coin conversions may preserve an off-chain ledger linking customers’ requests, public-chain movements, private-coin destinations and connection metadata.
The blockchain hides the destination. The swap order records it.
Monero uses stealth addresses, ring signatures and Ring Confidential Transactions to hide recipients, sender relationships and amounts in its on-chain records. A normal public observer cannot take an XMR receiving address and search the chain for a complete history of incoming and outgoing transfers.
But a swap service still has to know where to send funds. When a customer requests BTC → XMR, it may store the Bitcoin deposit transaction, the intended Monero receiving address, the order amount, the submission time, the client IP and the session used to track the order. Those values appear together in the supplied records.
Deposit address · transaction hash · asset and value
IP address · timestamp · session ID · browser headers · order mapping
Receiving address supplied to the service · internal payout status
A link in a service database is not evidence that Monero’s hidden sender, recipient or amount has become public on-chain.
We isolated 8,137 records with a native-XMR destination format and Monero output chain identifier; 6,692 were marked completed. Within the completed cross-chain subset, 4,580 records contained an incoming deposit transaction hash, a Monero receiving address and a client IP in the same row. Among these were 1,011 completed BTC → XMR orders with that linkage.
103.75.xxx.xxxBased on an actual completed row. Amounts are grouped, timestamps are reduced to the month, IP octets are masked, and complete wallet addresses, hashes, order IDs and session IDs are intentionally withheld to avoid reproducing a targetable user-level record.
This establishes that the supplied application data can map a public-chain deposit to an XMR destination and a network connection. It does not establish the customer’s legal identity, prove that the requestor owns the receiving wallet or reveal where any XMR later moves.
It works in reverse, too: XMR can become visible again at the exit.
The more consequential angle is not limited to buying Monero. We found 11,317 native-XMR-input swap records containing a 95-character Monero deposit address and a destination for another asset. Of those, 9,187 completed records also retained an outgoing transaction hash in the corresponding order data.
For an XMR → ETH transaction, for example, the service can connect the private-coin deposit it accepted to the Ethereum address it paid, alongside IP and timing information. That destination can then be examined on Ethereum’s transparent blockchain. Crucially, the service’s XMR deposit address is not proof of which Monero wallet originally funded it; Monero does not disclose that sender relationship publicly.
Putting both directions together reveals the real exposure: entry and exit metadata can erode pseudonymity even while the private blockchain continues doing its job. It is a correlation problem, not an XMR decryption problem.
Privacy can survive on-chain and still fail in the database sitting next to the chain.
10,139 IPs — and an activity map extending beyond individual swaps.
The companion file, users_wagyu.csv, is particularly informative. It groups activity by IP, providing an order count, number of distinct destinations, first and last observation, risk values, reported countries and network-provider classifications. We matched its 10,139 IP-level entries against orders.csv: each one corresponds to an IP in the larger file, and the per-IP order totals reconcile exactly.
This is not a verified database of 10,139 unique human users. Shared IPs, corporate NAT, VPN servers, Tor exit nodes, hosting services and automated API traffic can represent multiple unrelated people — while one person can use several IPs.
IP addresses appear in both XMR-output orders and orders delivering other assets.
Repeated session IDs span more than one IP address in the order export.
XMR receiving addresses occur in orders submitted from more than one IP.
These are correlation opportunities, not proof of shared ownership. A reused session ID can be more informative than an IP alone, but it may belong to a shared integration or automated workflow. Likewise, a popular destination can be a custodial wallet rather than one individual.
The network labels themselves include Tor, VPN, hosting and ISP categories. The mere presence of an IP beside a trade does not reveal the person’s home address, and a country or routing code should not be treated as verified geography.
One overlooked field may be the most uncomfortable: userDeletedAt.
Among the supplied records, 4,002 completed orders contain a populated field literally called userDeletedAt. Those same rows are still present in the export. All 4,002 retain an IP and destination; 3,180 also include a deposit transaction hash.
We cannot determine from the field name alone exactly what deletion operation occurred, what the site’s retention policy promised, or whether these rows came from a historical backup. So this is not proof of an unlawful failure to erase data. It is evidence that the supplied dataset still holds sensitive transaction metadata for records marked with a user-deletion timestamp.
Why this matters: A privacy interface can make a transaction disappear from a user’s account view without necessarily removing the underlying connection between their IP, trade and destination from every operational record or backup.
Can this data actually be used to trace XMR users?
Yes, in a defined and limited sense. Here is the boundary between what the files demonstrate and what they do not.
| Question | Assessment | Why |
|---|---|---|
| Can a public-chain payment be linked to an XMR receiving address? | Supported in data | Completed cross-chain order rows record deposit transaction hash, XMR destination, client IP and timestamp together. |
| Can an XMR-to-crypto exit be linked to a transparent payout address? | Supported in data | XMR-input orders retain service deposit addresses and destination addresses, often with an outgoing transaction hash. |
| Can network and session metadata help correlate activity? | Supported in data | The IP rollup and reused session IDs create off-chain associations, subject to VPN, NAT and automation ambiguity. |
| Can the files alone identify the human behind an IP? | Not established | IPs, wallet addresses and request headers are not reliable proof of a legal identity or a single user. |
| Can an analyst follow subsequent XMR transfers on Monero? | Not demonstrated | Monero conceals on-chain sender, recipient and amount relationships; this dataset does not defeat that protection. |
| Does this establish who originally sent XMR to a service deposit address? | Not demonstrated | An operator-issued deposit address is not the originator’s wallet, and a private Monero input cannot be attributed from the address alone. |
A cross-chain transaction plus IP metadata can become an investigative lead. Identification may be possible when independently corroborated with exchange KYC data, lawful provider records or other reliable evidence. Without corroboration, it remains a lead — not an identification.
For criminals, the off-chain metadata may be more useful than blockchain tracing.
Exact trade context makes targeted social engineering far more credible. A criminal holding an order’s real amount, approximate time, asset pair and payout destination could construct a believable fake refund or support message. A large historical conversion could also become the basis of financial profiling or extortion. These are plausible abuse cases; we have not established that any has occurred.
What a criminal could attempt
- Transaction-aware phishing: cite a real swap to impersonate support or demand a “recovery” payment.
- Cross-chain wallet clustering: connect public-chain activity to the same service session or network source.
- Targeted extortion: use historic transaction values and timing to suggest knowledge of a person’s finances.
- Dataset enrichment: compare exposed metadata with other compromised records to search for corroborating identity clues.
Where infostealers fit in
Infostealer malware can expose browser activity, saved credentials, session artifacts and cryptocurrency-related information on an infected endpoint. In an entirely separate dataset, those artifacts may sometimes add context to a pseudonymous exchange order.
No supplied evidence indicates that infostealers caused this alleged Wagyu incident, or that Hudson Rock matched any Wagyu customer to an infostealer infection. The risk is a general correlation mechanism, not a finding about specific users.
The allegations about hidden fees and rigged games need a separate audit.
The WhiteArmor-associated text alleges undisclosed swap fees and manipulated coin-flip odds. The accompanying configuration snapshot does distinguish public and “hidden” fee tiers, while an example order contains discrepant quoted, fee and later adjustment fields. Those findings warrant investigation, but a snapshot or attacker calculation alone does not prove an intentional scheme or the exact amount of customer losses.
The attached aggregate fee summary covers 28,840 completed swap/bridge orders, a subset that reconciles to completed order counts in the larger CSV. Yet the summary records 11,098 orders in its over category, whereas the actor’s note alleges 13,190 above the quoted rate. Likewise, the note’s coin-flip outcome imbalance does not by itself establish statistical rigging. We have therefore not adopted its claims of “proven” fraud as fact.
There is a further reason not to manufacture a spectacular dollar-volume figure from orders.csv: several expired orders contain implausibly huge amountUsd values. This article reports record counts and verified field co-occurrence rather than summing every row into a misleading trading-volume estimate.
What users and privacy-focused platforms should take from this.
For users
- Assume a swap provider may retain source and destination addresses, amounts, timestamps and connection metadata, even without an account or KYC.
- Be skeptical of unsolicited refund, recovery or verification messages that reference a real historic order.
- Avoid unnecessarily sharing transaction IDs or linking wallet addresses to public profiles. VPN or Tor use can limit direct-IP exposure but cannot erase information intentionally submitted to the service.
- If you believe your order information was exposed, check announcements through a known authentic channel; do not enter recovery phrases or private keys into support links.
For exchanges and bridges
- Minimize how long IP addresses, session identifiers, destination addresses and order mappings are retained together.
- Separate high-sensitivity transaction data from operational telemetry; implement least privilege, encryption and audited access.
- Explain what “delete” means across live systems, logs, analytics exports and backups; verify actual retention controls.
- Build incident response around the linkage between records, not merely the presence of standalone wallet addresses.
Monero can keep a secret that the service around it does not.
Our analysis does not show a vulnerability in Monero’s cryptography. It shows that a purported exchange order dataset contains enough off-chain information to connect thousands of privacy-coin transactions to source-chain movements, destination addresses, IPs and sessions. The records can support meaningful correlation; they cannot, on their own, name users or follow hidden XMR transfers.
For any company selling financial privacy, metadata retention is part of the threat model. A “no-KYC” transaction can still leave a remarkably detailed trail — and that trail may survive long after the user thinks the transaction has disappeared.
How we verified the numbers and limited the claims.
We analyzed the supplied orders.csv (38,628 rows; 45 columns), the users_wagyu.csv IP-level summary (10,139 rows), the WhiteArmor-associated note, and supporting configuration, fee and coin-flip files. We reconciled IP order counts, isolated native XMR address formats and order kinds, checked completion status and counted field co-occurrence. The IP-summary export has a misaligned network-classification header, which we accounted for during inspection.
The datasets’ origin, completeness and authenticity are not independently established. We did not independently verify blockchain settlement, identify private individuals, publish full wallet addresses or IPs, or attempt to follow Monero transactions. “Completed” means the export labels an order as completed, not independently verified settlement. The publication of a ransomware-group listing is a claim, not proof of encryption or exfiltration.
Public incident context: Wagyu.xyz / WhiteArmor listing, October 27; “Wagyu.xyz unfairness” listing, October 28; HackerFeeds reporting methodology.
Monero technical references: Official Monero FAQ; Stealth addresses; Network and IP privacy considerations.
Figures are from Hudson Rock’s analysis of supplied material, not independent confirmations from Wagyu. WhiteArmor’s financial accusations are presented as allegations, not proven findings. No personally identifying raw records are republished.
The post 38,628 Crypto Orders. 10,139 IPs. What Wagyu’s Alleged Leak Means for Monero Privacy. appeared first on InfoStealers.