Building a Dark Pool on Stellar: MPC, FHE, and TEEs Compared

When an institutional investor wants to buy half a million shares on a traditional exchange, they face a dilemma: place the order publicly, and watch the price move against them as the market sees it coming. This is why dark pools exist in traditional finance—private venues where large orders execute without revealing intentions to the broader market.

On many blockchains, pending transactions propagate through publicly observable gossip networks (and on EVM chains, a public mempool), giving bots advance visibility to front-run. The flow on Stellar is different and confirmations are fast, but the broader point remains: when orders or intents are visible before execution, sophisticated actors can exploit that information.

We set out to explore how privacy-preserving trading could work on Stellar. The journey took us through zero-knowledge proofs, multi-party computation, fully homomorphic encryption, and trusted execution environments. Here's what we learned.

Adversaries: Exchange operators who might front-run, MEV bots monitoring orderflow, cloud providers hosting infrastructure.

Trust assumptions vary by approach: Hardware vendor (TEEs), honest quorum (MPC), chain consensus (onchain settlement).

Goals: Pre-trade privacy (hide orders before execution), post-trade privacy (optional), censorship resistance, liveness.

A Central Limit Order Book (CLOB) sits at the heart of most exchanges. Buy and sell orders are sorted by price—bids from highest to lowest, asks from lowest to highest. The best prices get matched first, and when two orders share a price, the earlier one takes priority.

Different matching mechanisms exist. Continuous Double Auctions (CDA), used in most modern markets, allow buyers and sellers to submit orders at any time during trading, with trades executing immediately upon match. Periodic auctions, or Volume Trading, work differently: there's an open phase where orders are submitted, then a price discovery phase calculates the price that maximizes traded volume, and all trades execute at that uniform price.

With a standard order book implementation, unmatched orders are visible to the operator (and in DeFi, to everyone). This visibility enables two particularly nasty forms of exploitation:

Front-running occurs when someone sees your large buy order pending in the mempool and quickly places their own buy order first. The price goes up, and you end up paying more. They profit from the price movement your order caused.

Sandwich attacks take this further. The attacker places a buy order before yours (front-running), then a sell order after yours (back-running). Your transaction gets "sandwiched" between theirs. They buy low, your order pushes the price up, and they sell high—capturing the price movement they engineered at your expense.

These aren't theoretical concerns. MEV (Maximal Extractable Value) bots extract substantial value from DeFi users through exactly these techniques.

Zero-knowledge proofs are powerful tools for verifiability. They allow an off-chain party to execute a program and prove onchain that the result was computed correctly, without revealing the program's private inputs.

At first glance, this seems ideal for a dark pool: private, off-exchange trading venues. An operator could match orders off-chain, publish the result, and provide a ZK proof that the matching algorithm was executed correctly.

The problem is that ZK proofs alone do not provide pre-execution confidentiality in an operator-driven model. Unless orders are encrypted or otherwise hidden from the operator until execution completes, the operator necessarily learns orderflow while assembling the proof. This reintroduces the very information asymmetry dark pools are meant to eliminate.

One might try to address this with a commit–reveal or two-phase auction protocol: traders first submit cryptographic commitments to their orders, the operator commits to a batch, and only then are orders revealed for matching. This helps prevent direct front-running within a round, but it does not fully solve the problem. The operator still learns unmatched orders, revealing traders' short-term intent. Even if exploitation cannot occur immediately, this information can be used strategically in subsequent rounds.

In short, ZK proofs are excellent for ensuring correctness, but without an additional confidentiality mechanism—such as MPC, FHE, or TEEs—they do not prevent privileged parties from learning orderflow and acting on it. For a true dark pool, hiding inputs before and during execution is as important as proving the output was correct.

Before building our own solution, we looked at existing approaches:

Penumbra [3] reduces ordering-based MEV by batching intents and executing swaps as a batch at the end of each block; transaction ordering within the block becomes less relevant. However, the operator can still potentially affect clearing prices by introducing their own positions, and partial intent visibility remains a consideration.

