There exist VRF oracles on Solana, such as Switchboard, Orao network, MagicBlock VRF. But in many cases they might be too expensive, too complex to implement, not fast enough or require you to integrate deeper than you might want with their infra. In this article, I’m going to show an easy to implement, cheap, yet reasonably secure VRF that is going to take its randomness from drand.

Disclaimer: I consider the high level VRF construction described in this article secure enough to handle random outcomes in low- to mid-stakes situations (e.g. on-chain games). That being said, it definitely requires a more rigorous security analysis and external audit to be used when there is a significant value at stake (e.g. millions in DeFi protocol).

Our use case

Let’s consider a case of opening booster packs in on-chain games.

Opening booster packs is a randomized process where you get a set of collectible items (like cards) from a larger pool. Each pack contains a fixed number of items with varying rarity (e.g., common, rare). You don’t know what you’ll get until you open it, making the experience exciting.

Let’s say a booster pack contains 5 cards. The transaction should be as cheap as possible so as not to hurt playability and in-game economy.

A few things to note here:

1. Minting several NFTs at once on Solana is not easy due to metadata and transaction size limits. There are cNFT that make it less expensive.

2. Depending on how you create the cards, generating random cards (e.g. traits, art) may need to be done off-chain.

The metrics I care the most are:

1. Latency. The user should get the outcome quickly otherwise the player experience would deteriorate.

2. Transaction costs. The transaction should be as cheap as possible not to hurt playability and in-game economy.

3. Security. The randomness must be verifiable secure.

How VRFs work

VRF requires an off-chain entity to securely generate the random number using since on-chain environments are fully deterministic and cannot produce randomness independently.

Here is how a typical interaction with an off-chain VRF provider works:

1. User Contract (Onchain): Requests randomness from the VRF Coordinator.

2. VRF Coordinator (Onchain): Forwards the request to the blockchain and later verifies the randomness response using the public key.

3. Blockchain (Onchain): Records the randomness request and receives the response.

4. VRF Node (Offchain): Generates a random number and cryptographic proof.

5. Response Path: The VRF Node sends the response back through the blockchain, which is verified onchain by the VRF Coordinator and passed to the User Contract.

There are a few things worth noting:

1. The randomness is requested and the response consumed by User Contract in two different transactions - the VRF Coordinator calls your program back when it has the randomness

2. VRF Node should produce verifiable randomness. This verification is usually an on-chain signature verification. Also if a user or oracle can choose when to call for or provide the randomness, they can bias the outcome. We want to make sure that it is impossible or at least very hard to do.

Your own VRF

Our goal is to build our own VRF node that’s going to send randomness directly to our Solana program (User contract on the diagram).

When to build your own VRF

There are two good indicators you should consider having your own VRF:

1. The result of the VRF is a large transaction or even several transactions. Recall that you consume randomness in a callback transaction, and this transaction is subject to transaction CU or size limit on Solana. In our case, we want to mint 5 NFTs.

2. You need to have that randomness both on-chain and off-chain. On the diagram above, the randomness is only consumed by the User Contract. But what if you also want to process it on your backend? For example, you want to generate minted cards on the fly. One solution is to monitor your contract and fetch randomness from the chain, but this will introduce a delay in displaying the cards to a user.

Besides those, there are other reasons to consider your own app-specific VRF:

• Development speed. This might sound like an unconventional take, but your own app-specific VRF might be faster to build than to integrate an existing one:

  • No need to support callback CPIs from the VRF providers.

  • Fewer PDAs. No need to create and manage PDA accounts related to the external VRF.

  • Better and easier testing. You don’t need to mock VRF calls. Testing should be the most important of your Solana program development, so anything that improves it is great.

• Costs. There is a lot to optimize in terms of costs:

  • Consume on-chain the exact amount of randomness you dApp needs

  • Don’t pay VRF prodider’s fees, don’t need to create VRF-related PDAs

  • Don’t need to create a lot of Solana accounts related to VRF calls

• Reliability. You have fine-grained control over the quality of VRF, e.g. how fast is it delivered, what priority fees you’re ready to pay, etc. While commercial VRFs may spend a lot on building a reliable infrastructure, you are unlikely to get any guaranteed SLA (unless you are a big protocol) and be better off building a reliable delivery of randomness yourself.

