A July 2026 research preprint presents ProxyMark, a multi-stage technique intended to associate transactions originated by certain Monero nodes operating through Tor with their source IP addresses. The work does not break Monero’s transaction cryptography or decrypt Tor circuits. Instead, it examines how application-layer forwarding rules, peer selection, Tor relay positioning and traffic patterns can interact to expose network metadata.

The study illustrates a broader privacy-engineering problem: protecting transaction contents does not automatically protect the communications surrounding a transaction. A cryptocurrency may conceal amounts, addresses and ownership relationships on its ledger while still exposing information through message direction, peer selection, timing, packet frequency or differences between locally created and relayed transactions.

These layers should not be evaluated independently. A probabilistic blockchain heuristic, a network-origin observation or an exchange record may be inconclusive on its own. When several signals refer to the same transaction, however, they may reinforce one another and materially reduce an investigator’s uncertainty.

For Ryo Currency, the research provides relevant context for its planned high-latency mixnet. It supports the architectural case for treating network anonymity as a dedicated privacy layer. It does not, by itself, establish that any proposed mixnet is secure—or that every Monero transaction sent through Tor can be traced.

The ProxyMark research and its scope

The paper, Deanonymizing Monero Transactions in Tor Network, was submitted to arXiv on July 8, 2026 by Ruisheng Shi, Shihan Zhang, Yulian Ge, Lina Lan, Qingfeng Zhang and Qin Wang. An earlier and shorter version of the work appeared in the Companion Proceedings of The Web Conference 2024.

The expanded paper describes a framework called ProxyMark. According to the authors, it combines three operations:

1. Node-role identification: Distinguishing a Monero Tor hidden-service node from a Tor client node and, where applicable, recovering the node’s onion address.
2. Originated-transaction identification: Increasing the probability that adversarial hidden-service peers receive transactions created by the target.
3. Node-location deanonymization: Using a traffic watermark and an adversarial Tor relay to associate a Tor-level identifier with a source IP address.

The researchers evaluated these stages through component-specific experiments involving Monero testnet, Monero mainnet, controlled hidden-service deployments and the live Tor network. This is not the same as measuring the ordinary end-to-end success rate of ProxyMark against randomly selected live Monero users.

The central finding is compositional: the claimed leakage arises where Monero’s application-layer behavior meets Tor’s connection and traffic model. It is not presented as a cryptographic break of Monero or Tor.

How Monero transactions are routed through internal Tor connections

Monero supports more than one way of using Tor. ProxyMark concentrates on nodes using Monero’s anonymity-network mode while maintaining outgoing connections to Monero peers operating as Tor hidden services.

Under the behavior analyzed by the researchers, a node continues to use public peers for blockchain synchronization and eventual clearnet propagation while using hidden-service peers as an initial protected route for transactions created locally by that node.

The paper reports that an originated transaction is initially sent to two selected outgoing Tor hidden-service peers, described as proxy nodes. Those peers subsequently introduce the transaction into clearnet propagation through Dandelion++.

Transactions that the node merely relays are treated differently. The researchers argue that this asymmetry allows a hidden-service peer receiving a transaction through an incoming internal-Tor connection to infer that the transaction was created by the peer on the other side, rather than merely forwarded by it.

Monero’s own anonymity-network documentation describes Tor and I2P integration as experimental and acknowledges configurations in which privacy can leak. It also explains that locally originated transactions can be directed specifically to anonymity-network peers.

How ProxyMark builds the attack chain

1. Identifying the node’s role

The first stage analyzes peer lists exchanged through Monero’s periodic Timed Sync messages.

According to the paper, a hidden-service node repeatedly includes its own onion address in a predictable position in responses sent to certain outgoing hidden-service peers. A Tor client node does not display the same self-advertisement behavior.

By comparing multiple responses, the researchers attempted to classify the remote participant as either a hidden-service node or a Tor client. In the hidden-service case, the same behavior could expose the onion address associated with the connection.

In a controlled experiment involving 300 independent connections, the researchers reported 100% precision and 100% recall for this classification stage. The authors characterize this result as arising from deterministic differences in protocol behavior within the tested configuration—not as a statistical result applicable to every possible Monero setup.

2. Increasing access to originated transactions

Identifying a target does not automatically reveal its transactions. An adversary must become one of the target’s outgoing hidden-service peers and then be selected as one of the two proxy nodes used for originated-transaction forwarding.

