Privacy Focussed DEXs and Building it on Aztec!

DeFi today is designed to operate in a completely transparent state. E.g. for an AMM, traders or liquidity providers want to know existing reserves and volume in a pool. Indeed, an FHE (Fully Homomorphic Encryption) based AMM may be possible, but it comes at the cost of losing analytics and speed.

So how would you build a privacy-focused DEX or a DEX on a privacy network like Aztec (an L2 that has composability across private<>public state)?

My goals for this doc are:

  1. Get feedback and collect any thinking others may have done on this topic
  2. Nerdsnipe you
  3. Invite you to build your idea on Aztec!

Table of Contents

  • Privacy DEXs:
    1. Naive Constant Product AMM slapped with privacy - what are the minimal modifications we can make to uniswap v2 to make it private?
    2. Splitting/Batching flow on AMM - obfuscating the swap amount
    3. Onchain OTC Settlement
    4. Private RFQs
  • Future Work
  • Aztec Alpha Programme - a programme to build DEXs on Aztec
  • Appendix

Privacy DEXs:

1. Naive Constant Product AMM slapped with privacy

Users can start their private transaction of swapping or providing liquidity privately (or from a “private” function (or off-chain), but then they must interact with the liquidity pool in public (so people can track the volume and liquidity). So, in each case, you would need to call a public function that updates the pool with the new amounts of tokens. So this design would leak the amounts of tokens swapped but not the account that performed the swap or who redeemed the output tokens

Privacy Assessment:
We can hide the user address but tokens to swap and input/output amount will be public. You may think of this as “Privacy for the user, transparency for the protocol”.

2. Splitting/Batching flow on AMMs

If we can’t hide the amount in Design 1, can we somehow obfuscate it
Broadly, there are two ways:

  1. Splitting flow - split value into random sub-amounts and call the AMM for the small amounts.
  2. Batching flow - You batch multiple users’ trades and execute them in one go. And later users can claim their pro rata share.

Flow 1 has worse UX as it requires users to be aware of splitting their amount and doing multiple calls.

A combination of both flows helps alleviate some of that. You could deposit your private tokens into a contract and then the contract divides it into smaller amounts and a 3rd party (solver) executes transactions for you. It can also aggregate various users’ intents and swap them all simultaneously. Penumbra’s ZSwaps deserves a shoutout for this design. Ref here. The user encrypts their amount and the solver adds all the encrypted amount to find out the final amount.

Here you encounter the paradigm of a “shared private state”. Typically this requires additive holomorphic encryption which is simpler than FHE.

Privacy Assessment:
This leaks the total amount and tokens to swap but not the individual user’s intent.

3. Onchain OTC Settlements

Instead of using an AMM (a shared pool), you enter into 1-1 private negotiations between parties off-chain. They select their preferred party at an agreed-upon swap rate. The user deploys a private contract with the agreed-upon parameters (swap rate, tokens). Both the user and the party enter their funds into this escrow and settle/swap onchain. For people to send notes to a contract and still keep them private, the contract must be deployed with a key that it can use to encrypt/transfer out the notes. This key can be a shared key generated by the user and the 3rd party.

Privacy Assessment:
The party sees everything but from the perspective of the network participants, everything is private! But of course, you need to find a party to trade with you off-chain. Therefore this is quite simple and synergistic with privacy

4. Private RFQs

RFQs like Cowswap provide superior UX due to their gasless nature and more MEV Protection guarantees than using an AMM.
Solvers could create a batch of user requests off-chain and the solver can settle publicly but individual users can redeem the output tokens privately (read Appendix on how to do this)

Privacy Assessment:
Individual trades are privacy-protected from the rest of the network but at the cost of latency. Solvers would see individual trade requests (but not necessarily the user’s address, like with the naive AMM implementation).

What if we integrate the Private RFQ with SUAVE?
:eyes: :eyes: :eyes:
This deserves a separate post that exists here

Future Work - MEV and Arbitrage

Privacy networks generally come at a tradeoff of latency and speed. This massively impacts how to arbitrage and MEV on such systems and DEXs. This is an under-explored area. SUAVE may help with some of the MEV protection but more research is needed to map out this landscape.

If this is interesting to you, reach out to me here or at rahul [at] aztecprotocol [dot] com

Aztec Alpha Programme

If you have read on so far, you deserve some alpha!

Aztec is running an incentivized guided ecosystem programme to explore how DEXs would look on the Aztec network! The programme runs from April 7 - May 4th, has a prize pool of $15,000 and provides dedicated technical and marketing support for the builders. More info here. If you are keen to participate, there is a 1-minute survey waiting for you

You will build on the Aztec Sandbox, which is a local development environment (similar to Anvil). Aztec is not EVM compatible and has a custom execution environment with its own rust-inspired smart contract language, built using Noir!


Most of the above schemes spoke about how users may be able to redeem their output tokens in private even if their swaps were public. How is this possible?

In general, when giving your swap intent, the user specifies a hash of a secret. A solver creates a public note (UTXO) and encrypts it with a secret hash. A user can decrypt this note by specifying their preimage and therefore claim their note.

An Aztec-specific way to do this is detailed here


Hi @rahul.kothari, thanks for the post!

Could you elaborate on this motivation to make a privacy-focused DEX?

Trading mechanisms are very deliberate about the information they reveal about market participants. In some exchanges, you may know more about your counterparty than in others. For example, in certain limit order books, you may not know anything about your counterparty, whereas in over-the-counter markets, you will know exactly who the counterparty is.
Knowing who your counterparty is is important because you may not be willing to trade against a very sophisticated party, but you are willing to trade against uninformed traders.
Currently, information about traders is not often exploited in on-chain DEXs, but I think there is an opportunity to do so. Relying on people self-declaring information does not necessarily lead to the best trade execution because you may need some informed flow to update prices.

What is your view on this? How do you preserve price efficiency of DEXs when there the DEX is privacy-focused?

1 Like

Hey @Julian thanks for the question.

motivation to make a privacy-focused DEX

Aztec is a privacy preserving L2. Currently, blockchains can appear almost creepy given everything is permanently public. I also think this is one of the reasons that prevents mass adoption.

How do you preserve price efficiency of DEXs when there the DEX is privacy-focused?

This is an open question in the designs we are exploring, and is part of a reason we are exploring how DEXs could work on Aztec and have a programme dedicated to just that.

But the real design space here is what needs to be private and to whom? E.g. you could have RFQs where solvers batch a bunch of trade intents. Solvers give it to market makers who then work together (in public) to settle trades publicly, and users can trade privately.