*Forward the Original Title：Eureka Partners Research Report: Singularity - Privacy Transactions on a Transparent Blockchain

Introduction

In 1969, the method of trading in financial markets was still based on traditional trading floors. At that time, computer technology was not yet mature, and traders relied on shouting orders aloud, a method that was inefficient and lacked privacy, making it difficult for institutional investors to conduct large transactions without causing market fluctuations. Instinet, founded by Jerome Pustilnik, emerged in response to this challenge. Instinet allowed investors to place orders anonymously through an electronic trading platform, which was responsible for matching buyers and sellers’ orders and executing the trades. This model not only improved trading efficiency but also ensured the confidentiality of transactions, effectively preventing market impact and information leakage.

Today, technological advancements have led to the birth of blockchain technology, a revolutionary innovation that has brought unprecedented transparency and security to financial transactions. However, the public nature and immutability of blockchain, while bringing many benefits to the market, also present new challenges for large transaction traders. In the public ledger of the blockchain, every transaction is visible to all participants, making it difficult for large transaction traders to remain anonymous. Traditional exchange platforms cannot fully protect traders’ privacy, and the public disclosure of large orders may lead to price fluctuations, affecting trading efficiency and costs. Additionally, regulatory uncertainty and market opacity also pose additional risks to investors.

This report will explore dark pools on the blockchain as an innovative solution that introduces advanced privacy protection technologies and automated trading mechanisms to provide a more secure and efficient environment for large cryptocurrency transactions. It will also discuss how Singularity, through its innovative solutions utilizing technologies such as FHE (Fully Homomorphic Encryption) and ZKP (Zero-Knowledge Proof), offers large investors a private and compliant decentralized trading platform.

What is Dark Pools？

Dark Pools in the traditional financial markets refer to private trading platforms that do not publicly disclose trade information, allowing investors to conduct large transactions without exposing their trading intentions. The emergence of dark pool trading in the United States is closely related to the growing demand for large-scale equity transfers due to the increasing frequency of mergers and acquisitions in the securities market. With the development of financial markets, the importance of dark pools in various fields such as stocks, bonds, and foreign exchange has become increasingly prominent, especially in the era where high-frequency and algorithmic trading dominate. Statistics show that dark pool transactions account for 30% to 50% of the stock market, becoming an important component of market liquidity.

In the cryptocurrency market, as the group of large investors grows, the demand for large-volume transactions continues to rise. These large orders have a significant impact on the market, sometimes even triggering market turmoil. To avoid such risks, many traders turn to the OTC market or even Telegram groups for transactions. According to data from the Kraken exchange in 2020, the global OTC trading volume has surged 20 times since 2018, with a daily average transaction volume of approximately 300 billion USD, accounting for nearly 70% of the total cryptocurrency market trading volume. However, the OTC market also faces issues of insufficient liquidity and lack of regulation. To address these challenges, dark pools have been introduced as a solution, aimed at providing a more stable and private trading environment.

Key points about dark pools include:

• Privacy and confidentiality: Dark pools allow traders to transact anonymously, protecting their identity and order size from the public market until the transaction is executed.

• Reduced market impact: Dark pools enable large institutional investors to execute large orders without causing significant price fluctuations in the public market, minimizing market impact and slippage.

• Non-disclosure of trading strategies: Dark pool transactions help protect traders’ strategies from being known to the public market, preventing them from being exploited by MEV (Miner Extractable Value), copy trading arbitrage, and statistical arbitrage.

• Liquidity and price improvement: Dark pools provide additional liquidity to the market by matching buyers and sellers who may not find counterparts in traditional exchanges, potentially offering price improvements, especially for large-volume trades.

• Regulatory oversight: Dark pools are regulated, with regulatory bodies monitoring dark pool activities to prevent unfair access, insider trading, or market manipulation. However, for many dark pools, the centralized management style still poses risks of security, trustworthiness, and potential misuse of private data. Historically, there have been several cases where centralized dark pools were penalized for violating trust principles.

Core Privacy Technologies

Dark pools are a branch of the privacy track. Through the following Privacy Enhancing Technologies (PETs), such as Zero-Knowledge Proofs (ZKP), Multi-Party Computation (MPC), and Fully Homomorphic Encryption (FHE), dark pools inject privacy into their infrastructure.

Zero-Knowledge Proof (ZKP)