ProxyMark attempts to improve those odds through two mechanisms.

First, adversarial peers provide the target with numerous attacker-controlled onion addresses. The objective is to place these addresses into the target’s peer lists and progressively occupy a large share of its outgoing hidden-service connections.

Second, adversarial peers report artificially fresh blockchain heights. Because proxy eligibility is influenced by reported synchronization height, attacker-controlled peers may be selected as transaction proxies more frequently than they would under unbiased selection.

In the paper’s scaled connection-occupation experiments, adversarial identities reportedly occupied between 7 and 11 of 12 outbound hidden-service connections after repeated restarts. Under a separate periodic-replacement configuration, they occupied between 8 and 10 of 10 connections.

In the proxy-selection experiment, one adversarial connection among 12 outgoing hidden-service peers was selected as one of the proxies in 15.3% of baseline observations. After the adversarial peer reported a manipulated blockchain height, the observed selection rate increased to 35.7%.

These figures describe the authors’ configured experiments. They do not establish how frequently an adversary could obtain the required network position across the live Monero network.

3. Associating a Tor identifier with an IP address

Receiving an originated transaction from a target initially provides the attacker with a Tor-level connection or onion identifier—not necessarily the target’s underlying IP address.

ProxyMark’s third stage encodes an identifier into the timing and frequency of selected Monero P2P request messages. A malicious Tor relay positioned as the target’s entry guard observes the resulting traffic pattern and attempts to recover the watermark.

The paper reports 100% precision and average recall of 93.8% for hidden-service targets and 91.4% for Tor-client targets in its watermarking experiments.

Those results were measured with a controlled guard configuration in which the adversarial relay occupied the required Tor position. The experiment therefore tests watermark recovery and identifier-to-IP linking conditional on successful entry-relay placement. It does not show that the adversary will automatically become a target’s guard.

The complete attack requires all of the following:

• The target uses the relevant Monero anonymity-network configuration.
• Adversarial Monero peers interact with the target and influence its hidden-service peer lists.
• One or more adversarial peers become outgoing connections and transaction proxies.
• The adversary receives a transaction through a path that identifies it as locally originated.
• A malicious or cooperating Tor relay is selected in the target’s entry-guard path.
• The protocol behavior needed to transmit and recover the watermark remains available.

Without the required Tor-side position, the adversary may associate a transaction with an onion address or Tor-level identifier without learning the target’s underlying IP address.

What ProxyMark does not prove

It does not break Monero’s transaction cryptography

ProxyMark does not recover private keys, reveal confidential amounts, undo stealth addresses or identify the true spend inside a ring signature through cryptographic analysis. Its objective is to associate a transaction’s initial network broadcast with the infrastructure from which it originated.

Network attribution can still be consequential. An adversary that associates a transaction with a particular IP address or server may obtain information about its creator even when the blockchain does not reveal conventional sender, receiver or amount relationships.

It does not decrypt Tor traffic

The proposed attack does not remove Tor’s encryption. It uses application behavior and traffic characteristics that can remain observable despite encryption.

The Tor Project’s documentation explains that low-latency anonymity systems cannot eliminate every form of timing and volume correlation. Tor’s original design also states that an adversary observing both relevant ends of a communication may confirm a relationship using distinctive timing or volume patterns, while an active adversary may attempt to create such patterns.

It does not establish universal Monero-over-Tor traceability

The target must use a relevant configuration. The adversary must obtain specific Monero peer positions, influence proxy selection and occupy or cooperate with a suitable Tor entry relay. The paper therefore presents ProxyMark as a feasibility result under stated adversarial capabilities—not automatic deanonymization of every Monero-over-Tor transaction.

The tested software version matters

The researchers used Monero v0.18.3.1 for target nodes in the role-identification, proxy-bias and watermarking experiments. Some of the mainnet measurements were conducted in 2024.

Monero v0.18.5.1 was released on July 8, 2026—the same date on which the expanded ProxyMark preprint was submitted. The study does not report reproducing its complete attack chain against that later release.

The paper therefore establishes the behavior of the versions and configurations tested by the authors. Determining which components remain reproducible requires updated source-code review, testing against current releases and independent technical scrutiny.

Probabilistic evidence is not deterministic proof

Privacy research frequently uses words such as “trace,” “identify” or “deanonymize” for findings with very different levels of certainty. Separating these categories is essential when evaluating both ledger analysis and network-layer attacks.

