Dark pools are rapidly emerging as the next frontier of Ethereum’s decentralized finance (DeFi) sector. Dark pool designs mitigate issues like price uncertainty and poor trade privacy in onchain exchanges–issues that have made outside investors wary of DeFi, despite obvious benefits like access to 24/7 liquidity and novel yield generation mechanisms. 

In this article we provide an overview of dark pools and explore their role in traditional finance and DeFi. We further explain the mechanics of crypto-native dark pools and discuss potential roadblocks to broader adoption of onchain dark pools. 

Introduction: Dark pools in traditional finance 

Despite sounding ominous and illegal, dark pools are actually a longstanding component of the (highly regulated) traditional finance system. Below is a definition of a dark pool from Investopedia:

“A dark pool is a privately organized financial forum or exchange for trading securities. Dark pools allow institutional investors to trade without exposure until after the trade has been executed and reported. Dark pools are a type of alternative trading system (ATS) that gives certain investors the opportunity to place large orders and make trades without publicly revealing their intentions during the search for a buyer or seller.”

Dark pools are popular among institutional investors, high net worth individuals, hedge funds, mutual fund companies, and other entities that wish to execute large-scale trades anonymously. The desire to conduct trades anonymously derives from the sensitivity of market prices to perceived demand and supply (further increased by electronic trading platforms that enable near-instant responses to even weak signals). This is especially true of traditional exchanges where the orderbook is public and people can place or cancel orders at will. 

The order book in a central limit orderbook (CLOB) exchange is public. (source)

Suppose Alice places a market-sell order to sell 500 Tesla shares on an exchange. This is a small order that will have barely any impact on the price of Tesla shares offered on the exchange. However, Alice placing an order to sell 10 million shares of Tesla stock is a different thing altogether. 

In this scenario, a large sell order visible in the orderbook signals a potential drop in demand for Tesla stock. Sophisticated trading firms, particularly those utilizing high-frequency trading (HFT) algorithms, are likely to pick up on this signal. They may act quickly by selling their holdings before Alice’s order can be executed, anticipating a decline in Tesla's stock price. Consequently, the market value of Tesla shares could decrease, leading to a worse execution price for Alice. If Alice isn't leveraging advanced trading techniques, her trade might end up at a loss because the price drop occurs before her order is filled.

The problem is further complicated by the presence of HFT firms who employ proprietary algorithms capable of responding in real-time to activity in a central limit orderbook (CLOB) exchange. Here are some hypothetical scenarios:

Frontrunning 

Imagine Alice, an investor, decides to sell a large number of Tesla shares on a traditional stock exchange. If she places her sell order in the market, the details of this order, including the size and intent, become publicly visible to other participants before the trade is finalized. A sophisticated trading firm, equipped with high-speed trading algorithms, might notice this large order and quickly act on this information.

For instance, the trading firm could decide to sell its own Tesla shares before Alice’s order is executed, anticipating that her large sell order will drive down the stock’s price. By doing so, the firm locks in a higher price for its shares before the market reacts to Alice's sell-off. Once Alice’s large order is executed, the flood of shares hitting the market pushes the price lower, and the trading firm can then buy back the same stock at a discounted rate, profiting from the difference.

This practice, called frontrunning, exploits the visibility of Alice’s order to gain a financial advantage at her expense. The result for Alice is a worse execution price for her trade because the market reacts negatively before her order is completed. Frontrunning is a significant issue in traditional financial systems where orderbooks are public, allowing certain participants to act on information before others have the chance.

 

Quote fading 

Let’s continue with Alice’s example, but this time focusing on the behavior of market makers—entities that provide buy and sell quotes on an exchange. Suppose Alice’s large sell order becomes visible on the exchange’s public orderbook. A market maker initially had a standing offer to buy Tesla shares at $200 each. Upon seeing Alice’s sizable sell order, the market maker might suspect that the increased supply will cause the price of Tesla shares to drop.

To avoid purchasing the shares at $200 only to watch their value decline, the market maker quickly cancels or modifies its buy order. This action, known as quote fading, effectively removes liquidity from the market. When Alice’s sell order finally executes, there are fewer buyers left, and she has to settle for a lower price—perhaps $195 instead of $200.

Quote fading unfairly disadvantages traders like Alice by allowing liquidity providers to adjust their quotes based on insider-like knowledge of other participants' trades. Because the orderbook is public in centralized limit orderbook (CLOB) exchanges, market makers can see incoming orders in real time and react accordingly. Unfortunately, Alice has no way to prevent her trade from being affected by this practice, as it stems from the transparency of the orderbook itself.

Why dark pools?

Dark pools appeared in traditional finance as a response to the aforementioned problems. Unlike a “lit” exchange, dark pools execute trades outside of public exchanges like the NYSE (New York Stock Exchange) and Nasdaq. Orders submitted by buyers and sellers are matched directly and no one but the central operator has information about the orderbook. 

More importantly, each person trading through a dark pool is only aware of their own order(s) and the clearing price. Unless the central operator leaks information, it is impossible to know anything about other users–such as their identities and size/value of orders–even when trading assets with counterparties. 