Zero-Knowledge Proof (ZKP) technology allows a prover to prove the correctness of a statement to a verifier without revealing any substantive information. This technology is particularly crucial in Ethereum Layer 2 scaling solutions, such as ZK Rollup, which achieves transaction validity verification by compressing transaction data into compact ZK proofs and submitting them to the mainnet. These proofs not only occupy minimal storage space but also protect the privacy of transaction information, embodying the natural advantages of a trustless mechanism. The application of ZKP technology is not limited to scaling but also includes privacy computing, with its main implementations being zkSNARKs, zkSTARKs, and Bulletproofs. These technologies collectively promote the enhancement of cryptocurrency privacy protection and transaction efficiency.

Introduction to zero-knowledge proofs

Multi-Party Computation (MPC)

Multi-Party Computation (MPC) is a technology that allows multiple parties to compute a function together without revealing their individual inputs. In the privacy domain, MPC provides a method to protect sensitive data, enabling parties to perform data analysis, computation tasks, or reach decisions without exposing personal data. The core advantage of MPC lies in its privacy protection capability. Through distributed computing and encryption technologies, participants can ensure their data remains private throughout the computation process.

Introduction to secure multi-party computation

▪ Fully Homomorphic Encryption (FHE)

Fully Homomorphic Encryption (FHE) is a cryptographic technology that allows direct computation on encrypted data without needing to decrypt it first. This means that operations such as addition, subtraction, and multiplication can be performed on data while it remains encrypted, and the computation results, once decrypted, are consistent with those obtained by performing the same operations on the original data. The core value of FHE lies in providing a powerful tool for privacy protection, allowing data to remain confidential during processing, thereby significantly enhancing data security.

Balancing Anti-Censorship with Compliance

Decentralized exchanges (DEXs) operating on public blockchains, such as Uniswap and Curve, are susceptible to Maximum Extractable Value (MEV) due to the public and transparent nature of their ledgers. This transparency means order details are visible to everyone, enabling searchers and builders to optimize their profits by rearranging transaction orders, which can detrimentally affect other users to some extent.

Dark pools, as a form of financial trading venue, have their core advantages in providing privacy protection and anti-censorship. In dark pools, order details are generally kept secret from third parties since each order generates Zero-Knowledge Proofs (ZKPs), reducing the public disclosure of transaction information. This architecture is particularly appealing to large holders and institutional investors, as it protects their trading strategies from being exploited by competitors or market manipulators. Additionally, the characteristics of dark pools also help to resist MEV, as the order and details of transactions are not public, reducing the possibility of rearrangement.

However, these advantages may diminish when transactions need to call public contracts or use shared sequencers, as these operations could expose transaction information, providing opportunities for MEV capture. Nevertheless, for large holders and institutional investors seeking privacy and anti-censorship protection, especially when their trading activities require high confidentiality, dark pools remain an attractive option.

The emergence of privacy protection tools like Tornado Cash offers the possibility of conducting anonymous financial activities on-chain, but these tools have also been used by criminals for illegal activities such as money laundering. The smart contract address of Tornado Cash was listed by the Office of Foreign Assets Control (OFAC) due to non-compliance. OFAC maintains a list of Specially Designated Nationals (SDN) to sanction non-compliant individuals and entities. Protocols not conforming to OFAC regulations have a high likelihood of their transactions being excluded from on-chain blocks. As of February 23, 2024, 45% of blocks require OFAC list review. This anti-censorship issue affects not only block producers but also validators and relayers, who may selectively ignore certain transactions or blocks.

Proportion of blocks reviewed by OFAC lists

With Tornado Cash being banned for non-compliance, a market vacuum for compliant privacy solutions has emerged. To fill this vacuum, subsequent dark pool projects need to provide privacy protection while avoiding similar regulatory risks. One effective method is integrating verified KYB/KYC processes into the project, ensuring the legality of user activities and helping to avoid potential regulatory risks. Legal regulations often lag behind technological advancements, making privacy projects easily exploitable for illegal activities. Actively embracing and complying with regulations is crucial to ensure the project’s security and legality.

Competition Landscape & Project Analysis

Between 2010 and 2022, the number of dark pool projects was limited, and these projects did not gain widespread recognition among the general public. However, with the advancement of privacy-enhancing technologies such as Zero-Knowledge Proofs (ZKP) and Multi-Party Computation (MPC), the dark pool domain welcomed a series of innovative technological solutions. The development of these technologies brought dark pools back into the public eye in 2023. Nevertheless, due to the complexity of the technology, the number of projects in the dark pool race is still relatively small. Here are a few projects that have become relatively mature.