ProxyMark contains both deterministic and probabilistic elements. The researchers describe node-role identification as arising from deterministic differences in protocol behavior within the tested setup. Peer occupation, proxy selection, Tor guard placement and watermark recovery, however, involve probabilities, resource assumptions and environmental conditions.

Precision and recall must also be interpreted in context. A detector can perform well in a controlled experiment in which the adversary already occupies the required observation position without demonstrating how often that position can be obtained against ordinary users.

Four separate layers of cryptocurrency privacy

ProxyMark demonstrates why cryptocurrency privacy should not be reduced to one feature, ring size or anonymity score.

A system may provide strong ledger privacy while exposing network metadata. Conversely, hiding an IP address through Tor does not correct information leaked by the cryptocurrency protocol operating through it.

Ground truth, data fusion and the unequal observer

A public blockchain observer and a participating exchange do not possess the same information. They may examine the same ring, transaction or network event while reaching different conclusions because one party holds private labels that the other does not.

This distinction is examined in the 2024 Cypher Stack review, History and State of Monero Security Analysis. The review describes adversaries that participate in the Monero economy and combine public blockchain data with information obtained through exchanges, counterparties, other blockchains or network observation.

The exchange–Alice–exchange problem

The Cypher Stack review models one class of unequal-observer attack as the exchange–Alice–exchange, or EAE, game.

An exchange sends XMR to a customer and therefore knows the output it created for that customer, the amount and the withdrawal time. The customer subsequently conducts other activity. Later, the same customer—or another customer known to the exchange—deposits XMR back to the exchange.

The exchange then asks whether the returning funds may descend from the funds it originally sent. It can compare ring membership, transaction ancestry, known outputs, timing, fees and information from other transparent blockchains. Some conclusions may remain probabilistic. Other outputs may be eliminated deterministically when the exchange knows that they belong to a different customer or were already spent elsewhere.

This does not make the Monero blockchain globally transparent. It shows that a participant with extensive private transaction data may possess a substantial informational advantage over a passive public observer.

Key images do not reveal their source outputs by themselves

Monero publishes a key image for each spent input to prevent the same output from being spent twice. A key image does not, by itself, disclose which member of the associated ring was the real spend.

The difficult analytical step is establishing a reliable mapping between a key image and its source output. Such a mapping may come from deterministic historical conditions, wallet records, exchange data, a cooperating counterparty, a seized device or another source of ground truth. Merely observing a key image does not automatically provide that mapping.

Known-spent outputs can produce recursive elimination

Once an output is reliably known to have been spent in one transaction, it cannot be the true spend in any other ring in which it appears. It may therefore be removed as a candidate elsewhere.

This is the basis of known-spent-output elimination and historical chain-reaction analysis. A high-confidence identification can affect more than the transaction in which it was first made because the same output may appear as a decoy in other rings.

The recursive property also creates a major methodological risk. If an analyst incorrectly treats a probabilistic guess as a deterministic mapping, the false identification can contaminate downstream conclusions. A flawed label may cause valid candidates to be removed from other rings, creating an artificial chain reaction that appears more certain as it expands.

Confidence must not be upgraded by repetition: A hypothesis appearing in several dependent calculations is not equivalent to several independent confirmations.

Any claimed large-scale tracing method should therefore report more than selected examples or headline accuracy. It should disclose its ground truth, sampling method, precision, recall, false-positive rate, false-negative rate, confidence calibration and the effect of erroneous labels on later deductions.

Machine learning can rank hypotheses, but it cannot manufacture ground truth

Machine-learning systems can combine observable features such as output age, transaction structure, fees, periodicity, consolidation behavior and known service labels. They may then rank candidates or cluster transactions that appear statistically related.

A 2020 study, Simulated Blockchains for Machine Learning Traceability and Transaction Values in the Monero Network, created simulated Monero economies with known ground truth and extracted structural features from their public transaction graphs. The researchers reported that machine learning could assist with identifying individuals or groups in the simulations and used labels leaked through the ShapeShift API to identify likely ShapeShift-related activity on the real Monero blockchain. The method did not recover hidden transaction values.

The study demonstrates the importance of labels. A model can learn patterns from simulated or externally identified activity, but it does not transform an unlabelled, ambiguous blockchain into a fully known transaction history. Its output remains conditional on its training data, assumptions and validation procedure.

Different adversaries create different privacy risks

