Mystic DEX

Mystic DEX combines fully homomorphic encryption, verifiable proof of personhood and cross chain interoperability to empower a more secure and private environment for users. User's can take advantage of encrypted swaps on Fhenix without needing to have existing funds on that chain, they simply send tokens from their chain of choice and we handle the cross-chain minting, burning, swap and redemption on behalf of the user.

Conventional automated market makers and public token pools expose users to a myriad of negative effects, such as front-running, sandwich attacks, alpha leaking and public paper trails. Our goal is to give each user more control over the visibility of their on-chain actions and token swaps. We want to enable the user to engage in the blockchain ecosystem without unnecessary exposure to negative externalities.

For managing and testing our smart contracts we used Foundry. To create a UI and to connect the frontend with the entry point contracts we used React, Viem and Wagmi. To verify the users proof of personhood we used the worldidkit from WorldCoin to interact with the verifier contracts on the user’s source chain. To bridge between the source chain and Fhenix we used Hyperlane V3 which allowed us to deploy our own custom sending/receiving contracts to the source and destination chains aswell as our own verifier and relayers with custom signing thresholds. One of the big benefits of utilising Hyperlane is the customisability, we could bridge to Fhenix which is not natively supported. We were not restricted to only the currently supported chains like other cross chain technologies and protocols.

We faced many challenges while developing our solution, such as familiarising ourselves with these new technologies and trying to implement and MVP within the allotted timeframe. An interesting problem we faced was working with encrypted calldata and private swaps on Fhenix. We needed to adopt the encrypted primitives and learn how to work with these new paradigms. This took time to master, especially since encrypted booleans cannot be used in a the conventional way in an if/else control flow tree. We needed to use select statements instead, sometimes needing to chain multiple statements together to achieve a simple if/else if/ else flow that is very straightforward with primitive Solidity types. We also faced challenges when setting up the new Hyperlane messaging service, since nobody on our team had used Hyperlane before. So it took time to understand how the ISM and custom chain configurations work. We also needed to create a custom process for sending ERC-4626 vault tokens using warp routes, since there was no pre-configured way of doing this with Hyperlane. We also had to wrestle with Viem in our frontend codebase to allow for easy ERC-20 token transfers.