This has several implications for people who wish to trade with minimal exposure to market fluctuations. Specifically, traders can conduct large-scale trades without telegraphing intent to buy or sell a particular stock to the public and reduce the impact of a trade on the stock market. This increases the certainty that a significant trade won’t suffer frontrunning or quote fading and the seller (or buyer) will have the best price available.

Suppose Alice decides to sell 10 billion Tesla shares in a dark pool, setting an ask price of $1 per share. The dark pool identifies and matches Alice's order with Bob's corresponding order to buy 10 billion Tesla shares at the same valuation. When the trade executes, the public remains unaware of the transaction details until after settlement. Only then does the market learn that 10 billion shares changed hands, but without knowing the identities of the buyer or seller, thereby protecting both parties' trading intentions and strategies.

We can see how trading via a dark pool protects Alice’s interests and increases quality of execution and certainty of clearing price:

• Bob doesn’t know anything about Alice and only knows he received 10 billion Tesla shares for $10 billion, and someone received $10 billion for those shares. Bob cannot fade the quote because the orderbook is concealed—Bob must plan to actually buy shares to know someone has 10 billion shares to sell (this information is known once the order is matched).

• Frontrunning Alice’s trade is difficult since the central operator obfuscates details of pending buy and sell orders and market liquidity. The only way Alice’s trade becomes public information is if the dark pool administrator shares the information with external parties (this is illegal, however). 

 

Today, there are dozens of pools in operation and estimates suggest that 40 percent of electronic trades are conducted via dark pools. The growing popularity of dark pools has coincided with growing regulation, especially given pool operators’ privileged access to information about pending orders (Credit Suisse and Barclays were fined a combined $150m in 2016 for leaking information about dark pool trades to external parties).

Dark pools in DeFi 

(source)

If dark pools are necessary in TradFi, they are arguably even more critical in DeFi due to the inherent transparency of blockchain systems and the challenges this creates for maintaining trade privacy and execution quality. This is especially true for decentralized exchanges (DEXes) that facilitate electronic trades and provide functionality similar to traditional exchanges. 

• Archival nodes can query the blockchain for information about historical transactions interacting with an AMM pool and cross-reference it to onchain activity associated with a particular address. This makes it trivial for anyone to copy trading strategies employed by alpha traders.

• The mempool which stores information about pending transactions is public and available to anyone connected to a full node. This makes DEX users susceptible to the quote fading problem where people cancel buy/sell orders in response to a large trade capable of moving the market and leads to worst-price execution for traders.

• The post-state of a DEX can be computed trivially by anyone observing the mempool, which opens the door to malicious MEV (maximal extractable value) extraction by validators and MEV bots. These actors can observe the impact of a trade on the DEX pool and decide to frontrun or sandwich the transaction if simulating state changes reveals potential profits. (That users send transactions “in the clear” for inclusion in a block compounds the problem.)

• The DEX trade might fail to go through if a block producer deliberately censors a user’s transaction. Since account information is publicly available, validators can build up profiles for specific addresses and choose to discriminate against those counterparties when processing transactions.

• Validators might see information about a transaction and decide to exclude it from the next block. Users cannot obfuscate transaction details from validators or avoid disclosing intent to buy/sell tokens. 

(Source)

These issues have led to traditional DEXes falling out of favor with large whales and institutional traders who are sensitive to price and execution quality. DeFi is the biggest casualty, however–with DEXes unable to supplant TradFi exchanges despite boasting several qualities like borderless transactions and trustless, transparent execution for users. New alternatives like CowSwap and UniswapX have appeared to solve the problem, but reintroduce the need to trust a central operator, akin to how traditional dark pools function. While dark pools in TradFi are private in the sense that account information is hidden from others, this data remains accessible to the bank or operator, making it susceptible to abuse or leaks if administrators are less-than-capable or unscrupulous.

Bringing dark pools onchain is not only possible but represents an optimal approach for building decentralized trading platforms that offer quality execution without excessive reliance on central operators. While the inherent transparency of blockchains—where anyone can verify computational accuracy through running a node—might seem at odds with dark pool functionality, this challenge can be overcome. The solution lies in privacy-enhancing technology (PET), a cryptographic approach that enables information concealment while maintaining the integrity of ledger updates. This allows us to harness blockchain's verifiability while introducing the privacy features essential for dark pool operation. 

Building decentralized dark pools might seem impossible since blockchains are designed to be transparent and queryable. This is in fact what makes blockchains better than regular databases: everyone can run a node and verify that changes to the database are computed correctly. But we can work around this constraint by leveraging cryptography–specifically, privacy-enhancing technology (PET)–that enables concealing information while making sure updates to the ledger are consistent with the rules. 

How do dark pools work? 

There’s no one way to build an onchain dark pool. However, all crypto dark pools share the common characteristic: they use various cryptographic mechanisms to hide information about onchain trades and increase execution quality for users. 