1. Renegade, established in 2022, is a decentralized dark pool based on the MPC-ZKP architecture, designed to provide large transaction services for institutional investors. Renegade performs order matching through a peer-to-peer network and Multi-Party Computation (MPC) technology and uses ZK-SNARKs to ensure transaction details remain anonymous to outsiders during the order matching verification process. Additionally, it employs a midpoint execution mechanism to guarantee all transactions are directly settled at the real-time aggregated midpoint price of centralized exchanges to avoid slippage. Its default anonymous cross-trade feature, combined with interest indicators, promotes comprehensive price discovery and optimizes liquidity.

2. Penumbra is a decentralized trading platform built within the Cosmos ecosystem, offering a dark pool-like trading environment that allows users to trade while maintaining privacy. Through a private delegation mechanism, Penumbra combines privacy protection and the Proof-of-Stake (PoS) consensus mechanism, offering staking derivatives, tax-efficient staking, and on-chain governance with private voting. Penumbra connects to the Cosmos ecosystem via Inter-Blockchain Communication (IBC), serving as an ecosystem-wide dark pool that allows private transactions in any IBC-compatible asset. Users can also use ZSwap, a private decentralized exchange that supports sealed bid batch auctions and concentrated liquidity similar to Uniswap-V3, to exchange these assets.

3. Panther is a cross-chain DeFi platform that incorporates zero-knowledge technology, aimed at providing a solution that is both regulatory compliant and protects user privacy. Users can deposit digital assets into Panther’s Multi-Asset Shielded Pools (MASPs) and receive zAssets on a 1:1 basis. Through the Zswap module, Panther connects to other DeFi protocols, aggregating quotes for user selection. During transactions, Zswap creates an encrypted escrow contract, allowing users to exchange assets without disclosing transaction details. This design enables assets to coexist in diverse pools, maintaining data heterogeneity, making it difficult to track and de-anonymize users. Panther’s shielded pools leverage ZK SNARK and ZKP technology to ensure transaction privacy and compliance.

4. Railgun is a privacy system with a ZKP-MPC architecture designed for Ethereum, BSC, Polygon, and Arbitrum, utilizing zero-knowledge (ZK) encryption technology and leveraging MPC technology for the trusted setup ceremony. It allows users to execute smart contracts and DeFi operations securely while maintaining transaction privacy. When users issue transaction orders through Railgun, an Adapt Module smart contract automatically processes the private balance’s privacy unshielding, validates the order, and then relays find the best exchange rate in aggregated DEX liquidity, finally re-shielding the transaction assets to ensure the anonymity of user activity and addresses. This process is not only applicable to asset exchanges but can also be extended to other DeFi transaction types.

Technical Interpretation of Singularity:

How to Implement Private Transactions

Understanding the Concept of Private Transactions

To grasp the concept of private transactions, it’s essential to consider both the parties involved in the transaction and the specifics of the transaction, differentiating between two types of privacy: anonymity and concealment.

A standard transaction includes the following elements:

• Transaction Parties: This includes the sender (Trader A) and the recipient (Trader B) of the transaction.

• Transaction Details: This encompasses the amount of the transaction, the number of sub-transactions, the hash of the transaction, and other specific details.

Private transactions can be categorized into two types based on the level of information visibility to third parties:

• Anonymous Transactions: In anonymous transactions, the addresses of the sender and recipient are unknown to third parties. This means that during the transaction process, except for the two parties involved in the transaction, no one else can identify the specific participants. For example, Tornado Cash is a privacy protocol that achieves anonymity by obfuscating the transaction paths.

• Concealed Transactions: In concealed transactions, while the addresses of the sender and recipient are visible, the specific details of the transaction are not known. This means that the amount of the transaction, the number of sub-transactions, the hash of the transaction, and other detailed information are hidden from third parties. This type of privacy can be achieved using technologies such as Zero-Knowledge Proofs (ZKP). For example, Zcash is a privacy cryptocurrency that uses zk-SNARKs technology to conceal transaction details.

Singularity Overall Architecture Interpretation

Singularity Architecture Overview

Looking at the overall structure, it can be divided into roughly 5 modules:

1. Singularity

This is the smart contract with which users primarily interact, used for expressing and executing ZK circuit logic. These smart contracts’ functionalities include hiding the balance and transaction records of ETH/ERC20 tokens to achieve anonymity and concealment of transaction contents. It serves as a liquidity pool that aggregates all assets from all types of traders. Its name stems from its unique feature, that is, to all observers, all protocol transactions appear to originate from this smart contract. This design provides users with multidimensional privacy.