Privacy claims should identify the adversary against which they apply. A system resistant to a public passive observer may be weaker against an adversary that actively participates in the network or controls an exchange.

ProxyMark is most consequential in the final two threat models. It could provide network-origin evidence to an adversary that already possesses exchange records, wallet information, counterparties or probabilistic ledger hypotheses.

How weak evidence can become stronger across layers

Consider three hypothetical observations:

1. A ledger-analysis model ranks one ring member as more likely to be the true spend than the other members.
2. A network observer associates the transaction’s initial propagation with a specific node or IP address.
3. An exchange or merchant possesses private records connecting that IP address, withdrawal time or payment request to a known user.

None of these observations may be conclusive individually. Together, they may substantially narrow the set of plausible explanations.

This is where the Monero Project’s OSPEAD research becomes relevant.

At the time of the OSPEAD publication, Monero used a ring size of 16: one real spend and 15 decoys. A uniform guess would therefore have a 1-in-16 probability of selecting the true spend.

The OSPEAD article reported that differences between actual user spending patterns and Monero’s decoy-selection distribution could allow a Maximum A Posteriori decoder to rank the correct spend first with an estimated probability of approximately 1-in-4.2.

This does not mean that an analyst can deterministically eliminate approximately 12 ring members, or that Monero’s literal effective ring size is always 4.2. The highest-ranked candidate would still be incorrect in most individual cases. OSPEAD describes a probabilistic advantage over random guessing, not certainty, and the Monero Project noted that the research had not yet been formally peer-reviewed.

FCMP++ would change the ledger analysis—but not the network problem

Monero is developing Full-Chain Membership Proofs++, or FCMP++, as a major replacement for its current fixed-size ring-membership model. Instead of proving that the real spend is one member of a selected ring of 16 outputs, FCMP++ is intended to prove that the consumed output belongs to the full eligible set of outputs represented by the blockchain’s membership structure.

If successfully deployed, FCMP++ would substantially change the ledger-layer analysis discussed above. Decoy selection would no longer determine which 15 alternative outputs appear beside the real spend, removing the specific probability-distribution mismatch that OSPEAD is designed to address. Many conventional ring-member ranking, known-decoy and decoy-elimination techniques would therefore not apply to post-FCMP++ transactions in the same form.

FCMP++ would not, however, conceal where or how a transaction enters the peer-to-peer network. A transaction could possess full-chain sender privacy at the ledger layer while still exposing its originating node, onion identity, source IP address or traffic pattern through the network layer. ProxyMark therefore concerns a privacy problem that FCMP++ is not designed to solve.

As of August 2026, FCMP++ remains under development and integration rather than active on Monero mainnet. Its expected protections should therefore be described as planned properties until the final consensus implementation, wallet integration, deployment and independent review are complete.

The Monero OSPEAD article itself emphasizes that probabilistic guessing becomes more relevant when combined with other deanonymizing attacks. A network-origin signal could help an investigator validate, reject or reweight a probabilistic ledger hypothesis. Likewise, private exchange or merchant records may provide context unavailable from the public blockchain.

This does not prove that combined analysis will succeed against arbitrary Monero transactions. It explains why privacy systems must minimize leakage at every layer rather than assuming that uncertainty in one layer will compensate for information exposed in another.

Where Dandelion++ fits—and where it does not

Dandelion++ was designed to make it more difficult for ordinary P2P observers to identify which node originated a cryptocurrency transaction. It separates propagation into a stem phase, in which a transaction follows a limited path, and a fluff phase, in which it diffuses more broadly.

This can improve origin privacy compared with immediate network-wide broadcasting. It is not equivalent to a general-purpose mixnet, and it does not eliminate every threat involving colluding peers, topology knowledge, connection manipulation or active attacks.

A 2023 NDSS analysis of P2P anonymity schemes modeled Dandelion, Dandelion++ and the Lightning Network using Bayesian inference. Its authors concluded that the evaluated configurations provided limited anonymity under adversarial observation and that increasing network size did not necessarily increase the effective set of possible transaction originators.

That research is not a reproduction of ProxyMark and should not be presented as evidence of the same attack. It instead demonstrates that lightweight transaction-propagation schemes have their own threat models and measurable limits.

A subsequent NDSS 2025 study of Monero’s P2P network introduced a connection-reset technique intended to replace a target’s benign connections with attacker-controlled connections. The researchers evaluated the method against Monero mainnet and reported that differences in Dandelion++ stem and fluff propagation could be used as part of the connection-reset process.