Multiparty computation (MPC), zero-knowledge proofs, threshold encryption, Fully Homomorphic Encryption (FHE), and Trusted Execution Environments (TEEs) are some primitives available to mechanism designers working on crypto-native dark pools. The goal in every case is to maintain guarantees around trade privacy without increasing trust assumptions or making the system susceptible to manipulation. 

Renegade, Tristero, and Railgun are examples of onchain dark pools in the Ethereum ecosystem. We’ll briefly go over each of these protocols to provide an overview of how onchain dark pools work in practice. This article will focus on Renegade, exploring its design and the protocol’s approach to safeguarding information about trades conducted by market participants.

Renegade: Accelerating private DeFi with cutting-edge cryptography 

Renegade is a decentralized, privacy-preserving dark pool designed to address critical flaws in the existing decentralized finance (DeFi) trading landscape. By leveraging advanced cryptographic techniques like zero-knowledge proofs (ZKPs) and multiparty computation (MPC), Renegade allows users to place, match, and settle orders securely without revealing their balances, trading intents, or strategies to third parties. Unlike traditional DEXes, which expose orderbook data to public scrutiny, Renegade encrypts all wallet and order information, ensuring that trades occur privately and are resistant to manipulation.

At its core, Renegade enables users to achieve trustless, onchain trading with the same precision and execution quality as centralized exchanges while maintaining the privacy guarantees needed to protect against frontrunning, quote fading, and other exploitative practices. By introducing a single global merkle tree for state management, Renegade retains the benefits of blockchain transparency—such as verifiability and immutability—while shielding sensitive trading details from the public eye.

Addressing the problems of current DeFi systems

The design of decentralized exchanges (DEXes) today—whether based on Automated Market Makers (AMMs) or Central Limit Order Books (CLOBs)—introduces critical flaws that impact all participants, from regular users to institutional traders. These issues arise because transactions and orders are broadcast as plaintext on transparent blockchains. While transparency is foundational for trustless verification, it also exposes traders to harmful practices like frontrunning, quote fading, and address profiling. 

For both small traders and large investors, these vulnerabilities result in poor trade execution, financial losses, and reduced trust in decentralized finance. Renegade eliminates these issues by introducing cryptographic techniques that maintain privacy without compromising the integrity of decentralized systems.

Maximal Extractable Value (MEV)

Average total MEV profit (30-day dataset) according EigenPhi

Whenever orders and transactions are visible in the mempool, they become susceptible to manipulation by block producers (in Layer 1) or sequencers (in Layer 2). These actors can reorder, frontrun, or backrun transactions for profit. For instance, observing a large buy or sell order enables malicious actors to execute their transactions with higher gas fees first (frontrunning) or exploit opportunities immediately following execution (backrunning). This form of MEV affects all DEX designs, irrespective of whether they utilize an AMM or CLOB architecture.

Trade transparency

The transparency of blockchain-based orderbooks exposes traders to both pre-trade and post-trade risks:

• Pre-trade risks: In open orderbook systems, publicly visible orders signal traders' intent, enabling adversaries to adjust strategies in response. This can lead to manipulative tactics such as quote fading, where liquidity providers withdraw their orders to exploit incoming trades, causing slippage and degraded execution quality.

• Post-trade risks: Once a trade is executed, its details, including trading strategies and patterns, are permanently recorded on-chain. Malicious actors or competitors can analyze this historical data to predict and exploit future trades. This lack of post-trade privacy leaves traders, especially institutions, vulnerable to exploitation.

By combining these into one broader category, Renegade addresses the entire lifecycle of trading transparency issues with cryptographic solutions that ensure pre-trade privacy and secure post-trade settlement.

Address-based profiling

In transparent blockchain systems, every transaction exposes the address of the initiating party. Adversaries can analyze this data to create detailed profiles, linking trading behavior with specific wallets. This profiling enables discriminatory practices, such as offering worse prices or selectively targeting certain users. While blockchain identities are pseudonymous, sophisticated analytics can correlate addresses with real-world entities or behavioral patterns, further exacerbating these vulnerabilities.

Renegade’s privacy-centric design ensures that user identities and strategies remain protected throughout the trading process, safeguarding both retail and institutional participants.

At the core of these problems lies the unavoidable transparency of blockchains. While transparency ensures trustless verification and immutability—critical qualities for decentralized systems—it also exposes sensitive details about user activity. Every trade, balance update, or pending transaction becomes public information that adversarial actors can analyze, manipulate, or exploit for profit. This creates a system where users face challenges such as MEV extraction, trade manipulation, and address-based profiling, all of which degrade execution quality and erode trust in decentralized markets.

To resolve these issues, Renegade replaces transparency with controlled privacy through the combined use of zero-knowledge proofs (ZKPs) and multiparty computation (MPC). ZKPs ensure that trades are valid, balances are sufficient, and protocol rules are enforced without ever revealing the wallet contents or transaction details. At the same time, MPC enables secure order matching, where multiple parties collaborate to find trade matches without exposing any inputs or leaking sensitive information. 