In the Singularity protocol, ZK Notes form the basic unit of transactions, containing critical transaction information, including the type of asset, amount, and an encrypted identifier related to the owner. The design of these Notes aims to provide a high level of privacy protection, ensuring the traders’ identities and asset information are effectively safeguarded.

Each Note includes the following key information:

• Asset Type: Indicates the type of asset involved in the transaction, such as the token type of a cryptocurrency or other digital assets.

• Amount: Indicates the quantity of assets contained within the Note, used to determine the transaction’s value.

• Rho: A randomly generated field value used to enhance the privacy of transactions, preventing external observers from tracking and analyzing the transaction.

• Schnorr Public Key: Used for cryptographic signing and verifying the identity of transactions, ensuring that only authorized users can perform valid transaction operations.

In addition to the above information, each Note also generates a corresponding Nullifier. The generation of Nullifiers employs cryptographic hashing techniques, taking the Note’s random value and public key as inputs and processing them to produce the corresponding Nullifier. This design aims to provide additional security for transactions, ensuring that only legitimate authorized users can effectively operate and consume the Note.

Note Addition and Storage

In the Singularity protocol, all Notes are attached to an append-only Merkle tree, and the root of the new Merkle tree is permanently stored. The purpose of this design is to ensure the integrity and security of transactions, preventing data from being tampered with and corrupted.

To illustrate with a simple example:

Suppose Alice is a user of the Singularity protocol. At some point, she conducts a transaction, depositing 1 ETH into the Singularity contract. This transaction will be recorded as a Note and attached to the current Merkle tree. At this moment, the root of the Merkle tree is calculated from this single Note.

Subsequently, Bob also conducts a transaction, depositing 0.5 ETH into the Singularity contract. This transaction will also be recorded as a Note and appended to the current Merkle tree. The root of the Merkle tree is updated as new Notes are added.

Note: In the case where an odd number of Notes are generated for the Merkel tree root, the two individual Notes will be duplicated and their hashes calculated.

As more users conduct transactions, each new Note is added to the Merkel tree in chronological order. Thus, the transaction history of each user is preserved within the same data structure, and the integrity of the entire transaction history can be efficiently verified by calculating the root hash of the Merkel tree. Since the Merkel tree is append-only, it is impossible to modify or delete any Note that has been added to the tree, thereby ensuring the security and immutability of the transaction data.

Transaction Verification of Notes

When traders conduct transactions, they must disclose the corresponding Nullifier and provide related evidence in the zero-knowledge proof to verify that the Nullifier is associated with the corresponding Note and prove the existence of the Note in the Merkel tree. Smart contracts will verify the uniqueness of the Nullifier and the validity of the evidence to ensure the legality and security of the transaction.

For example:

Suppose Alice has a Note containing 1 ETH that she deposited into the Singularity contract, and the Nullifier of that Note is “AAA123”. Now, Alice wants to use these funds for a transaction, so she must provide “AAA123” as the Nullifier and prove the following two points through a zero-knowledge proof:

1. Prove that “AAA123” is associated with the spent Note, i.e., the funds for this transaction indeed come from that Note.

2. Prove the existence of the Note in the Merkel tree, i.e., the Note was previously deposited into the Singularity contract and has not been tampered with.

The smart contract will verify the Nullifier and evidence provided by Alice to ensure the uniqueness of the Nullifier and the validity of the evidence. Only when the verification is passed will the contract execute the transaction and transfer the funds to the recipient desired by Alice. Thus, the smart contract ensures the legality and security of the transaction, preventing any malicious or fraudulent activities.

Below is the pseudocode implementation of the above logic:

// Pseudocode
pragma solidity ^0.8.0;
contract SingularityContract {
   mapping(address => mapping(bytes32 => bool)) private invalidValues;
   mapping(bytes32 => bool) private merkleTree;
   // Deposit operation, depositing funds into the Singularity contract
   function deposit(bytes32 noteHash, bytes32 invalidValue) public payable {
       require(msg.value > 0, "Deposit amount must be greater than 0");
       // Add the Note to the Merkel tree
       merkleTree[noteHash] = true
       // Store the nullifier
       invalidValues[msg.sender][noteHash] = true;
   }
   // Transaction spending operation, verifying nullifier and evidence, executing the transaction
   function spend(bytes32 noteHash, bytes32 invalidValue, bytes memory proof) public {
       // Verify that the provided nullifier matches the stored one
       require(invalidValues[msg.sender][noteHash], "Invalid value does not match");
       // Verify the existence of the Note in the Merkel tree
       require(merkleTree[noteHash], "Note does not exist in the Merkle tree");
       // Verify the zero-knowledge proof
       require(_verifyProof(noteHash, invalidValue, proof), "Proof verification failed");
       // Execute the transaction, transferring funds to the recipient
       // The specific transfer operation is omitted here
   }
   // Zero-knowledge proof verification function
   function _verifyProof(bytes32 noteHash, bytes32 invalidValue, bytes memory proof) private view returns (bool) {
       // In practice, specific zero-knowledge proof verification is required
       // The specific verification process is omitted here
       // If the proof is successfully verified, return true, otherwise return false
       return true;
   }
}

1. Book

Book employs Fully Homomorphic Encryption (FHE) technology to build a completely private offline order book, providing traders with a secure and reliable trading environment. Within the Book system, a special group of FHE nodes, known as Bookies, play a critical role, collectively managing the order book. The matching process includes:

API nodes encrypt orders to ensure the confidentiality of the order content. Then, Bookies use the FHE protocol to perform order matching calculations, safeguarding the secrecy of order information. The results of the order matching are published, but the original order content remains confidential to protect traders’ privacy rights. Matched traders can directly communicate and settle using the Swap feature of the Singularity contract, while traders who fail to settle will face reputation penalties.

To ensure the stable operation of the Book system, a majority rule incentive mechanism is adopted, and Bookies are required to stake tokens:

• Bookies use a majority rule mechanism to address potential disagreements in encrypted order matching, preventing malicious activities.

• Staking tokens aims to guard against Sybil attacks while motivating Bookies to fulfill their duties and ensure the system’s smooth operation.

In the Book system, identity and reputation management are key, with innovations including:

• Each anonymous identity corresponds to a reputation reflecting its historical settlement probability, while maintaining identity privacy.

• Traders can set reputation thresholds to filter order matching counterparts, ensuring transaction security and reliability.

• Traders failing to settle will receive reputation penalties, also affecting the reputation of their trading counterparts.

For example, suppose Alice wants to buy 1 ETH,

• Order submission: Alice submits an order to buy 1 ETH at a specified price of $2000 USDT.

• Order matching: The Book system finds a seller, Bob, willing to sell 1 ETH at $2000 USDT.

• Transaction confirmation: Alice and Bob confirm their orders have been successfully matched.

• Transaction settlement: Alice pays Bob $2000 USDT and receives 1 ETH. The Singularity system updates their account balances.

• Reputation management: If Bob fails to complete the transaction on time or exhibits other negative behaviors, his reputation may be reduced, leading the system to restrict his matching with other traders. If Bob’s reputation rating is 5, it indicates he is a reliable trader. However, if he fails to complete the transaction on time or engages in other negative behaviors, such as canceling orders multiple times or manipulating the market maliciously, his reputation could be impacted. This could lead to a 1-point decrease in his reputation rating to 4, further limiting his future trading participation threshold.

1. Automation

Automation is a protocol-embedded AMM-DEX, with Book acting as an alternate liquidity provider. Since traders can submit transactions through Singularity to deposit funds, and Singularity is anonymous, deposits into Automation are also anonymous. This means the identities of traders are not exposed, protecting their privacy.

Traders can withdraw funds from Automation at any time and transfer them to the Singularity contract. This flexibility allows traders to freely manage their funds and withdraw them whenever needed. Similarly, since the Singularity contract itself is anonymous, the withdrawal process also maintains the traders’ anonymity.

For orders that cannot be matched with any orders in Book, Automation will provide matching to help increase liquidity. This ensures that even if orders are not immediately matched, traders’ orders can still be processed, and their trades can continue. By providing additional liquidity, Automation improves the overall efficiency and trading experience of the protocol.

1. Relayer

In Singularity, the Relayer plays a crucial role, responsible for submitting meta-transactions on behalf of users and paying the Gas Fee for user transactions. This design is motivated by the desire to protect user anonymity. Since Gas Fees must be paid to the typically public base-layer blockchain, if users were to pay their own Gas Fees, their identities could potentially be exposed.