Unyfy [4] combines secure enclaves with ZK proofs. Commitments to orders are posted onchain, but matching happens inside TEEs. ZK proofs verify correct execution independent of hardware trust. It's an interesting hybrid: blockchain for custody, TEEs for confidentiality, ZK for verifiability.

Sunscreen uses threshold FHE, similar to what we explored in our own experiments.

• ZK: Verifiable, but not inherently confidential in an operator model. Liveness depends on prover availability.
• MPC: Confidential (with honest threshold). Verifiability depends on scheme/committee design. Liveness requires quorum participation.
• FHE: Confidential. Verifiability is separate (needs ZK or redundancy). Too slow for this workload today.
• TEE: Confidential with hardware trust assumptions. Attested integrity provides verifiability. Liveness/censorship resistance depends on the operator.

Hybrid sweet spot: TEE for speed + ZK for public verifiability of critical invariants (e.g., solvency, matching correctness). Unyfy exemplifies this approach.

MPC enables private computation distributed across multiple parties. Various protocols offer different guarantees—some require an honest majority, while the SPDZ protocol [6] guarantees privacy unless all parties collude.

For a dark pool, MPC means multiple non-colluding parties collectively execute order matching without any single party seeing the incoming orders before results are revealed. This genuinely prevents front-running and sandwich attacks. Cartlidge et al. demonstrated this approach using the SCALE-MAMBA framework in their paper "MPC Joins The Dark Side” [1].

We built a prototype on Stellar using the MP-SPDZ framework [2], implementing a matching protocol for periodic auctions. MP-SPDZ offers a Python-like programming model that compiles down to MPC protocols, making it more accessible than SCALE-MAMBA (though the latter has experimental Rust support via WASM compilation).

Understanding SPDZ's two-phase structure:

SPDZ splits computation into an offline (preprocessing) phase and an online phase. The offline phase generates "Beaver triples"—correlated random values that enable secure multiplication. These triples are the expensive part to produce, but once you have them, the online phase is remarkably fast.

The catch: each Beaver triple can only be used once. More computation means more triples needed. And for a 24/7 exchange with unpredictable volume, continuous preprocessing helps but doesn't eliminate the fundamental constraint—you still need to generate triples at least as fast as you consume them, and spikes in trading activity can outpace preprocessing capacity.

Our experimental results:

We simulated 50 buyers and 50 sellers per round, measuring combined offline+online compute-time on an Apple M3 MacBook Air. The results showed clear linear scaling:

The linear relationship with rounds makes sense: each round requires fresh Beaver triples that can only be used once. A more thorough study would decouple the offline and online phases to measure them independently.

Participant scaling is more concerning:

We also measured how time increases with participant count for a single round. Here too we see roughly linear growth—around 100 seconds for 100 participants, climbing to about 600 seconds for 1,200 participants.

For an exchange with thousands of participants and high trade volumes, this linear scaling becomes a serious constraint that preprocessing alone can't solve.

A note on MPC verification:

It's not enough to secret-share inputs and execute matching via MPC—we also need to verify that claimed results actually stem from correct protocol execution by a threshold of honest participants. The MPC participants maintain secret state throughout and run off-chain, but auction results must be committed onchain. A common pattern is committee attestation: a threshold of MPC nodes jointly sign the output. Public, non-interactive verification like a SNARK over the MPC execution is possible, but typically adds complexity and cost.

FHE is cryptographically beautiful: compute on encrypted data without ever decrypting it. Traders could submit orders encrypted under a public key corresponding to the FHE scheme. The operator would evaluate the matching algorithm on the ciphertexts, producing an encrypted result. The corresponding decryption key could be secret-shared among multiple operators, allowing a quorum to threshold-decrypt the results without any single party ever seeing plaintext orders.

FHE alone doesn't guarantee correct algorithm execution, but that's solvable. The real problem is performance.

