38,628 Crypto Orders. 10,139 IPs. What Wagyu’s Alleged Leak Means for Monero Privacy.
Monero’s cryptography was not broken. Yet the records connect its users to public-chain activity — and include seven-figure transaction clusters marked with alleged hacker, theft and mixer attributions.
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.
Hacker labels, seven-figure Monero orders and some revealing connections.
The data contains another striking finding: some large Monero-related orders carry source labels such as “Poloniex Hacker,” “DCENT Wallet Hacker,” “Theft” and “Tornado.Cash: 100 ETH.” Even without knowing who controlled the wallets, the records preserve the source and destination addresses that Wagyu associated with those orders.
What these findings do — and do not — establish. The labels come from the supplied Wagyu records. We have verified the order counts, amounts and relationships within those files, but have not independently established that any wallet belongs to a known hacker or that its funds were laundered. The dollar figures are values recorded by Wagyu for completed orders, not independently verified stolen proceeds.
Six Monero bridge withdrawals totaling $1.03 million.
The export contains six completed XMR bridge withdrawals marked “Poloniex Hacker.” All six share the same recorded source address, Monero receiving address and session identifier. They were submitted from two different IP addresses.
The November 2023 Poloniex hack is publicly documented. However, we have not confirmed that this source address was involved. These records show bridge withdrawals into native XMR; they do not contain the incoming transaction hashes needed to establish the funds’ earlier history.
Three Ethereum-to-Monero orders linked by one source wallet.
Two completed orders totaling $651,667 carry the label “DCENT Wallet Hacker.” A third, worth $250,960, has no such label, but shares the same Ethereum depositor address, Monero destination and recorded IP. Taken together, the three orders represent approximately $903,000 in recorded swap volume.
D’CENT publicly reported unauthorized App Wallet transfers in September 2026. This provides context for the name, not proof that the three Wagyu orders contained those stolen assets. Two orders are also marked as restricted in the export despite a completed status; determining whether those flags existed before or after execution would require the platform’s screening logs.
“Theft” and Tornado Cash-labeled orders converge within an hour.
Seven completed orders identify two different Ethereum depositor addresses and the same recorded XMR receiving address within roughly 58 minutes. Two orders carry the label “Theft” and total $559,107. Five are labeled “Tornado.Cash: 100 ETH” and total $264,290.
All seven orders also share a recorded IP address, masked here as 146.70.xxx.xxx. A shared destination is a useful investigative connection, although it does not prove the wallets had the same human owner. Shared infrastructure, custodial wallets or automated services can produce similar patterns.
A Tornado Cash association is not inherently evidence of laundering. The five mixer-labeled orders described here also appear in the broader 25-order group below.
One depositor, 360 Monero orders and unusually consistent amounts.
A single Ethereum depositor address labeled “Theft” appears in 360 completed Monero-output orders, sent to 13 different XMR destinations. Most of the orders are remarkably similar in size: 315 fall between $4,900 and $5,100. The records span 20 IP addresses, and 354 orders retain incoming transaction hashes.
The repetition makes this a worthwhile transaction-pattern investigation. It might reflect deliberate order splitting, but it could equally result from an automated trading workflow, route capacity or limits imposed by the service. The amounts alone cannot establish an attempt to evade financial controls.
A wider group totals $3.56 million in recorded ETH-to-XMR swaps.
Across the full dataset, 25 completed Ethereum-to-Monero orders carry the label “Tornado.Cash: 100 ETH.” They involve four source addresses and four Monero receiving addresses. A single source-to-destination pair accounts for 12 orders worth approximately $2.03 million, placed over about two hours on October 3, 2026.
Five of these 25 orders are already counted in Case 03. The $3.56 million therefore overlaps with the $823,397 case; the figures should not be added together. Mixer usage is not evidence of criminal conduct on its own.
Why these records matter for investigations.
For investigators, the value lies in linking the data points: a source-chain address, a service order, a Monero receiving address and the metadata recorded at the time. Some apparent relationships span multiple transactions, different labels or repeated destinations. Those connections give investigators leads to verify against independent blockchain evidence and other records.
They do not reveal transfers made after the funds enter Monero, nor do they identify the individuals who control the wallets. The case totals are recorded order values, may include the same funds moving more than once, and are not a cumulative estimate of money laundering or stolen assets.
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. |
The labeled high-value transaction clusters described above illustrate the investigative uses of these records, but the labels are not independently verified claims about criminal proceeds. 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.
For the high-value case studies, we filtered to completed rows, grouped by recorded source and destination fields, checked source labels and shared wallet identifiers, and summed recorded USD values per group. Named labels describe the export, not externally verified wallet attributions; linked orders and group totals overlap. The datasets’ origin, completeness and authenticity are not independently established. We did not independently verify blockchain settlement, identify private individuals, publish full wallet addresses, transaction hashes, order IDs 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.
Context for incident names appearing in unverified source labels: The Block: November 2023 Poloniex hack; DCENT: September 17, 2026 official incident report. These sources document the external incidents, not a verified match between their stolen funds and any wallet in the supplied dataset.
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.