Relayers carry out this task by submitting meta-transactions. Meta-transactions are natively verifiable and computable, preventing Relayers from tampering with or altering the content of the transactions, thus ensuring the security and integrity of the transactions. Moreover, to prevent malicious behavior by Relayers, the system is designed with a trustless Relayer network. This means that anyone can run a Relayer without needing to provide any form of collateral.

The transactions submitted by users and their associated fees are public and will be paid to Relayers to compensate them for the Gas Fees they cover. This design makes the Relayer network a rational system, where they will accept and submit any profitable transactions. Even if there are malicious Relayers, ensuring the presence of at least one honest Relayer guarantees the system’s completeness. Of course, traders have the option to run their own Relayer and replace the Gas Fee, albeit at the expense of some privacy.

1. API

API serves as the interface node for users to interact with the protocol. Through the API, users can generate and submit proofs to the Singularity contract, manage orders on the Book, listen to the Book to find matches, and negotiate settlements on the Singularity contract. Additionally, the API allows users to interact with Relayers.

Privacy Transactions

Based on the aforementioned structure, the privacy transactions mentioned earlier can be implemented:

• Anonymous Transactions (Automation)

When conducting transactions with Automation, since traders need to make a deposit operation, the amount of money pledged each time will be exposed, just as each deposit to Singularity cannot avoid being overheard by third parties listening in on the transaction details. Therefore, conducting transactions through Automation will sacrifice the concealment of the transaction.

It should be noted that when the Book cannot match a trader, although their order can be included in the Automation trading pool for matching (which seems to expose the trader’s address), the anonymity of the trader is still ensured, because the entity transferring their liquidity is Singularity.

• Anonymous + Concealed Transactions (Settlement through Singularity)

When settling transactions through Singularity, regardless of how the transaction price discovery and intent matching are conducted, the final settlement of the transaction can still ensure its anonymity and concealment. This is because the Singularity contract is responsible for custodial settlement of funds and the final transfer of funds, thereby achieving visibility in the open while operating in the dark.

Dark Pool Trading: The Implementation of Singularity

Singularity’s Trading Process

A dark pool, aimed at large institutions and professional traders, provides a platform for trading without affecting market prices. It primarily accommodates two types of trading needs: Transfer and Swap. In the following, we will detail how Singularity implements these two types of transactions based on the content depicted in the diagram above. It’s important to note that API Nodes and Trading Nodes are part of the same node in the diagram; for clarity, they are described as two different types of nodes here.

1. Transfer Transactions

Transfer transactions primarily occur between two Trader nodes. We define the receiving Trader node as Trader A and the sending Trader node as Trader B. The specific process for a transaction between Trader A and Trader B is as follows:

1) When conducting a transaction, Trader B must deposit funds into the Singularity contract. Trader B encrypts this deposit transaction by calling an API, thus generating a ZK Proof, also referred to as a ZK Note, and provides it to the Singularity contract to verify that Trader B has deposited the funds.

2) After depositing the funds, Trader B initiates a Transfer transaction by calling an API to send a ZK Note to the Singularity contract.

3) Upon receiving Trader B’s Note, the Singularity contract identifies the corresponding Trader A based on the information provided in the Note. At this point, Trader A can extract the amount of the Transfer transaction from the Singularity contract.

In this process, we observe that the interaction between nodes and the contract is conducted through ZK Notes. The notes utilize a UTXO model for transfer, which inherently possesses a degree of privacy and anonymity compared to the account model. This method ensures that the specifics of a transaction are known only to its initiator, while externally, it appears as though some address interacted with the Singularity contract. However, basic transaction details, such as the recipient’s address or the transaction amount, cannot be captured.

1. Swap Transactions

Compared to Transfer transactions, Swap transactions are somewhat more complex due to the need to find a trading counterpart. Here, we define the Trader node wanting to engage in a Swap transaction as Trader C and the eventually found trading partner’s Trader node as Trader D. The specific transaction process between Trader C and Trader D is as follows:

1) Similar to the first step of the Transfer transaction, Trader C needs to deposit funds into the Singularity contract, and simultaneously, Trader C will initiate an Order transaction to the Book node by calling an API.

2) Acting as an off-chain order book node, the Book node attempts to match different Order transactions under a Fully Homomorphic Encryption (FHE) environment without knowing the specific details of the Order transactions.

a. Upon successful matching, the Book node will notify the corresponding two Trader nodes to proceed with the transaction.