Using Zama's Concrete FHE library, we simulated just 10 buyers and 10 sellers with random volumes and different limits.

Computation time: 204 minutes. Over three hours for 20 participants.

(Benchmark details: security level, precision, and parameters are documented in the repo; results are illustrative, not a universal constant.)

This isn't a criticism of Zama's implementation—it's excellent work pushing FHE forward. But for high-performance trading with many participants, FHE simply isn't viable with current technology. The gap between what's theoretically possible and what's practically usable remains enormous. Compare this to the ~30 seconds MPC takes for 100 participants—FHE is orders of magnitude slower. This is not merely an engineering challenge that simply takes time. A significant breakthrough is required for FHE to become a suitable solution – either a theoretic innovation in the form of a more efficient cryptographic construction, or hardware acceleration solutions that somehow improve performance by orders of magnitude.

Trusted Execution Environments (TEEs), including Intel SGX and TDX, AMD SEV-SNP, and AWS Nitro Enclaves, provide hardware-isolated computation with remote attestation. Code and data are decrypted only inside the protected execution context, while the surrounding host—including the OS and hypervisor—is treated as untrusted.

For a dark pool, this maps cleanly onto the problem. Traders can send encrypted orders to an attested matching engine, confident that plaintext order data is only visible inside the TEE. The matching logic runs on native hardware, and results are returned along with cryptographic proof that a genuine enclave running a specific, audited codebase produced them.

TEEs effectively combine the strengths of other approaches: confidentiality comparable to FHE, integrity guarantees similar in spirit to ZK proofs, and performance close to native execution. There is no need to split computation across many parties or operate on encrypted data; existing matching engines can often be deployed with minimal modification.

The tradeoff is trust in the hardware platform and its attestation infrastructure. TEEs do not eliminate all risks: side-channel attacks remain an active area of research, and TEEs do not inherently provide censorship resistance or liveness guarantees. A malicious or unavailable operator can still refuse service or go offline.

However, when combined with onchain settlement, transparent attestation, and defense-in-depth techniques (such as ZK proofs for critical invariants), TEEs offer the most practical path to production-grade, privacy-preserving trading today. For systems that require both high throughput and strong pre-trade confidentiality, they currently represent the best available engineering tradeoff.

We built a working prototype on Stellar using Phala's TEE Cloud, which offers Intel TDX-enabled confidential VMs. The code is available on GitHub, and while it's experimental, it demonstrates the complete flow from order submission to onchain settlement.

The system has two components working in tandem. Off-chain, a Python matching engine runs inside the TEE, receiving signed orders via REST API and maintaining a private order book with price-time priority matching. Onchain, a Stellar smart contract manages user vault balances and executes atomic transfers when trades settle.

The vault model is key to enabling instant settlement. Traders deposit funds into the contract ahead of time. When the matching engine finds a match, it calls the contract's settlement function, which atomically updates vault balances. No user signatures are needed at settlement time since funds are already locked—but orders themselves are signed by traders using SEP-0053. The settlement contract verifies that submitted trades reference valid signed orders, checks order IDs for replay protection, and confirms the matching engine is authorized. This prevents the engine from settling at unauthorized prices or amounts.

Establishing Trust Without a Certificate Authority

Here's where things get interesting. The matching engine uses a self-signed TLS certificate, which would normally be a red flag. But the private key for that certificate was generated inside the TEE and has never existed anywhere else. The same is true for the Stellar signing key the engine uses to authorize settlements.

To prove this, we bind both public keys into Intel TDX's attestation. The TEE computes a hash combining the Stellar public key, the TLS certificate's SPKI hash (a cryptographic fingerprint), a timestamp, and an optional client-provided challenge. This hash goes into the attestation quote's reportData field, which Intel's hardware then signs.

The Docker Compose configuration—including a pinned container image digest—also gets hashed and recorded in the attestation. Anyone can fetch this configuration, compute the hash themselves, and verify it matches what Intel attested. This proves the matching engine is running exactly the code that was audited, not some modified version.