The eclipse study and ProxyMark are distinct attacks. Together, however, they show why connection management, peer diversity and application-layer message handling belong inside the network-privacy threat model.

A timeline of Monero traceability and network-privacy research

Research findings must be interpreted according to the protocol version and period studied. Early Monero results should not be applied directly to current transactions, while newer findings should not be assumed to affect configurations that were not tested.

The ProxyMark authors’ proposed mitigations

The researchers outline protocol changes intended to interrupt each stage of their framework.

• Remove the repeated onion-address fingerprint: Advertise a node’s own onion address only during the initial handshake rather than repeatedly placing it in a predictable timed-sync position.
• Make originated and relayed traffic less distinguishable: Extend stem-style forwarding across hidden-service connections so that a transaction arriving through an internal-Tor connection could be either originated or relayed.
• Harden peer-list handling: Verify onion-address reachability and limit the number of addresses accepted through peer-list messages.
• Verify synchronization claims: Compare heights reported by hidden-service peers with a network height independently verified through public peers.
• Constrain message timing: Enforce fixed rates for messages used by the watermarking channel and disconnect peers that violate those limits.
• Require completed handshakes: Reject relevant protocol messages before handshake completion, reducing opportunities for low-noise watermark injection.

The paper distinguishes between mitigations that remove a root cause and measures that only raise the attacker’s cost. Making originated and relayed transactions indistinguishable addresses the central forwarding asymmetry more directly than simply reducing the probability that an adversarial peer is selected.

What ProxyMark means for Ryo’s high-latency mixnet

Ryo’s planned privacy architecture separates ledger confidentiality from network-layer anonymity. Its proposed Halo 2 transition is intended to protect transaction information, while the proposed high-latency mixnet is intended to conceal broadcast origin, communication timing and routing metadata.

This architectural separation is technically justified. A zero-knowledge proof system may validate a transaction without exposing protected ledger information, but it does not determine how that transaction reaches the network. Transport and propagation remain separate sources of observable metadata.

Ryo’s earlier analysis, How Halo 2 and a Mixnet Protect Against Timing and Metadata Attacks, describes the intended complementary roles:

• Halo 2: Protect transaction validity and concealed ledger information through zero-knowledge proofs.
• High-latency mixnet: Disrupt observable relationships between transaction origin, network timing, routing and eventual broadcast.

ProxyMark supports the rationale for this layered design. It does not prove that Ryo’s eventual implementation will resist equivalent attacks.

The relevant question is therefore not whether Ryo plans to use a mixnet. The question is whether the completed design can demonstrate specific, testable security properties.

Testable engineering requirements for Ryo’s mixnet

These requirements move the discussion beyond promotional labels. “High latency,” “cover traffic” and “mixnet” describe design components, not measured security outcomes.

A credible implementation should publish the adversary it is designed to resist, the assumptions on which its protection depends and the conditions under which anonymity degrades.

The correct interpretation

The most accurate conclusion from the new research is neither “Tor has failed” nor “Monero is completely traceable.”

The stronger conclusion is that privacy can fail at the interfaces between otherwise valuable systems.

Tor may hide a node’s IP address from its Monero peers. Monero may conceal amounts and transaction relationships on-chain. Dandelion++ may make ordinary first-spy analysis more difficult. Yet the composition can still leak information if application roles, peer lists, control messages and forwarding paths remain distinguishable.

Likewise, a ledger heuristic may be too uncertain to identify a true spend by itself. A network-origin observation may be insufficient to reconstruct a payment. An exchange record may reveal only one endpoint. When these observations are combined, however, their joint evidentiary value may be substantially greater.

The practical privacy of a transaction therefore depends not only on what is publicly visible, but also on:

• What the adversary already knows
• Which network or economic positions the adversary controls
• Whether the available signals are independent or derived from one another
• How accurately uncertain evidence is calibrated
• Whether an initial false attribution can contaminate later deductions

For cryptocurrency developers, ProxyMark reinforces several principles:

• Encrypted traffic can still expose metadata.
• Protocol-control messages belong inside the privacy threat model.
• Origin privacy depends on peer selection as well as packet routing.
• Locally originated and relayed traffic should not expose reliable behavioral differences.
• A key image does not reveal its corresponding output without additional information.
• Probabilistic evidence must not be described as deterministic identification.
• Anonymity sets are observer-relative when some participants possess private ground truth.
• Machine-learning outputs require ground-truth validation and false-positive measurement.
• Improvements to ledger privacy do not automatically protect transaction-broadcast origin.
• Anonymity claims should identify the adversary and assumptions against which they apply.
• Findings against one software version should be retested against current implementations.
• Privacy must be evaluated across the ledger, wallet, P2P and transport layers together.

Conclusion

ProxyMark presents a technically significant claimed attack against specific Monero-over-Tor behavior. Its experiments indicate that an adversary with suitable Monero peer positions and Tor entry-relay visibility may be able to identify originated transactions and associate them with a source IP address.

The research does not establish that all Monero-over-Tor transactions are traceable. It does not defeat Monero’s transaction cryptography or decrypt Tor circuits. Its experiments evaluate separate attack components under defined configurations, including controlled Tor guard placement, and use Monero v0.18.3.1 for several stages.

Nevertheless, the research exposes an important architectural concern: ledger confidentiality, wallet privacy, P2P propagation and IP-hiding transport are different security layers. Protection at one layer does not neutralize metadata leaked by another.

The OSPEAD findings provide a parallel lesson at the ledger layer. Ring members may remain cryptographically valid candidates while still receiving unequal probabilities from an analyst. A network-origin observation could then strengthen or weaken that probabilistic inference.

FCMP++ is intended to remove the fixed-ring and decoy-selection structure underlying that form of ledger analysis. It would not, however, prevent a network observer from studying where a transaction entered the network or how its traffic propagated. The distinction further demonstrates why ledger privacy and network anonymity must be engineered separately.

The ground-truth problem makes this more consequential. A public observer, exchange, recipient, network operator and device investigator may each possess different information about the same transaction. A privacy system must therefore be evaluated against unequal observers—not only against an outsider examining the public blockchain in isolation.

This is why full-stack privacy cannot be established through one headline metric, one anonymity network or one cryptographic primitive. It depends on ensuring that separate components do not expose signals that become decisive when combined.

For Ryo, ProxyMark supports the decision to treat network anonymity as a dedicated component of its future architecture. It also creates a demanding benchmark. Ryo’s eventual high-latency mixnet should be judged by a published threat model, originated-versus-relayed message indistinguishability, route-concentration resistance, active-watermark testing, cross-layer data-fusion experiments, compromise-containment analysis, reproducible simulations and independent review.

A privacy roadmap becomes credible when its security claims can be translated into tests—and when external researchers are able to try to break them.

Primary sources and further reading

• Shi et al., Deanonymizing Monero Transactions in Tor Network, 2026
• Shi et al., Deanonymizing Transactions Originating from Monero Tor Hidden Service Nodes, 2024
• Monero Project, Anonymity Networks with Monero
• Monero Project, Monero 0.18.5.1 “Fluorine Fermi” Released, 2026
• Tor Project, Attacks Against Onion Routing and Remaining Limitations
• Dingledine, Mathewson and Syverson, Tor: The Second-Generation Onion Router
• Shi et al., Eclipse Attacks on Monero’s Peer-to-Peer Network, NDSS 2025
• Sharma, Gosain and Diaz, On the Anonymity of Peer-to-Peer Network Anonymity Schemes Used by Cryptocurrencies, NDSS 2023
• Rucknium, OSPEAD—Optimal Ring Signature Research, Monero Project, 2025
• Parker, FCMP++: Full-Chain Membership Proofs + Spend Authorization + Linkability, 2024
• Monero Project, FCMP++ Hard-Fork Development Milestone
• Berman, Deprecating Monero’s Custom Transaction Unlock Time, 2026
• Cypher Stack, History and State of Monero Security Analysis, 2024
• Borggren et al., Simulated Blockchains for Machine Learning Traceability and Transaction Values in the Monero Network, 2020
• Hammad and Victor, Monero Traceability Heuristics: Wallet Application Bugs and the Mordinal-P2Pool Perspective, 2024
• Hinteregger and Haslhofer, An Empirical Analysis of Monero Cross-Chain Traceability, 2018
• Möser et al., An Empirical Analysis of Traceability in the Monero Blockchain, 2017/2018
• Ryo Currency’s High-Latency Mixnet vs. Tor and VPNs
• How Halo 2 and a Mixnet Protect Against Timing and Metadata Attacks