Together, these techniques form a seamless system where trades remain private, execution is verifiable, and order details are hidden throughout the lifecycle. This eliminates the vulnerabilities inherent in transparent blockchains while preserving decentralization and trustless validation.

With a clear understanding of the problems Renegade solves and its approach to privacy, let’s dive into how the system works to deliver secure, private, and fair trading.

How does Renegade work under the hood?

Renegade reimagines decentralized trading by integrating advanced cryptographic techniques that redefine the boundaries of transparency, privacy, and fairness in DeFi. By addressing the limitations of conventional decentralized exchanges, Renegade introduces an innovative approach that blends privacy-preserving technologies with trustless, on-chain trading.

This section provides a closer look at the unique architectural components that power Renegade. We will explore:

• Commitment tree and wallet design: How user wallets remain fully off-chain and private, secured by cryptographic commitments, and managed through a sophisticated key hierarchy.

• Relayers and super relayers: The role of relayers in facilitating secure trade matching and execution, alongside their integration with delegated wallet permissions.

• MPC matching engine: Renegade’s groundbreaking two-party multi-party computation mechanism that ensures private, trustless trade matching.

• Collaborative SNARKs: How atomic settlements are achieved through the seamless integration of zero-knowledge proofs with multi-party computation.

• Performance and scalability: A discussion of the trade-offs involved in Renegade’s design choices and how its architecture balances privacy, decentralization, and efficiency.

By leveraging these innovations, Renegade not only resolves the critical flaws of existing DEX models but also lays the foundation for a more secure, private, and equitable decentralized trading environment.

Renegade’s wallets and the commitment tree

Renegade introduces a state management model that prioritizes privacy and verifiability. At its core, the system employs a Commitment Tree, an append-only global Merkle tree that stores cryptographic representations (commitments) of user wallets. This design ensures that wallet contents remain completely private while maintaining the trustless guarantees of decentralized systems.

Unlike traditional decentralized exchanges (DEXs) where wallet data is visible on-chain, Renegade keeps all wallet information off-chain, allowing users to securely manage their balances, orders, and transaction history without exposing sensitive details. On-chain, these wallets are represented solely by hiding and binding commitments, cryptographic hashes that obscure the wallet’s contents while ensuring they cannot be tampered with or reused improperly.

An analogy: Wallets as mini-rollups

To better understand Renegade’s architecture, we can draw a parallel to Ethereum rollups. In a rollup, transactions are executed off-chain, where state changes occur privately, and only the state root, a cryptographic representation of the rollup’s cumulative state, is periodically submitted to Ethereum. Alongside this state root, a zero-knowledge proof (ZKP) is provided to validate that the state transition adheres to the rules of the rollup protocol without revealing any transaction details.

Renegade wallets operate in a strikingly similar manner:

• Off-chain execution: All wallet operations—such as order placement, balance updates, and trade execution—occur off-chain. These updates are reflected in the wallet’s private state, inaccessible to external observers, including Ethereum.

• On-chain commitment: After the wallet’s state is updated, its new commitment is added to the commitment tree. This commitment serves as a cryptographic summary of the wallet’s new balances, orders, and any changes made during the update process. The update is accompanied by a ZKP, ensuring that the transition from the old wallet state to the new one is valid.

This similarity highlights how Renegade Wallets function like mini-rollups. They independently process state changes off-chain while relying on the commitment tree to synchronize their state with the broader system. Importantly, this process is tailored exclusively to enhance privacy, rather than scalability, by keeping wallet data opaque and unreadable to all external observers.

Commit-reveal scheme for wallet updates

Every operation on a wallet in Renegade follows a commit-reveal scheme, ensuring privacy and correctness throughout the update process. This mechanism allows users to modify their wallets while maintaining the integrity of the system.

1. Reveal the old wallet: The user submits a Merkle proof showing that their previous wallet commitment exists as a leaf in the Commitment Tree. Crucially, this reveal process does not disclose any details about the wallet’s contents, preserving Renegade’s pre-trade privacy guarantees. The system only learns that the wallet commitment is valid and included in the tree.

2. Compute nullifiers: To prevent the reuse of old wallet states, Renegade requires the computation of two nullifiers for each wallet: a wallet-spend nullifier and a wallet-match nullifier. These nullifiers are derived from the old wallet’s commitment and a private randomness value, ensuring uniqueness. 

The nullifiers are then submitted alongside the new wallet commitment to ensure that the old wallet cannot be reused.

1. Commit to the new wallet: The user generates a new wallet state reflecting the desired updates—such as order placement, balance adjustments, or trade settlements—and computes its cryptographic commitment. A ZKP is submitted to prove the following:

• The old wallet commitment exists in the Commitment Tree.

• The nullifiers are correctly computed and unique.

• The transition from the old wallet state to the new one adheres to the protocol rules (e.g., no unauthorized balance increases).

• The user possesses the secret keys necessary to authorize the update.

Once the proof is verified and the nullifiers are confirmed as unused, the smart contract marks the old wallet’s nullifiers as “spent” and inserts the new commitment into the Commitment Tree.

(Source: Renegade documentation)

