Strawberry ChocolateFudge requested to merge Strawberry/ccs-proposals:homomorphic_dex_infrastructure into master Feb 11, 2026

Homomorphic reputation and order matching layer to increase privacy against cross-domain metadata-correlation attacks when trading on DEX

I want to propose to build a system that does what the title says, and I will explain here the details

The Problem

A cross-domain metadata-correlation attack can be used to target traders who use decentralized applications like Haveno or Atomic Swaps, if they use them often and there are identifiable patterns in their usage. High reputation traders are more exposed as they attract a possible attack more likely.

The attack is based on leaked metadata and acquired trading data and transaction correlations, and it's exposed by the decentralized exchange or the third-party blockchain/FIAT payment system. Monero is well protected against the attacks by itself but the systems it relies on for trading have possible attack surfaces. The goal is to make them less open, because they can't really be mitigated fully. Usage will always have patterns.

First I will analyze an exchange like kinda like Haveno and the possible attack scenario.

Maker M has reputation X that is visible by trade count, it gives Takers an incentive and trust to use him. However high profile traders are a target.

In this scenario Attacker A will have law enforcement privilages. So attacker A identifies high profile trader M by trust score and initiates a trade to swap XMR to Fiat.

M and A complete the trade using Escrow (E) and then finalize it. However A has acquired metadata about the transaction, the bank account of M.

Now using the law enforcement privilages, A uses a warrant to acquire the bank transaction details of account M which reveal the past payments using the account and their personal address.

Now A is able to analyze metadata by consitently watching the reputation score and then comparing the acuired bank details to speculate on outgoing payments. The attack is restricted to the tracked modalities that can leak data, but using cross-referencing a lot of data can be collected about individuals.

A is able to correlate transactions with Dex observed changes.

This attack can't be fully mitigated, using Fiat transfers will always have this inherent weakness of law enforcement observability, however we can hide the reputation score of M to make selecting targets harder.

Another scenario is when the order book itself is public. It can happen because the exchange is a decentralized atomic swap or simply because hiding it is quite complex and out of scope for Dex developers.

Correlating transactions with Dex trades on a public orderbook and then performing chain-analysis can reveal high-profile traders and their transactions can be tracked till CEX deposit.

Again, it's hard to hide this information due to the nature of public chains so a XMR-BTC swap can be always tracked on the BTC side unless it passes through a mixing mechanism which will still mark it "tainted"

However we can decrease the attack surface by hiding more metadata from plain sight and making the targeting of individual traders harder.

Proposal Overview

Separate the trust layer from the order matching by developing a distributed order matching system that uses homomorphic encryption internally and allows hiding these details, and it could serve as an encrypted order book that will hide more information than before possible. Some data will leak (the intent of an unknown participant to trade) but the analyzable data leak can be meaningfully decreased.

The trading should occur on a different layer, so the proposal is to divide it into two layers:

layer 1 for order matching (order book and reputation processing)
layer 2 a pluggable settlement layer that can have custom implementations.

So the main focus is implementing layer 1 and then implementing layer 2 as a framework that provides abstractions to work with layer 1 and can be customized by developers.

This allows separating concerns and focusing on the goals. One of the problem domains is where to place the trust, the system I propose operates trustless on layer 1 and then layer 2 implements custom trust models, an escrow based layer 2 would need trust in escrow etc...

So layer 1 works using homomorphic encryption and uses a distributed network of nodes and clients that communicate over Tor. I can specify the networking layer later, but it should use existing established patterns.

The role of nodes is to perform homomorphic compute and query the other layers. The nodes have no insight into the computation they perform as it's encrypted, they are an ephemeral layer that forwards information after performing the homomorphic compute.

Homomorphic encryption uses Public key cryptography and allows an encrypted data to be operated and combined with other encrypted data that was encrypted with the same public key. It's mainly using integer or floating point arithmetic. After performing operations only the owner of the private key can decrypt it

It's possible to implement an encrypted reputation system, order book and secret data sharing. It does require back and forth communication between the clients and nodes as I will explain with images.

Github link for images: https://github.com/StrawberryChocolateFudge/dex_proposal_1/blob/master/architecture_drawings.png

Software architecture

Layer 1 is made up of 3 parts:

Layer1 daemon (layer1d) is the ephemeral homomorphic encryption provider and distributed node that is available on the open web as endpoints. It's trustless. Layer1d instances gossip to each other the information about layer2s they know of, and maintain their own internal keys however they have no insight into the data they process other than the fact that a client is using it and then later which layer 2 the client chooses.
Layer 1 client is the user facing client directly connecting to layer1d. It should work in the browser with wasm compiled binary and allows connecting to the system for match making.
Layer 1 ipc daemon (layer1ipcd) is the third part which is a local daemon for connecting layer 1 with layer 2 and can be accessed over IPC. This provides APIs for communicating with layer1d and an easy interface that can be used over IPC from any language.

Layer 2 can be written in whatever a user chooses, it communicates via the IPC daemon to Layer 1. Every dependency required for Layer2 to interact with the system is in the layer1ipcd so the users who implement the settlement layer have full freedom over their tech stack however layer1ipcd maintains its own private key when interacting with layer 1, so it's a private instance that can't be exposed directly to users.

Another benefit of these layers is that it lowers the barrier of entry for entrepreneurial developers who want to focus on innovative swaps/escrow systems but not reimplement all the order book networking over and over again and build on a privacy focused system.

The Cryptography

Homomorphic Cryptography is created using Brakerski-Gentry-Vaikuntanathan (BGV) homomorphic encryption schemes. BGV is considered post-quantum safe.

It provides modular arithmetic over the integers which is enough to develop a homomorphic engine for layer 1 match making that runs inside layer1d

I will base the implementation on this example: https://github.com/tuneinsight/lattigo/blob/main/examples/singleparty/bgv_ride_hailing/main.go

No need to completely reinvent the wheel, because the example application can be repurposed for the exact usage I want (Instead of matching for nearest coordinates it would match reputation and order parameters).

So the software stack is go, obviously to use this dependency. Go should work well in WASM too, so it's flexible.

For the encryption the taker needs to generate custom keys, pass the public key to the layer1d then that layer passes the public key to layer 2s where the reputation and available orders are encrypted. Then the layer 2 passes the cipher text back to layer1d that performs homomorphic operations to determine what is the best match (high enough reputation and matching order) and then forwards the match to the Taker. The taker can then decrypt the information and use a link or other method to redirect to layer2 and begin trading with the maker.

The taker never learns the reputation of the maker or the available volume.

The layer 2 can still be vulnerable to attacks if it uses the banking system for one side, however correlations are much harder to detect and an attacker can't monitor the reputation of a maker or see their orders.

Layer 2 and it's interactions with Layer 1

Okay so layer 1 is an ephemeral system that anyone can run, and its main tasks are messaging and homomorphic compute. What about layer 2? So the interaction with Layer 1 happens through the IPC daemon on the server in this proposal, with possible Wasm compatible implementation later to port the layer 1 tooling to browsers.

The layer 2 is the trust layer that finalizes the trade, it will connect to layer 1 with an API that exposes a lot of functions to allow integration into the system. Layer 2 doesn't have to be written in the same language because all the homomorphic encryption tooling should be available via the local layer 1 ipc or Wasm dependency.

Layer 2 could be an escrow similar to haveno or atomic swap or something new. It's important to make it open as this creates a pluggable ecosystem.

FAQ

Is it trustless?

Layer 1 is a trustless architecture, layer 2 needs to implement its own trust mechanism. An Escrow would be trusted, atomic swaps can be trustless

Where does monero come in?

This project simplifies DEX development by providing an infrastructure that is privacy focused and builders can implement custom XMR trading interfaces without rewriting the order book system over-and-over again.

It's aimed at the monero community because privacy is appreciated here, and even incremental improvements are great. So think of it like a framework for DEX applications where privacy is built into the foundational levels so atomic-swap or other exchange developers got a framework to work in.

Does it fit with new monero upgrades?

Yes , layer 1 is separated and doesn't care about Monero version, Layer 2 however will be working closely with it, and it should support newest monero versions as needed.

Are there any fees or monetization?

No, this is a public good. No mining, no fees but the homomorphic compute must be donated. Anyone can join and participate and help secure the trading.

Is it anonymous?

Yes, layer 1 can operate its networking layer on the tor network if a rendezvous point is established, so nodes can gossip about the available exchange layers and stay hidden. The clients are identified by public keys.

Who benefits the most?

Whales and high volume traders can hide better, they leave less reputation or order book traces. So if somebody wants to trade large volumes in many trades they benefit by blending in better.

Where is reputation stored? Is it trusted?

Ranking data comes from layer 2. In-case of an escrow its trusted and comes from the escrow itself. The escrow can always see every transaction it participates in any way it's a point of trust.