• Security. It’s almost impossible to judge the quality and security of randomness produced by a third-party VRF. We are going to use drand, arguably the most reliable, secure and publicly verifiable source of randomness.

What is drand

drand (short for distributed randomness beacon) is a decentralized network that generates publicly verifiable, unbiased, and unpredictable random numbers at regular intervals. Their quicknet network generates new randomness roughly every 3 seconds. Each generated randomness has its round number. A round number is simply a counter that increases each ~3 seconds for quicknet.

Using drand HTTP API you can fetch latest randomness, wait for the next one or get randomness for a specific round, see

• /v2/beacons/:beaconID/rounds/latest

• /v2/beacons/:beaconID/rounds/next

• /v2/beacons/:beaconID/rounds/:round

In this article, I will use v1 api for illustrative purposes. For example, this call will give you the latest randomness from the quicknet

curl -L 'https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/latest' \
-H 'Accept: application/json'

At the time of writing this, it returned:

{
  "round": 17920353,
  "signature": "ad355be85a512c69702ef02ca6ce1b88dad19d5317d6c57eff372b54b7427b3c93b56e1d6e05ab65da57f0b81d94260c",
  "randomness": "a6d5517270bc2040a4c181e7a53146fe5fcbe0d2d2339cecd913ecb505396b83"
}

Viola! We have a piece of verified randomness. Anyone can either

1. Check that the round 17920353 indeed produced these 32 random bytes "a6d5517…” by querying HTTP API

2. Check the signature against the drand’s public key

Obviously, the second approach is much better because we want to consume this random data on-chain. Unfortunately, it’s pretty expensive to check BLS12-381 signatures that drand uses in a Solana program due to lack of cryptographic pre-compiles, see:

https://github.com/solana-labs/solana/issues/20241

One can prove such verification using zkSNARKs and verify the proof on-chain, but it still will be expensive to do for each transaction.

Is there anything we can? One can choose an optimistic approach: everyone can see the round numbers and the corresponding randomness consumed on-chain and if our VRF tries to cheat (i.e. use different randomness), then anyone would be able to prove it and claim bounty or halt our protocol. In other words, we allow anyone to monitor and check that our VRF is delivering correct drand randomness. To be more specific, anyone can prove that the correct randomness was different for the round. They send this proof to our Solana program that will verify it and halt if the verification succeeds.

How to use drand on-chain

While signature verification is important, it’s not everything. Another security issue is manipulation via timing. If our backend can choose when to send the randomness to our Solana program (e.g. delay until drand gives us a “lucky” number), it can bias the outcome. To avoid this, we want to fix the round whose randomness we will use before this round is generated. In other words, we commit to a random value that is yet to be known. How do we do this?

First, a user needs to execute a transaction that will request randomness. In our example, it is a transaction to mint a booster pack with 5 NFT cards.

In a Solana program, we can request an approximate time of the transaction using clock. The Clock is a Solana built-in sysvar (system variable) that provides time-related information to programs. This will give us the timestamp in seconds:

let current_time = self.clock.unix_timestamp as u64;

Next, we can turn this timestamp into a drand’s round

pub fn round_for_time(
     &self,
     current_time: u64, // i.e. self.clock.unix_timestamp
     genesis_time: u64, // for quicknet this is 1692803367
     period_seconds: u8, // for quicknet this is 3
) -> Result<u64> {
     if current_time <= genesis_time {
         return Err(CustomErrorCode::RoundBeforeGenesis.into());
     }
     // at genesis, the round == 1, so we add 1
     Ok((current_time - genesis_time) / period_seconds as u64 + 1)
}

What does it give us? It give us an approximate round number for the time when randomness was requested. Recall that Solana has roughly 400 ms slot time and drand’s quicknet has 3 second round delay. This gives a pretty good shot at getting a relevant round number. We have just fixed a round at the time when a user requested randomness. To be even more secure, we can add an offset to determine which round our VRF node should send on-chain, e.g. if round_for_time returned 17920353, then we expect randomness from the round 17920353 + 2, which means we need to wait for two more rounds after the request and then send this particular randomness to our Solana program. The larger the delay, the more secure is the randomness, but the longer our user has to wait to get the outcome.

