Aphotic is a decentralized exchange (DEX) with performance of a centralized exchange (CEX) and strong privacy guarantees built on Aleo. Aphotic not only combines the best of the two worlds - efficiency of a CEX and self custody of a DEX - but also offers privacy, front-running protection and dark pool functionality without a need to trust DEX operators.
Here we will look at how Aphotic improves on existing solutions by using Aleo and off-chain private computations.
TLDR: Aphotic is a rollup order book and dark pool DEX with CEX performance and pre-trade, trade and post-trade privacy guarantees achieved by blazing fast trade execution in hardware enclaves and zero-knowledge proofs secured settlement.
There are three widespread archetypes of crypto exchanges:
centralized exchanges (e.g. Binance)
decentralized on-chain exchanges (e.g. Uniswap, Balancer)
decentralized L1 and rollup exchanges (e.g. dYdX v4, Hyperliquid and Loopring, Lyra respectively)
Aphotic falls into the category of rollup exchanges, with Aleo as its underlying L1. More specifically, Aphotic is a Validium rollup exchange with Aleo as its settlement layer. It will become one of the first app-specific rollups on Aleo.
The following table summarizes the key differences between Aphotic and other types of exchanges:
The major drawback of centralized exchange platforms is custody - you have to trust them with your funds. We all know why it is bad. A DEX only requires you to trust the immutable smart contracts. However, an on-chain DEX cannot boast low fees and fast transactions, which is essential for active trading. This is why we we see many new L2 DEX platforms appear, especially for perps.
But the key problem that remains is privacy. Neither centralized nor decentralized exchanges are capable fully protecting you from the front-running and keep your trades private. Even such major players like dYdX struggle to avoid harmful MEV extraction:
Many promise front-running protection, but there is no way to verify that your centralized exchange doesn’t front run you. Alternatively, you can trust that a DEX won’t front run you:
But should you?
Aphotic is set to take the best from L2 DEXes and bring true privacy and fairness to trading. Let’s dive deeper into which design decision make Aphotic a fully private and ultra fast DEX on Aleo.
Aphotic is built on Aleo with a goal to add a next level of privacy to the DeFi ecosystem of Aleo - trade execution privacy.
Unlike public blockchain, Aleo natively supports private transfers and smart contracts. This built-in privacy make it easy to achieve pre- and post-trade privacy: a user can deposit and withdraw funds without disclosing their address. However, to the best of our knowledge, existing decentralized exchanges on Aleo don’t offer trade privacy: all trades are public and thus are subject to MEV. This happens because to settle a trade they need sequential access to global state of the liquidity pools, which is only possible in the public finalize
block of Aleo program.
Aphotic’s main goal it to bring private execution to Aleo DeFi ecosystem by executing encrypted trade orders off-chain, in hardware-protected enclaves (trusted execution environments, TEE). A hardware enclave is a secure container that protects integrity of code and confidentiality of data it handles from the infrastructure operator. This is achieved by:
Remote attestation. An enclave cryptographically proves to a user or an Aleo program that they are communicating with a specific piece of software running in a secure container hosted by the trusted hardware.
Hardware isolation. Enclave’s code and data are isolated from the outside environment, including the operating system, hypervisor, and hardware devices.
Today TEEs are used in many DeFi applications to extend blockchains with confidential computing, e.g. MEV auctions and SUAVE.
In Aphotic, we use TEEs to execute limit order book and dark pool order crossing privately and without front-running. All orders arrive to TEEs over TLS encrypted channels, with private keys generated inside a hardware enclave and never leaving it, so that no one can front-run an order, even the operators of the infrastructure. This is guaranteed by hardware isolation. Moreover, anyone can verify that their trades are executed by audited, untempered code running in the enclave thanks to remote attestation, which guarantees the integrity of the off-chain part of Aphotic DEX. For example, an Aleo program can not only check that a withdrawal request is signed by the correct, enclave-protected key, but also verify the integrity of the withdrawal amount calculations.
As the name suggests, trusted execution environment require a certain level of confidence in its hardware implementation. Aphotic uses one of the most developed hardware trusted enclaves is Intel SGX. Security researchers have discovered several vulnerabilities in Intel SGX implementation and proposed mitigations for these attacks. Most of the vulnerabilities are side-channel attacks which require access to hardware and possibly tens of thousands of measurements to execute an attack, which is hard to execute in practical settings of physicaly secure data centers. However, because security and privacy are our top priorities, we plan to implement additional measures such as
Generating ZK proves of the critical parts of the enclave
Re-execution on a redundant hardware enclave by a different vendor (e.g. AMD SEV)
Our end-game vision is to transition to Collaborative SNARKs running in TEEs as an additional line of defense.
The number one priority of a DEX is always the security of users’ funds. Any DEX must avoid taking custody of assets and guarantee permissionless withdrawal.
Users do not custody crypto with Aphotic: the assets are custodied by the smart contract instead exactly the way L2 deposits (e.g. Optimism or Scroll) transactions work.
A withdrawal request is signed by the user and is approved by the Account module that runs in a TEE, which after all checks are completed co-signs a withdrawal request with a key that never leaves a hardware enclave. Co-signing acts as a 2FA (two-factor authorization) to hedge the risk of bugs and vulnerabilities in ZK proving/verification (similar to how Taiko and Scroll are incorporating TEEs in their multi-proving systems).
There are two pessimistic cases that need to be handled:
Extended failure of a TEE node.
Censorship of withdrawals by a TEE node.
These cases are again very similar to sequencer outages in L2s.
In case of extended outage of TEE node (e.g. 10 days), an escape hatch will be automatically activated for the users to pemisionlessly withdraw their funds. Aphotic allows users to withdraw directly from the smart contract by providing a Merkle proof to the contract showing an account's balance in the state root. If the proof is accepted, the user can evict their funds from the smart contract.
Aphotic follows a modular Validium approach and store transaction on a separate Data Availability (DA) layer. This guarantees that a user always has an access to the information required to construct a Merkle proof. In addition to a DA layer, Aphotic introduces two additional mechanics to guarantee data availability:
Store-it-yourself option. Aphotic can optionally streams to client their own Merkle proofs. Today many mobile apps and even browsers can store users’ data locally for a prolonged periods. Also power users (e.g. market makers) would be willing to store their own proof data for withdrawal.
Economic incentives for a longer term storage and withdrawal fraud proofs. Most DA solutions do not gurantee historic data storage:
Rollup developers should not rely on this as the only method to access historical data, as archival nodes serving requests for historical data for free is not guaranteed
Aphotic uses an withdrawal challenge game protocol to incentivize external entities to store historic data.
A user who wants to withdraw via the contract Merkle proves to the contract that their balance is was equal X
in the block k
posted to the DA layer. However, there might have been balance updates in the following blocks. Instead of making a user prove non-inclusion of his balance in blocks i>k
(e.g. using Sparse Merkle Trees), we allow a certain time for anyone to challenge this withdrawal with an economic incentive: if somebody submits a Merkley proof of that this user had balance Y
in the block t>k
, they are award a certain percentage of the original balance. This creates economic incentive to store and challenge malicious users trying to game the system. We currently work on formalizing such a mechanism and showing that it indeed can enhance security of emergency withdrawals.
Since all trades happen off-chain, there are no trade transaction fees in Aphotic. This significantly improves trading experience for Aleo users.
How many trades per second can Aphotic handle? Trades are executed in hardware enclaves, which have performance impact. The overheads of Intel SGX can result from two main aspects. The first is the actual overhead of executing CPU instructions and accessing the encrypted memory in an enclave. The second is the overhead associated with entering and exiting an enclave. However, even compared to the fastet ZK proving systems (let alone Collaborative SNARKs), SGX is blazing fast and can handle 1000+ trades per second with sharding by asset pairs.
This makes Aphotic a viable alternative to CEXes for active, instituational and high-frequency traders.
Strong privacy of Aphotic enables dark pool markets. A dark pool is an exchange mechanism containing anonymous, nondisplayed trading liquidity that is available for execution. Dark pools bring together buyers and sellers in a confidential manner and reduce or completely eliminate market impact. This makes them an important market for institutional investors who often trade large amounts of assets in traditional finance.
For crypto-native assets, dark pools can play even more important role due to unique features of most of the blockchain:
Again it’s important to note that MEV is possible even if the inputs (e.g. amounts) are encrypted but the settlement part happens in the public part of the smart contract. For example, most of the private AMMs on Aleo are subject to MEV because they settle a trade in the finalize section.
Note that using a privacy solution on a public data blockchain (e.g. a Tornado-cash mixer) will not help: the initial mixing transaction will be seen as an attempt to hide a large trade, leading to the same or even worse market impact.
A dark pool DEX can solve the above mentioned problems in crypto finance. However, it’s application is not limited to DeFi.
Dark pools are well-established, regulated venues in traditional finance. In the U.S., there are over 50 dark pools, with 19 of them accounting for up to 35% of consolidated volume. In Europe, there are the 16 dark pool markets, which report approximately 4.5% of volume, and in Canada they represent 2% of volume.
However, there are two major problems with existing, centralized dark pools (they affect both traditional and crypto-native trading):
Information asymmetry. While ordinary traders have limited or no information about the pool’s market depth and structure, a pool operator knows exactly what orders are in the pool. Using this information, an operator or their affiliates can engage in proprietary trading in the pool using unfair informational advantage to front-run pool subscribers’ trades
Trusted execution. Pool subscribers have to trust that their orders were executed correctly.
A trustless and decentralized dark pool exchange like Aphotic can not only solve some of the key issues in DeFi, but also have a competitive advantage over existing centralized solutions in traditional finance.
Our project will take KYC and all applicable regulations into account from day one.
We plan to work with compliance ZK oracles (e.g. Aleo ZPass) which in turn operate through traditional compliance service providers to KYC/KYB/OFAC-verified user accounts. Once verified, the user is given a ZK proof of compliance. This proof allows their wallet to trade in the dark pools. This verification would need to be re-done on a recurring basis.
While we plan to start with crypto native assets, we plan to build our dark pools in accordance with all the regulation usually imposed on stock/futures dark pools. We plan to take US regulations as a starting point. In the United States, the Securities and Exchange Commission (SEC) serves as the main regulatory body. It is responsible for supervising dark pools, ensuring adherence to regulations to safeguard investors and uphold market integrity. Furthermore, entities like the Financial Industry Regulatory Authority (FINRA), as self-regulatory organizations, actively monitor dark pool operations and enforce compliance with industry standards.
FINRA and SEC require dark pool trading post-settlement information to be published publicly with a certain delay. It may happen that public disclosure standards may be applied to crypto dark pools in the future, especially with regards to tokenized RWA. Therefore, an audit trace export should be available in a secure manner. Some of the reporting standards (e.g. Rules 605 and 606) deal in aggregate statistics, they do not provide detail and certainly do not reflect the split of light versus dark activity. However, additional reporting for internalized trades and other off-exchange trades must be reported through a trade reporting consolidated tape within 90 seconds of execution.
Aphotic is set to become the first truly private exchange that can be as trustless as L2 rollup and as performant and feature rich as a centralized exchange. We hope to make Aphotic and Aleo a prime destination for active traders who want to trade with integrity, security and privacy.