If it's an atomic swap the reputation for layer 2 can come from a smart contract or an atomic swap provider server. It's very flexible. If the reputation is stored in a smart contract, further privacy features like ZK proofs can be also used.

Will you create a layer 2 also or just layer 1?

I will create a layer 2 templates that is verified to function. So developers who want to operate layer 2s can build one easily. I will start working on Layer 2 when layer 1 is complete to make sure they work together well.

Can a malicious layer1d node find out information?

So here is a possible attack scenario, attacker sets up a layer1d and then uses his own public key to collect trading information about layer2 traders. This attack can be mitigated in two ways:

layer1ipc can't just submit raw information to layer1d, it must do homomorphic preprocessing that smooths real data, so the malicious layer1d will just get processed information. It can deduce what Maker can match the order, but not the available volume or the real reputation or transaction history.
layer2 must rotate the identity of Makers, so an identity that matches once with a Taker should be usable only once. This way a malicious layer1d can't track a Market Maker because there is no repeating identity to analyze.

Can it be DOS attacked?

Yes, that's possible however connections can be just dropped and blacklisted by the nodes. There is no large network to DOS, it's all modularized, so it's not like a blockchain can be filled with data. Individual participants can attack each other, just like any web server can be attacked but if only one node is getting attacked the others are fine. The same mitigation rules apply as any web servers.

How will the taker determine what maker to match with?

The Taker will get a set of weights that allow it to determine the closest match and then encrypted information about which layer2 to contact and a special nonce that identifies the maker. Nonces should be time limited and expire and specific to the session, so they can't be reused after a while. More specs will be available as I switch working on this full time.

layer2 is public?

Yes, they are public but initial interaction with them should be done only through layer 1, anyone running the nodes will learn about all the layer2s, but they should be only accessible for trading after data passes through the homomorphic processing system and the takers receive the nonces to access the makers.

Why golang?

I chose it because It's easy to develop and has the lattigo library which is exactly suited for this use-case.

Alternatives are C++ OpenFHE lib which is a very good lib but C++ dev is more nuanced for distributed node software.

Rust has a good homomorphic library from Zama, but it is actually patented, so that can be only used as a last resort.

If the go implementation has issues I am flexible to rotate languages to use a different lib, but so far it seems the best and the examples function well.

Isn't the name layer 1 confusing?

I can understand that people think in blockchains for them layer 1 means something else in this case think of it as a DEX information processing layer that is separated from the payment processing layer. It's really a layer that processes information and blends it.

Is AI Involved?

No, I use AI for some things like querying docs or while I'm brainstorming, but AI will never directly see or touch the code. Everything in the codebase is human written and reviewed. So I use AI like to figure out a low-degree polynomial that transitions smoothly from 0 to 1 for implementing homomorphic smoothing, but I will not use AI to generate code. I prefer to use it to distill information and help me learn, but not for directly creating stuff. Except maybe for some smaller helper functions.

This is Research?

It's Research and Development. The final result will be fully functioning production system.

About the author

I am an autodidactic software developer with 10 years in software, a fullstack dev, cryptographer, hackathon winner and grant funded Applied ZKP researcher, creating tooling for other blockchain ecosystems. I like thinking in logical systems and like to find the best solution possible always. I have a strong interest in solving problems using homomorphic encryption and I think there is a strong use-case here.

I made one single small contribution to monero codebase once.. yeah I have to mention that. :)

Funding

This request considers an XMR price of 320 USD since it's been very volatile.

The requested funds are 180XMR

I would request a pre-payment of 10 XMR for starting work, so I can switch to full time work instantly.

Then:

Completing a specification and implementation of a homomorphic engine for reputation and order processing: 20XMR

Completing layer1d: 50 XMR - Includes the running homomorphic engine and networking and all the challenges involved in creating the daemon.

Completing layer1client and layer1IPC: 50XMR - Includes the clients, the APIs facing the users and the layer2s

Finishing and completing an example Layer2: 50XMR - The project reaches a deployable version and has an example Layer2d

There is a lot of pro bono work involved of course. Creating a "standardizable" reputation system that works with multiple layer2s will have its challenges. I am happy to spend all my time on the subject.

The duration of the work is the next 2 years. I can spend 2 years straight working on this. I will possibly finish in 1 but then have time for doing more.

Please ask me questions and give me constructive feedback about this proposal and let me know if there are issues. If there is logical reasoning on why something is incorrect I will be happy to change things around.

Contact: [email protected] @strawberrychocolatefudge:matrix.org

Homomorphic Dex infrastructure to increase privacy against cross-domain metadata-correlation attacks