Renegade’s commitment-based architecture ensures that sensitive trading data remains secure at all times. The hiding and binding nature of wallet commitments guarantees that no external observer can infer wallet contents, even with access to the commitment tree. Moreover, the randomness included in the wallet commitment computation prevents adversaries from creating rainbow tables to identify common wallet states, such as wallets with zero balances or orders.

By combining these cryptographic mechanisms with zero-knowledge proofs, Renegade achieves a privacy-first design where wallet operations are verifiable yet invisible to external parties. This ensures that the protocol maintains pre-trade privacy, protecting users from adversarial strategies like frontrunning and quote manipulation.

Key hierarchy and relayer system

Renegade relies on relayers to facilitate critical operations such as order matching and settlement, enabling users to trade efficiently without compromising security. To achieve this, the protocol implements a robust key hierarchy, a cryptographic framework that separates control and view permissions, ensuring users retain custody of their assets while delegating specific tasks to relayers. This system not only secures sensitive wallet information but also simplifies interactions with relayers, making private and decentralized trading more practical and user-friendly.

How key hierarchy works

Although the current design of Renegade’s Key Hierarchy has evolved beyond its initial description in the whitepaper, the core principles remain consistent. When a wallet is created for the first time and committed to the Commitment Tree, it includes five distinct secrets that collectively define its functionality. These secrets are:

• Root keypair: The root keypair is an ECDSA keypair (secp256k1 curve), identical to a standard Ethereum private key. It is the most authoritative key and grants full custody over the wallet. All operations that modify the wallet’s state—such as deposits, withdrawals, placing orders, or cancellations—require a signature from the root secret key. To ensure maximum security, the root key is kept strictly client-side and is never shared with any external party, including relayers.

• Match scalar: The match scalar is a secret scalar value defined over the bn254 curve and serves as the mechanism by which relayers are authorized to submit matches for settlement to the smart contract or base layer. Unlike traditional asymmetric keypairs, the match scalar is a single secret value that relayers use to generate zero-knowledge proofs (ZKPs), proving their knowledge of the scalar’s preimage under the Poseidon hash. This ensures relayers can only settle matches explicitly authorized by the wallet’s configuration. Additionally, the match scalar is paired with predefined fees in the wallet, allowing users to specify the exact charges relayers can apply for their services.

• Symmetric API key: The symmetric API key is an out-of-protocol tool used to authenticate interactions between the user and the relayer. It allows relayers to stream real-time updates, such as wallet changes or order statuses, to the user without compromising the wallet’s security or its cryptographic integrity. While not directly tied to wallet operations, this key facilitates seamless communication and improves the overall trading experience.

• Blinder seed and share seed: The blinder seed and share seed are essential components that enable relayers to decrypt and process wallet information securely. These seeds function as view keys, granting relayers the ability to access the wallet’s private state. However, as seeds, they are dynamically hashed into values that change with every transaction. This ensures that blinder and share values are specific to the current operation, preventing any reuse or unintended access.

The blinder seed is responsible for indexing the wallet on-chain by creating a cryptographic hash chain that links wallet states. This ensures that the wallet’s presence in the Commitment Tree remains provable without exposing its contents.

The share seed is used to construct “secret shares” of wallet data, enabling the relayer to collaborate with the MPC matching engine during the order-matching process. This integration allows relayers to perform their functions securely and without revealing sensitive details about the wallet to the broader network.

How relayers work in renegade

Relayers in Renegade serve as critical intermediaries that enable the protocol to maintain its privacy-preserving and decentralized nature while offering a seamless trading experience. Acting as both facilitators and enablers, relayers are empowered by the key hierarchy to perform specific operations on behalf of the user without compromising wallet custody or privacy. By leveraging the secrets embedded in the wallet, relayers can decrypt wallet information, identify outstanding orders, and submit matches to the smart contract for settlement—all while maintaining strict cryptographic guarantees.

The relationship between relayers and the Key Hierarchy is built on a clear delegation model. Users share only the necessary secrets—such as the match scalar, blinder seed, and share seed—with the relayer. These secrets grant the relayer the ability to view and process wallet data securely. The match scalar allows relayers to authorize and settle matches by proving knowledge of its Poseidon hash preimage through zero-knowledge proofs (ZKPs). The blinder seed and share seed, meanwhile, ensure that relayers can access wallet data without exposing it to external observers or gaining unauthorized control. This separation of powers ensures that relayers have the tools to perform their delegated tasks without compromising the user’s overall control or security.

A key advantage of this system is that it enables granular delegation. Relayers are restricted to the roles explicitly permitted by the shared secrets. For example, while relayers can view wallet details and match outstanding orders, they cannot modify, withdraw, or cancel orders since the root keypair—the ultimate custodian key—remains with the user. This design ensures that users retain full ownership of their wallets while outsourcing specific tasks for efficiency.