b. If matching fails, the Book will deposit the funds related to this transaction into the on-chain Automation as reserved liquidity. This is akin to depositing spare money into a savings service like Yu’e Bao. If there are still transactions that fail to match later, they will prioritize trading from the Automation. Only when the funds in Automation are insufficient to complete the transaction will it interact with external DEXs like Uniswap through the Singularity contract.

After finding the trading counterpart and negotiating the Swap details, the traders will sign the Swap transaction details mutually. Then, either party can use these signatures to construct a zero-knowledge proof, allowing the transaction to change the ownership of Notes without both parties being online. It’s important to note that to protect the privacy of the transaction, Swap transactions are still conducted through the Singularity contract.

Hence, we can see that Singularity primarily utilizes ZK (Zero Knowledge) and FHE technologies in the transaction process to achieve privacy and anonymity. The use of ZK technology ensures that the specifics of any transaction are only known to the initiator, yet allows other traders or the Singularity contract to quickly verify it; FHE technology enables the Book node to compute mutually matching transactions during the matching process without needing to know the specific details of the transactions, and also keeps the original transaction information confidential when notifying both parties, meaning the parties only know who they are trading with but not the specific asset type and amount of the trade.

Summary and Evaluation

The OTC market accounts for nearly 70% of the entire cryptocurrency market’s trading volume, highlighting the significant demand for privacy transactions in the Web3 industry. However, the privacy trading sector still faces various challenges, such as meeting regulatory requirements of government bodies, conducting transactions without revealing specific information about users and transactions, and preventing malicious actions by the trading parties. Decentralized dark pools like Singularity represent an innovative solution that can provide users with higher levels of privacy protection and censorship resistance through the use of privacy technologies and smart contracts, reducing reliance on centralized entities. These platforms support large transactions anonymously and can integrate with compliance services to create a trading environment that is both decentralized and regulatory compliant.

Key Considerations for Dark Pool Sector:

1. Technical Architecture : Zero-Knowledge Proofs (ZKP) and Multi-Party Computation (MPC) are foundational to the dark pool sector, enabling transaction validity verification without revealing transaction details. Many current protocols rely heavily or entirely on MPC, which has two main drawbacks: low computational efficiency and protocol complexity. MPC protocols require proving and verifying ZKPs within an MPC framework, which is computationally intensive. Additionally, MPC often needs stable network connections, challenging to achieve in a global decentralized network. These factors make protocols based entirely on MPC impractical for large-scale applications, such as order matching engines.

2. Anonymity and Privacy Protection : Regulation is an unavoidable topic in the privacy sector. Ensuring transactions and funds are completely anonymous while providing sufficient privacy protection is a challenging task. It’s particularly important for users wishing to trade with compliant capital. Dark pool projects urgently need to integrate KYB/KYC processes, embrace regulation proactively, and ensure users’ KYC/KYB data is not leaked to maintain platform legality and user trust.

3. Liquidity & Fund Security : Liquidity is a critical factor in dark pool operations. Ensuring sufficient trading volume and fund security is vital for efficient order matching and enhancing traders’ anonymity and willingness to participate. In dark pools, the anonymity of funds increases with the pool’s size, making tracking specific depositors more challenging. In scenarios of scarce liquidity, many protocols’ order book models have limitations in matching trades among users, as they may not always provide sufficient liquidity for all orders. Besides order books, innovative AMM trading mechanisms and integrating more DeFi applications from various blockchain ecosystems could be effective ways to expand liquidity.

4. Scalability : Ensuring good scalability to accommodate growing numbers of users and transaction volumes is essential for dark pools. Dark pools risk losses if they face a surge in LPs without matching orders. Therefore, dark pools should consider their settlement layers, technical design, and ecosystem roadmap during the design phase to meet higher transaction demands, especially under progressively comprehensive regulatory frameworks.

Dark pool trading, with a certain history in traditional industries and yet to be disproven as a solution, continues to have significant market demand and development potential. Traditional dark pool trading faces trust risks with centralized traders, whereas decentralized projects like Singularity innovatively adopt a “dark pool + transparent pool for dark trades” model, addressing the pain points of reliance on centralization, insufficient privacy, and poor censorship resistance.

Unlike previous privacy trading projects, Singularity offers asset privacy trading functionality along with DeFi asset trading capabilities. The current market is flooded with trading aggregators, but few have distinctive features or design that enhance user stickiness. Singularity, serving as a privacy layer for transparent pools, firstly addresses the trading pain points of institutions and whales, maintaining information asymmetry. Compared to current privacy trading solutions, the design of a dark pool (privacy layer) naturally embodies the principle of “keeping money in the pocket,” as privacy is lost if traders’ funds frequently enter and exit the platform, equivalent to self-disclosure. Hence, most funds prefer to stay in the dark pool for a sufficient time before withdrawing, benefiting the project’s TVL stable growth and providing users with more security.

