This repository contains the final result of Orakle Dark Pool Team's hard work and is submitted to ETHOnline 2024. Fugazi is the first fully on-chain dark pool built on Fhenix. Unlike many other dark pools, Fugazi does not require any external or centralized entity to work, thanks to the fully homomorphic encryption (FHE) supported by Fhenix Helium Testnet.
Dark pools are equity trading systems that do not publicly display orders. They enable large trades to be executed in private manner so that the traders get better price for their orders.
Although the order is not public, the exchange operators can still see user orders and exploit them. This is not a mere conspirancy theory; See these examples. This happens because of the trust assumption that the trusted & centralized entity, in this case, exchange operators, will act honestly. Through the trustless and decentralized dark pool, users can benefit from the better execution without risk of being exploited.
Fugazi usese following 3 tools to hide order information:
- FHE
- Batch Execution
- Noise Order
Fully Homomorphic Encryption (FHE) is a emerging cryptographic scheme that can process data blindly (i.e., without decryption) without compromising transparency and usability. By leveraging FHE supported by Fhenix's Helium testnet. We store and process user balances, pool reserves, and order information such as size and direction.
AMM with encrypted reserves is not enough for privacy. See following studies. TL;DR of these studies are: 1. The attacker can discover user order through sandwiching it, and 2. Batching is inevitable to mitigate such attack vector. Instead of authors original proposal (randomize order priorities then execute them one by one), we clear them in uniform price. We adopted specialized AMM curve for batching, called FM-AMM. FM-AMM itself has another positive effect, too. The more arbitrageurs are trading against our pool, the total cost of pool paying to arbitrageurs decay by 1/N. For more details check this article.
There is one more way of hiding user order from attacker. As introduced in here. By forcing protocol-owned account to submit randomized order and pay protocol an additional fee for providing privacy, users can hide their order without batching. The additional fee is expected profit of arbitrageur from exploiting the post-trade state. We adopted this method too. Users can set the degree of noise up to 200%. This will be especially useful whenever there are not many orders in given batch.
We built a dark pool that does not require any external or centralized entity to run. User orders' information is hidden through either batching or adding noise (and pay fee). Our dark pool supports UX that is as same as most of existing DEXs such as Uniswap, Curve, Balancer, etc etc, except users have to wait for a while after submitting order.
SoK: Privacy-Enhancing Technologies in Finance
MPC Joins The Dark Side
An Efficient Data-Independent Priority Queue and its Application to Dark Pools
Optimal Trade Execution in Illiquid Markets
Optimal liquidation in dark pools
Liquidation in the Face of Adversity: Stealth vs. Sunshine Trading
Do Dark Pools Harm Price Discovery?
Diving into dark pools
Regulations of EU Financial Markets
A Note on Privacy in Constant Function Market Makers
Differential Privacy in Constant Function Market Makers
Pricing Personalized Preferences for Privacy Protection in Constant Function Market Makers
Automated Market Making and Loss-Versus-Rebalancing
Automated Market Making and Arbitrage Profits in the Presence of Fees
The Cost of Permissionless Liquidity Provision in Automated Market Makers
Notes on the LVR of FM-AMM
The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response
Frequent Batch Auctions and Informed Trading
The Market Quality Effects of Sub-Second Frequent Batch Auctions: Evidence from Dark Trading Restrictions
Augmenting Batch Exchanges with Constant Function Market Makers
Arbitrageurs' profits, LVR, and sandwich attacks: batch trading as an AMM design response