Relayers also bring significant convenience to the trading process by handling the computational complexity of matching orders with the MPC matching engine and ensuring the validity of these matches through collaborative SNARKs. This mechanism allows relayers to offload much of the technical burden from users while maintaining Renegade’s rigorous pre-trade and post-trade privacy guarantees. By securely managing these operations, relayers not only protect sensitive wallet details during order matching and settlement but also alleviate many of the UX challenges typically associated with privacy-preserving systems. Their ability to provide real-time updates via the symmetric API key further enhances the user experience, ensuring that users remain informed about their trades and wallet status without compromising security.

In practice, this system creates a highly flexible and secure trading environment. Users can delegate their wallets to relayers for extended periods, granting them persistent access to match orders without having to repeatedly share new keys. At the same time, users can revoke relayer access at any point by creating a new wallet and transferring their assets, effectively resetting the delegation. This mechanism balances long-term convenience with short-term adaptability, catering to both casual traders and more security-conscious participants.

By integrating relayers into its architecture, Renegade achieves a rare combination of decentralization, privacy, and usability. Relayers act as trusted intermediaries without requiring explicit trust, thanks to the cryptographic safeguards enforced by the Key Hierarchy. This allows Renegade to scale its operations while maintaining the highest levels of security and user autonomy.

 

 

In short, Renegade’s commitment tree architecture and key hierarchy provide a foundational framework for balancing privacy and verifiability in decentralized trading. By ensuring that user wallets remain entirely off-chain and represented on-chain only as cryptographic commitments, Renegade eliminates the visibility of sensitive trading data. 

This design not only prevents frontrunning, quote fading, and other exploitative behaviors but also enables users to retain full custody of their funds through the root keypair. The commit-reveal scheme, coupled with the use of ZKPs, guarantees that wallet updates and state transitions are secure, tamper-proof, and completely opaque to external observers. This ensures a trading environment where trustless verification and strong privacy coexist seamlessly.

The relayer system, integrated with the Key Hierarchy, further elevates Renegade’s user experience and operational efficiency. Relayers simplify the trading process by managing the computationally intensive tasks of order matching and settlement, leveraging the MPC matching engine and SNARK proving to maintain privacy and ensure correctness. At the same time, their ability to provide real-time updates via the symmetric API key bridges the gap between robust privacy guarantees and a smooth user experience. 

By separating view and match permissions, the key hierarchy ensures that users maintain ultimate control over their wallets while relayers operate within strictly defined roles. This system creates a unique balance where users benefit from the privacy-preserving properties of advanced cryptographic techniques without encountering the usability barriers typically associated with such systems.

How orders are matched in Renegade

In Renegade, the process of matching orders combines user actions, relayer facilitation, and cutting-edge cryptographic protocols to create a seamless and private trading experience. This section follows the journey of a single order—from its creation by the user to the final settlement—explaining the role of relayers, the mechanics of the MPC matching engine, and the security guarantees provided by collaborative SNARKs. By exploring these stages, we’ll uncover how Renegade ensures that trades remain private, atomic, and fully verifiable without sacrificing usability or trustlessness.

With that, let’s begin by examining the first step: how a user creates an order and how this action sets the stage for the rest of the matching process.

User creates an order

The order-matching journey in Renegade begins with the user interacting with the interface to create an order. This involves specifying key parameters such as the trading pair (e.g., WETH/USDC) and the quantity they wish to trade. Unlike traditional systems, Renegade does not support limit orders—since Renegade is not a central limit order book (CLOB) and aims to avoid unnecessary complexity—instead, every order is midpoint-pegged, meaning the trade executes at the midpoint of the prevailing spread on major exchanges like Binance, Coinbase, OKX, and Kraken. Once the price has been determined using data from multiple venues, users confirm their order details, and the wallet software seamlessly updates the state to reflect the new order while adhering to Renegade’s privacy-preserving architecture.

The updated wallet state accounts for any reserved balances required to fulfill the trade, as well as relayer fees. This new state is cryptographically committed using a hiding and binding commitment scheme, ensuring that the wallet’s contents remain private and incomprehensible to external observers. To maintain the integrity of the system, the previous wallet state is securely nullified, preventing any possibility of reuse or double-spending.

The wallet software then submits the updated commitment to the commitment tree as part of Renegade’s commit-reveal scheme, along with a zero-knowledge proof (ZKP) that validates the entire transition. This proof ensures that the wallet update follows the protocol rules, including sufficient balances and correct state transitions, without revealing any sensitive details about the order or wallet contents. Once the transition is verified, the old wallet is marked as spent, and the new commitment is securely added to the Commitment Tree.

From the user’s perspective, this entire process is seamless. Once the order is successfully placed, the updated wallet state, including remaining balances and active orders, is displayed in real time. Importantly, the user’s trading intent and wallet details remain completely private, preserving Renegade’s pre-trade privacy guarantees.

With the order now committed to the system, the relayer can begin processing it for potential matches, taking the next step in the secure and private trading process.

Relayer processes the order