Why do we need all this? Because we have binded us to deliver future randomness on-chain. Now we can’t cheat by waiting until drand gives us a favourable outcome: we have to deliver a specific round’s random data to our on-chain program. If we fail to do so, anyone could observe this and ZK prove that we are cheating.

Now similar to third-party VRF, our VRF needs to deliver the randomness to our on-chain program (don’t forget to take a fee from a user to offset the transaction costs!).

How does this happen? After the randomness is requested, out off-chain VRF (e.g. Node.js backend) indexes this request transaction, parses the round_number that our Solana program has committed us to and waits while this round is generated by drand. For example, if we have a round delay of 1, the wait should be around 3 seconds. As soon as the required round is generated, our backend executes a transaction to send the randomness to the Solana program.

In our Solana program, we verify that the round is a correct one, e.g. assuming we stored the round number as booster_pack.randomness_round our code might look like this:

impl<'info> MintBooster<'info> {
    pub fn handler(
        &mut self, 
        game_id: u64, 
        player: Pubkey, 
        booster_pack_seq_no: u64, 
        randomness: [u8; 32], 
        randomness_round: u64, 
        bumps: MintBoosterBumps
    ) -> Result<()> {
        const ROUND_DELAY: u64 = 3; // TODO move to configuration
        require!(randomness_round == self.booster_pack.randomness_round + ROUND_DELAY, CustomErrorCode::InvalidRandomnessRound);
        // consume randomness here...
    }

What do we have

What have we achieved so far? Quite a lot:

1. Delivered randomness from drand to our program

2. Prevented manipulation via timing

3. Prevented tampering with data by optimistic signature verification

As a result, we have cheap, secure and fast randomness.

ZK fraud proof for BLS signatures will be covered in the next post - we’ll use SP1 and their Solana verifier to make sure anyone can catch us if we try to cheat. Follow to make sure you don’t miss it x.com/0xlexx!

This article is an attempt to devise a practical approach to maximizing crypto-economic security of a Bitcoin rollup. It is very much a WIP.

Context

L1 blockchains rely on two sources of security: cryptographic and economic. Cryptographic security is the computational hardness of the algorithms securing a blockchain protocol. Economic security is the total value of assets deployed by consensus participants to secure a blockchain. Combined, they define the total so-called crypto-economic security of a blockchain.

The idea behind Layer 2 execution scaling solutions is to inherit crypto-economic security of the underlying L1. The execution of transactions in L2 happen off-chain and the state of L2 is committed to L1 allowing users to trustlessly enter and leave L2.

In contrast, side-chains have their own crypto-economic security, usually by having a committee of PoS validators or merged mining.

There are two main types of L2s: optimistic and ZK. Optimistic rollups rely on fraud proofs while ZK rollups rely on validity proof

Currently available Bitcoin Script opcodes (e.g. lack of pairing cryptography) do not allow to verify ZK validity proofs or fraud proofs on-chain. That's why, to the best of our knowledge, "Bitcoin zk-rollups" are not rollups, but sidechains. At best, they use Bitcoin as a data availability (DA) layer and follow its longest chain exactly like a side-chain does.

BitVM is the only potentially viable solution to the problem of on-chain verification in a Optimistic-ZK model, while it is work-in-progress with many engineering and scalability challenges to overcome (e.g. delay attacks or Bitcoin script single execution limitation when a malicious watcher wastes the script's execution while not disproving a lying operator).

As a result, the existing solutions have the following drawbacks:

• "Bitcoin zk-rollups" are limited in their ability to inherit Bitcoin crypto-economic security

• Bitcoin as a DA is expensive and constraints L2's throughput

To enable authentic Bitcoin rollups, new features have to be introduced to Bitcoin core, which will understandably be met with caution and require time to be implemented.

Our approach

We propose a more practical approach that will gradually build on existing crypto-economic infrastructure of Ethereum with an aim to gradually incorporate as much of Bitcoin security as possible, so that it will be accepted by even the most hardcore Bitcoin maxis.

While measuring economic security is a highly controversial subject, it's hard to deny that Ethereum has amassed substantial economic security. Ballpark estimates show that Ethereum has probably overtaken Bitcoin in this regard. As of March 2024, Ethereum has around 31M ETH staked, which at $4000 per ETH amounts to $124B of economic security. In contrast, Bitcoin at 600M TH of hashrate with $17.5 per TH gives $10.5B of economic security to the network.

Our goal is to build a modular Bitcoin validium, zkEVM rollup which leverages Bitcoin for state tracking, EigenLayer to tap into Ethereum economic security and specialized DA layer for proofs to increase throughput.

The working title of the rollup is LayerB.

Security Model

Our security model relies on combining two security drivers:

• Ethereum re-staking security for state transitions

• Bitcoin native security for unilateral exit

Both mechanisms rely on ZK fraud proofs and economic incentives.

As a validium rollup, LayerB enforces execution integrity via ZK proofs, but doesn’t store transaction data on Bitcoin. Only the hash commitments of proofs will be stored on Bitcoin, while the proofs and witness data will be saved to a specialized DA layer. This allows for a much higher performance and lower costs while still synchronizing the state of the rollup with the Bitcoin's longest chain and properly handling reorgs. It also minimizes additional security assumptions that might be caused by using a DA layer rather than publishing data on Bitcoin.

LayerB will become an Actively Validated Service (AVS) of EigenLayer protocol. AVS operators verify proofs off-chain and certify their correctness on-chain, contributing to the pooled security of LayerB.

In case anyone detects an incorrect state transition, they submit a ZK fraud-proof to our EigenLayer slashing contract. This contract uses an on-chain DA layer light client and a Bitcoin ZK light client. These light clients allow receiving the state of external networks (DA layer and Bitcoin) in Ethereum without relying on third-party validators. The slashing contract validates:

• fraud proof

• incorrect state proof hash inclusion in Bitcoin via a light-client

• incorrect state proof inclusion in DA via a light-client

If the fraud proof is confirmed by the smart contract, the malicious validators are slashed. In other words, LayerB relies on optimistic ZK validity verification: the verifier contract optimistically accepts AVS operators' claim that a submitted proof is valid. Any observer can check the proof off-chain and submit a proof to prove its incorrectness. The verifier then checks this fraud proof and, if it is correct, rejects the original proof and slashes the operator. This kind of proof is sometimes referred to as naysayer proofs.

A rollup must provide an ability to perform a unilateral enter (deposit) and exit (withdraw). While the implementation of deposits is straightforward (via SPV proofs), a proper unilateral exit requires proving its validity directly on Bitcoin. This requires an approach similar to the interactive fraud proof scheme proposed by BitVM. We work on a practical resolution algorithm when a single honest challenge can win disputes in the presence of dishonest competitors while spending effort linear of the cost of the computation related to the proof size.

It's important to note while Bitcoin Script and BitVM is needed to verify the correctness of exits from a rollup for BTC as a native asset, it is not required for Bitcoin meta-protocols such as BRC20 and Inscriptions. A deposit of such assets to a rollup can burn them (i.e. render them unspendable on the Bitcoin mainnet) and withdrawal can incorporate validity proofs that indexers can independently validate and consider as an authentic asset returned to the L1.

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.

The spectrum of exchanges

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.

Privacy and Front-running Protection

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.

Self-Custody of Assets and Data Availability

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.

Low Fees and Fast Transactions

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.

Dark Pools

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:

• Maximal Extractable Value (MEV). Any attempt to sell a large amount of tokens on a DEX will likely be affected by MEV (e.g. front-runned) because all transactions are public. With the rise of RWA, the amount MEV will increase even further because there will be more profit opportunities for searchers and arbitrageurs.

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.

• Public transactions. In most liquid blockchains, all transactions are public and all accounts of major crypto-asset holders are constantly monitored. An attempt to deposit a large amount of tokens to a centralized exchange will most probably immediately impact the token’s price.

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.

• Low cap project tokens. Many projects are funded through token sales, and their cap can be relatively low. A legitimate sale of even a moderate amount of tokens by the project’s investors or team can significantly impact the price. This means that the market impact problem does not only affect large institutional trades when it comes to crypto assets.

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.

Compliance

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.

Conclusion

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.