Creating an exchange with private reserves presented unique challenges. A token's price is typically derived from the ratio of reserves between tokenA and tokenB, which means revealing the price could inadvertently disclose information about the reserves. To address this, we adopted a strategy that involves dealing with ratios when accessing reserve information. As a result, the only potential information leakage pertains to the ratio itself, rather than the actual reserve amounts. While its possible there still might be some data leakage about the reserves given certain circumstances, This method better ensures the confidentiality of reserve quantities.

The encryption library we uses introduced new Solidity data types specifically designed for encrypted integers and booleans. However, these new types come with computational limitations that become more pronounced as their size increases. The largest data type we could efficiently use was euint16, as euint32 proved to be computationally prohibitive and could exceed the block size limit, making some functions too large to execute within a single block. A more production-grade dex would require larger encrypted integer values to properly handle the math needed and mitigate underflow and overflow errors.