Once the user places an order, the relayer becomes an essential part of the process, facilitating secure and private interactions between the user's wallet and the broader Renegade system. Armed with the delegated secrets—the match scalar, blinder seed, and share seed—the relayer decrypts the user’s wallet to access the details of the newly created order. This delegation makes the relayer the critical intermediary, seamlessly bridging the user's private wallet and the broader trading ecosystem, ensuring the order is matched efficiently and in full compliance with the protocol’s privacy and security guarantees.

The first task of the relayer is to decrypt the wallet using the blinder seed and share seed, which are dynamically hashed for each transaction. This ensures that these values are unique to the specific operation, further reinforcing privacy and security. Once decrypted, the relayer gains view access to the wallet’s private state, including the newly created order, balances, and any other outstanding orders. However, the relayer cannot modify or interfere with the wallet contents, as the root keypair remains solely under the user’s control.

After accessing the wallet state, the relayer constructs a handshake tuple to securely communicate the order to the Renegade network. This tuple contains:

• Cryptographic commitments to the order details (e.g., token pair, amount, price).

• A zero-knowledge predicate, which cryptographically proves that the order is valid under the protocol rules without exposing sensitive details like the wallet’s balances or order specifics.

• Additional metadata required for compatibility checks, such as fees and settlement preferences.

The handshake tuple is then broadcast to other relayers within the peer-to-peer (P2P) network, signaling the availability of the order while ensuring that its privacy remains intact. As the handshake propagates, other relayers monitor incoming tuples to identify orders that could potentially match with those managed by their wallets. The relayer responsible for the user’s order does the same, continuously searching for counterparties that meet the user’s specified criteria using the cryptographic commitments and compatibility metadata.

(Source: Renegade documentation)

When a potential match is identified, the relayers responsible for the two orders begin direct communication to initiate the next phase: secure order matching using the MPC Matching Engine. This ensures a seamless transition from order creation to secure matching, while maintaining Renegade’s core privacy guarantees.

Matching the Orders

The process of matching orders in Renegade showcases an innovative application of Multi-Party Computation (MPC), tailored specifically to enable secure, private, and decentralized trading. Unlike traditional implementations of MPC, which often involve multiple participants contributing inputs for a collective computation, Renegade’s MPC is designed for a two-party setup. In this case, two relayers, each acting on behalf of their respective users, collaborate to evaluate whether their orders can be matched. This unique adaptation of MPC ensures that neither relayer learns any sensitive details about the other’s order, such as token types, balances, or pricing, while still allowing for accurate and trustless order matching.

(Source: Renegade documentation)

The MPC matching engine begins by processing encrypted inputs from both relayers. These inputs include critical details such as the orders’ token pairs, amounts, prices, and associated wallet states. Throughout this process, all information remains encrypted and is represented as secret shares within the MPC protocol. The computation verifies whether the orders align on key parameters, such as token pair compatibility, balance sufficiency, and pricing conditions. If the orders are found to be incompatible, the process terminates without leaking any information about the attempted match, preserving the trade privacy of both parties.

If the MPC engine determines that the orders are compatible, it generates a match tuple, a cryptographic representation of the match. This tuple includes essential details such as the tokens to be swapped, the amounts involved, and the direction of the trade for each participant. 

However, in line with Renegade’s privacy-first approach, this tuple is not immediately opened. Instead, it remains encrypted, ensuring that neither relayer can prematurely access its contents or infer details about the counterparty’s order. By deferring the exposure of this information, and due to the robust cryptographic assumptions of the MPC Matching Engine, Renegade eliminates the risk of sensitive data being revealed during the matching process, even in the case of a malicious relayer. 

(Source: Renegade documentation)

The primary exception is the relayer you choose before submitting your order; as they are delegated your view key, a dishonest relayer could access all your past and future orders. Nevertheless, the fact that this is the only trust assumption within Renegade and that you can freely run your own relayer makes this concern largely negligible.

To validate the match tuple, the relayers collaboratively construct a collaborative SNARK proof, which cryptographically confirms that the match is valid under the protocol’s rules. This proof ensures that:

• The orders were correctly matched based on their encrypted inputs.

• The match tuple accurately reflects the wallet states and orders provided during the MPC process.

• Neither relayer manipulated the match tuple or submitted invalid data to the MPC engine.

Collaborative SNARK Proofs play a critical role in ensuring the integrity of the matching process. By linking the encrypted outputs of the MPC engine to the commitments stored in the Commitment Tree, they provide a trustless validation mechanism that guarantees the match adheres to Renegade’s protocol rules. Only after the proof is verified to the encrypted values in the match tuple—such as the amounts to be swapped—become accessible. This phased approach safeguards the trade privacy of both parties throughout the matching and validation process.

Once the Collaborative SNARK Proof is verified, and the encrypted match tuple is opened, the system transitions to the settlement phase. At this point, the matched orders are fully validated and ready for settlement, with all trade details securely encapsulated and verified. This seamless integration of MPC and Collaborative SNARKs ensures that Renegade’s matching process is not only private and secure but also trustless and tamper-proof, setting a new standard for decentralized trading.

Trade finalization