When a client connects, they can extract the TLS certificate from the live connection, compute its SPKI hash, and verify it matches what's in the attestation quote. If it matches, they know their encrypted connection terminates inside the genuine TEE—not at some man-in-the-middle proxy.

How a Trade Actually Happens

A trader starts by depositing tokens into the settlement contract's vault. They then sign an order using SEP-0053 (the standard for off-chain message signing on Stellar) and submit it to the matching engine over HTTPS.

The matching engine validates the signature and adds the order to its book. When a matching order arrives, the engine builds a Stellar transaction calling the contract's settlement function. The contract verifies the caller is the authorized matching engine, then atomically swaps vault balances—the buyer receives the base asset, the seller receives the quote asset.

All of this happens with the order details hidden until the moment of settlement. The infrastructure operator running Phala Cloud can see encrypted network traffic going in and out, but the TEE's memory encryption means they can't see the order book or matching logic executing.

What This Proves (And What It Doesn't)

The attestation gives us hardware authenticity (the quote is signed by genuine Intel TDX silicon), code integrity (the compose-hash proves exactly what's running), and key confinement (the TLS and Stellar keys provably originated inside this TEE instance).

What it doesn't give us is absolute certainty about memory privacy during execution—side-channel attacks are an ongoing practical research risk for all TEE implementations, with new vulnerabilities and patches emerging regularly. Defense-in-depth (combining TEEs with other mechanisms like onchain settlement verification) helps mitigate this. It also doesn't provide censorship resistance (the operator could refuse to include certain orders) or liveness guarantees (the TEE could simply go offline, though depositors could still withdraw their funds from the onchain contract).

Gaps Remaining

Two significant pieces remain before this could be production-ready.

First, contract-level attestation verification. Currently, clients verify trust by fetching the registered matching engine's public key from the settlement contract, then comparing it against what appears in the attestation quote from the matching engine (or vice versa—fetch the attestation first, then confirm the contract has registered that same key). This works and can be fully automated, but the trust check happens client-side. A stronger design would have the settlement contract independently verify attestation quotes, preventing a compromised matching engine from being swapped in even if clients skip verification.

Second, OS kernel verification. We need to verify the Phala OS kernel hash against a reproducible build. Phala runs Dstack [5], which is open-source with reproducible builds. The tooling exists—we just need to complete the verification pipeline to ensure the entire software stack, not just our container, matches expected values.

If you're building privacy-preserving trading infrastructure, here's our assessment:

FHE: Not viable for high-performance trading. The technology is advancing rapidly, but current performance is orders of magnitude too slow for practical use.

MPC: Viable for limited-participation systems or exchanges with natural trading windows. The linear scaling with participants is a hard constraint, but if you have a small, known set of participants, it works well and provides strong cryptographic guarantees without hardware trust assumptions.

TEEs: The pragmatic choice for production systems today. Native performance, lift-and-shift deployment, and strong privacy guarantees make this the best option for most use cases. The tradeoff is trusting the hardware platform—but combining TEEs with onchain settlement and ZK proofs (as Unyfy does) can provide defense in depth.

Privacy-preserving trading is moving from research to production. We're seeing it in projects like Renegade [7], Penumbra, and Unyfy. The tooling is maturing. The demand—from institutional investors who can't afford to have their positions front-run—is very real.

For Stellar specifically, the combination of fast finality, low transaction costs, and the Soroban smart contract platform makes it well-suited for this kind of infrastructure. Our prototype demonstrates the core architecture works.

The remaining work is engineering, not research: hardening the attestation verification (including contract-level quote verification), completing OS kernel verification against reproducible builds, and stress-testing at scale. The cryptographic foundations are solid.

The code for our MPC prototype is available at dark-pool-mpc, the FHE experiments at dark-pool-fhe, and the TEE-based prototype at stellar-dark-pool.