Based on the aforementioned standards for decentralized dark pools, Singularity stands out among current dark pool solutions for several reasons:

• Anonymity and Privacy Protection : For anonymity, the conventional approach is Zero-Knowledge Proofs (ZKP). Hence, finding the right partners is key. Currently, Singularity delegates off-chain KYC & KYB processes to ComplyCube (KYC) and Shufti Pro (KYC & KYB), with Keyring constructing the corresponding proofs, and oracles ultimately bringing these proofs onto the blockchain. Compared to other projects, Singularity is more in line with current compliance requirements, avoiding future regulatory risks similar to those faced by Tornado Cash.

• Fund Safety : Direct comparison of contract safety is not possible. However, since Singularity allows transparent pools to act as dark pools, it may decrease the willingness of users and institutions to move funds, potentially exposing their capital to contract security risks over the long term. As mentioned earlier, frequent fund transfers by institutions/users can also expose addresses, thus requiring a balance between address privacy and fund safety.

• Liquidity : Unlike projects that rely solely on order book/AMM models, Singularity introduces both order books and AMMs to maximize liquidity efficiency. However, the actual application may show that the difference in liquidity due to trading models might not be significant, depending more on the business development capabilities of the project and its compliance, with the final decision resting largely in the hands of market users.

• Scalability : In terms of ecosystem compatibility, Singularity’s compatibility with the EVM ecosystem is a mainstream narrative. If not considering creating its own chain, its transaction settlement efficiency is still highly limited by its settlement layer. In extreme cases, these layers might not be able to handle high-frequency transactions. Therefore, in the medium to long term, projects that extend the app-chain ecosystem direction will be more scalable. Technically, Singularity opts for FHE+ZKP, which is more efficient than MPC-ZKP solutions due to the high computational efficiency required by MPC-ZKP. Hence, Singularity’s chosen technological approach seems to meet the transaction needs. From an ecosystem expansion perspective, the “transparent pool as dark pool” approach can extend to non-transactional scenarios and other DeFi contexts, offering imaginative possibilities comparable to those proposed by Uniswap V4 with hooks.

While recognizing Singularity’s core competencies, it’s also important to be aware of potential risks the project may face in the future:

• Market Price Discovery Function Loss : Due to the anonymity and large volume of dark pool trades, the prices of assets on the market may not accurately reflect fluctuations within the dark pool. This results in a loss of effective price discovery, as other market participants cannot access information on dark pool trades. The exception is if users use conventional DEXs for price discovery on Singularity, where prices may reflect the actual market supply and demand.

• Government Regulatory Risk : Dark pool trades, potentially used to evade regulation and standards, might prompt government agencies to implement stricter regulatory measures. These could include enhanced monitoring and regulation of dark pool trades or penalties for individuals and entities participating in such trades. These measures could impact the development and operation of the Singularity project and increase legal risks.

• Fund Control and Safety : With funds kept long-term in Singularity contracts, akin to a Vault, there could be contract risks in extreme situations. However, since Singularity does not involve multi-chain communication or rely on transaction relayers, its security is at least higher than that of cross-chain bridges.

• KYC/KYB Risks : The high dependence on a limited number of partners for user qualification checks could introduce single points of failure.

In summary, Eureka Partners considers the privacy track as a significant strategic investment. For investment institutions and other stakeholders, Singularity represents dark pool trading; however, for regulators, it’s more akin to a “grey pool.” We anticipate that OTC and institutional trades will gradually embrace regulated dark pool privacy trading methods. We believe that the current technological development in Web3 is making “iterative progress.” Following strict regulation of Tornado Cash, a visible demand vacuum for privacy trading emerged. Historically, the implementation of rules often lags behind technological breakthroughs and revolutions. When technology faces challenges, we should embrace change and not waste any crisis. We look forward to Singularity becoming the next leader in the regulated dark pool ZK privacy track.

“Never waste a good crisis.” - Winston Churchill

Disclaimer：

1. This article is reprinted from Eureka Partners, Forward the Original Title‘Eureka Partners Research Report: Singularity - Privacy Transactions on Transparent Blockchains’,All copyrights belong to the original author [Oliver, Andy, Howe]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.