After the match tuple and collaborative SNARK Proof have been validated, the process moves into the finalization phase, where the results of the matched trade are securely recorded and prepared for settlement. At this stage, all necessary cryptographic validations have been completed, ensuring the integrity of the trade while maintaining the privacy of both parties involved.

To finalize the match, each trader’s wallet generates a record of the trade, summarizing what tokens were exchanged, in what amounts, and in which direction. These records serve as secure placeholders for the results of the match and are tied directly to the cryptographic commitments that represent the updated wallet states. Importantly, these records are generated privately for each trader and include cryptographic safeguards to prevent unauthorized access or manipulation.

After verifying the encrypted trade records and proofs, Renegade's smart contract updates the commitment tree and marks the orders as "encumbered"—preventing further actions until settlement. These encrypted records persist in the commitment tree for settlement reference. This phase demonstrates Renegade's privacy-security architecture: encrypted trade details combined with cryptographic proofs enable trustless, private trading while maintaining verifiability throughout the settlement process.

Performance and scalability

This section delves into two fundamental challenges that arise from Renegade’s innovative design choices:

• Computational costs of MPC and SNARKs: The trade-offs in latency and resource demands introduced by these advanced cryptographic techniques.

• Scalability of the relayer network: How Renegade’s peer-to-peer infrastructure manages high trading volumes and adapts to varying user needs.

Let’s explore each of these in detail.

Computational costs of MPC and SNARKs

Renegade’s architecture heavily relies on MPC matching engine and collaborative SNARK proofs to deliver unparalleled privacy and security. However, these advanced cryptographic techniques come with substantial computational demands. The MPC process requires relayers to perform encrypted computations on secret-shared inputs, which involves multiple rounds of secure communication and computation to evaluate the compatibility of orders. This introduces significant overhead compared to traditional matching systems, especially when processing complex or high-volume trades.

Similarly, generating collaborative SNARK Proofs is a resource-intensive task. While SNARKs are designed to be efficient for verification on-chain, their creation involves extensive cryptographic operations, particularly when proving complex statements like order validity and wallet state transitions. This computational cost adds to the time and resources required to complete a trade, making it less suitable for scenarios requiring high-frequency or instantaneous trading.

In summary, these two operations represent one of the largest computational burdens for relayers tasked with matching user orders. While this cost is a necessary trade-off for achieving the strong privacy and security guarantees that define Renegade, it remains a key consideration for scalability and user experience.

Scalability of the relayer network

Renegade’s design minimizes trust in relayers, relying on them only for the liveness required to match trades. Beyond this, relayers hold no custodial authority or decision-making power, as all actions are cryptographically validated through zero-knowledge proofs (ZKPs). This trustless design means that strengthening relayers computationally—for example, by increasing their processing power to handle more trades—does not introduce significant risks. At the same time, Renegade’s network architecture is fully permissionless, enabling a diverse range of relayers, varying in size and computational capability, to coexist within the same ecosystem without causing any systemic issues.

This flexibility is one of Renegade’s strengths. Smaller relayers can operate effectively alongside larger, more powerful ones, ensuring a robust and decentralized network. The protocol's reliance on cryptographic guarantees ensures that all relayers, regardless of size or scale, must adhere to the same strict validation rules, preserving the system’s fairness and integrity.

Super relayers, on the other hand, offer a specialized role within the network, designed to cater to advanced users and institutional participants. Unlike standard relayers, super relayers operate with delegated root key access, granting them full control over a user’s wallet. This means they are not just trusted to match trades but to manage the entire wallet lifecycle, including order placements, cancellations, and balance adjustments. By delegating the root key, users gain significant improvements in speed and performance, as the super relayer can bypass on-chain verification steps for certain operations.

However, the delegation of the root key introduces a high level of trust, making super relayers suitable primarily for entities that operate their own relayer infrastructure for personal use, such as institutions or sophisticated individual traders. These users can leverage super relayers to optimize their trading systems, benefiting from near-instant order execution and reduced costs while maintaining direct oversight of the infrastructure.

(Source: Renegade documentation)

Renegade’s relayer network, with its blend of standard and super relayers, exemplifies a scalable and adaptable system. It achieves this scalability without sacrificing decentralization or security, ensuring that the network can handle diverse user requirements and trading volumes while maintaining its core principles of trustlessness and permissionlessness.

Conclusion

In this article, we introduced the concept of dark pools, highlighting their role in traditional finance and their growing importance in decentralized finance. By examining Renegade, we demonstrated how cryptographic innovations like zero-knowledge proofs and multiparty computation can address critical issues such as frontrunning, quote fading, and MEV extraction, paving the way for secure and private decentralized trading. 

 

Moving forward, the discussion on dark pools will expand to include other noteworthy protocols such as Tristero and Railgun. Both of these projects provide unique approaches to enhancing trade privacy and execution quality, each employing different methodologies to achieve their goals. 

 

In upcoming articles, we will delve deeper into their designs of these protocols, exploring their advantages, distinct features, and how they compare to one another and to Renegade. This broader exploration will shed light on the diverse solutions shaping the future of privacy-preserving decentralized finance. 

 

Until then, stay with 2077!