Enabling Private Swaps on Jupiter

[team-encifher]

Introduction

Jupiter has established itself as Solana’s premier DEX aggregator, processing over $980B in volume since inception per DefiLlama and serving as the backbone for DeFi trading on the network. With their expansion into lending, staking, and perpetuals, plus the launch of Jupiter Mobile, Jupiter is positioning itself as Solana’s comprehensive DeFi operating system.

This research examines how Jupiter can capitalise on the next wave of growth by addressing a critical gap: the trade-off between privacy and security. Recent advances in threshold cryptography and Trusted Execution Environments (TEEs) now make it possible to add private trading to existing DEX aggregators without sacrificing composability or user experience. Unlike previous privacy solutions that required separate, isolated protocols, this approach lets traders keep their strategies confidential while still accessing Jupiter’s full liquidity and efficient routing capabilities.

The Privacy Gap in DeFi Trading

Jupiter’s transparency, while foundational to DeFi’s trustless nature, creates significant barriers for sophisticated traders:

1. Strategy Leakage TradFi traders choose CEXs because every trade onchain today reveals their strategy. A sophisticated arbitrage opportunity or technical analysis insight becomes public knowledge the moment it’s executed, eliminating the trader’s competitive advantage.

2. Copy Trading Exploitation Large trades when executed by profitable wallets or doxxed addresses are immediately visible and copied by bots. A memecoin trader who has made a lot of profit in their lifetime by launching coins will surely be copy-traded by users.

3. Institutional Barriers

The rapid evolution of DeFi presents significant opportunities for financial institutions to access new markets and users, particularly through the issuance and distribution of digital assets. Permissionless public blockchains offer unprecedented access to global markets with 24/7 availability and programmability, allowing issuers to benefit from consistent liquidity and broader user reach.

Despite these advantages, however, institutional participation on DeFi platforms is constrained by regulatory, risk management and privacy concerns. Regulated financial institutions remain subject to stringent requirements, including securities laws, anti-money laundering (AML), countering the financing of terrorism (CFT), strategy exposure and sanctions obligations. As a result, institutions often use private blockchain networks or gated systems that are blocked off from the broader onchain market.

• Compliance Requirements: Banks and regulated institutions need to trade confidentiality for regulatory compliance

• Fiduciary Duty: Fund managers cannot expose investment strategies to competitors

• Corporate Treasury: Companies require confidential rebalancing and hedging operations

The Future of DeFi: Privacy as the Next Frontier

DeFi is shifting from centralized exchanges to on-chain solutions, offering transparency and composability. Yet, privacy remains a critical barrier.

Protocols like Jupiter already provide fast access to vast onchain liquidity, but without strong privacy guarantees, they miss out on:

• Professional trading firms that drive significant volume and sophisticated strategies

• Corporate treasury use cases for treasury management

The result: DEXs only account for ~18% of all crypto traded in 2025 according to The Block.

While the shift from CEX to DEX has been evident and vital; if more volume continues moving onchain, privacy will be essential infrastructure. Combined with evolving compliance, it will unlock greater adoption by traders, corporates, and developers with Jupiter leading the way.

What about compliance?

Our privacy-preserving architecture on Jupiter incorporates comprehensive compliance mechanisms to ensure responsible DeFi participation. The system integrates with leading compliance providers like CipherOwl and Chainalysis to conduct pre-transaction wallet screening against sanctions lists, terror financing networks, exploit addresses, and other high-risk categories. Flow-of-funds verification leverages data from Information Providers to determine asset origins, proactively restricting transactions associated with known exploits, OFAC-listed addresses, or illicit activities. This approach enables onchain anti-money laundering risk management while maintaining transaction privacy, particularly crucial given how major exploits often use decentralized exchanges for money laundering. Users experience seamless private trading while compliance checks operate transparently in the background, ensuring the venue remains safe for all participants. The threshold cryptography architecture enables selective regulatory access when legally required while preserving day-to-day privacy.

Our protocol supports selective disclosure through threshold key management, where no single entity can unilaterally access encrypted data. Compliance records are disclosed only through valid legal requests from recognised authorities, with all such actions logged and auditable. This design ensures encrypted transactions remain private from public observation while allowing regulators to access necessary information through proper legal channels. The framework balances user privacy rights with regulatory accountability, supporting institutional adoption by demonstrating that privacy and compliance can coexist effectively in DeFi infrastructure. This approach positions privacy as compatible with compliance requirements rather than adversarial to them, making it suitable for institutional Jupiter adoption while maintaining technical credibility.

[team-encifher]

High-Level Architectural Overview

Our privacy-preserving solution for Jupiter operates through a novel three-layer architecture that enables private trading while maintaining full access to Jupiter’s liquidity and routing capabilities. The system combines onchain encrypted state storage, off-chain TEE-based verifiable computation, and an onchain pointers-based execution framework that bridges the two environments seamlessly.

Encifher coprocessor enables privacy onchain. It works by enabling users to represent their encrypted computation request as symbolic execution over certain pointers (cryptographically bound to ciphertext). The onchain symbolic execution captures users’ intent and commits encrypted transaction graphs, which are processed within a coprocessor on top of actual encrypted values.

At its core, the architecture works by replacing plaintext values and order parameters with encrypted equivalents stored onchain via pointers. When users wrap (encrypt) assets, the asset value gets encrypted using ElGamal encryption under the network public key and generates cryptographically binding pointers to the encrypted data. These pointers enable users to express their intent on top of encrypted data to perform operations without ever exposing the underlying values.

The trading process begins when users create orders with encrypted parameters through ephemeral accounts that are destroyed post-order solving, eliminating address-based tracking. Parallely, our coprocessor running within AWS Nitro continuously monitors thechain for encrypted intent requests, performs the requested encrypted computation off-chain in a verifiable manner and posts the results onchain.

To optimise performance and security, the protocol employs batched processing of encrypted requests and threshold cryptography. Multiple encrypted operations are grouped together to reduce repeated computation and cache results, which enables request processing in batches. The threshold network ensures decentralised key management, preventing any single point of failure, and additionally enabling authorised access for compliance purposes.

The result is a privacy-first trading experience that preserves Jupiter’s core value propositions optimal routing, deep liquidity access, and composability with the broader DeFi ecosystem while protecting traders from strategy leakage, front-running, and surveillance. Users can trade confidentially knowing their strategies remain private, yet still benefit from Jupiter’s superior aggregation capabilities and expanding product suite.

[team-encifher]

Component Deep Dive

1. Wrapping

Encrypted Assets

When a user wraps assets into Encifher, the Wrapper Program serves as the entry point, transforming plaintext tokens into their encrypted equivalents.

Flow:

• A user calls a method with 100 USDC into the Wrapper Program, and subsequently, the wrapper program converts that 100 USDC into its encrypted equivalent onchain.

• The Wrapper immediately encrypts the amount using ElGamal encryption within a secure TEE environment. (This specific encryption operation, while wrapping happens within TEE, and the rest of the encryption operations happen on the client side)

• The encrypted balance can be located with a unique pointer, for example, h100, in a PDA named eTokenAccount, which stores users’ encrypted asset pointers. Furthermore, the pointer is derived through a specific pointer calculation function that utilises the underlying ciphertext as input.

• This provides the user with a counterfactual pointer to their encrypted balance, rather than holding plaintext tokens, ensuring privacy while maintaining programmatic access.

Technical Implementation:

• Deterministic Account Derivation: ETokenAccounts are derived deterministically using user pubkey and token mint pubkey.

• ElGamal Encryption: Provides public key encryption and threshold decryption at scale

• Pointer Generation: These are 16-byte cryptographically secure pointer that serves as a reference to ciphertext.

• Intent Verification: Users can cryptographically verify their intents (computation requests generated while placing an order) such that the requests are correctly computed in a secure/non-tampered environment.

How the wrap contract is designed, how we are converting plaintext to the ciphertext, and where those mappings get stored, how can the user verify that their handle corresponds to the right balance?

The wrapper program is designed to securely convert a user’s plaintext balance into ciphertext using the ElGamal-based encryption scheme. When a user wraps funds, their balance is encrypted, and a pointer is generated to represent that ciphertext. While the pointer is stored and processed onchain. This separation ensures privacy; only the user knows the actual balance, while still allowing computations to be carried out publicly through pointers. Whenever an operation such as adding or updating balances is performed, the new value is encrypted, a corresponding pointer is computed counterfactually, such that the coprocessor would also land onto the same pointer if computation is performed correctly. For verification and updates, ciphertexts are fetched and securely decrypted within a Trusted Execution Environment (TEE) with the help of a threshold decryption network, after which the updated ciphertext and its pointers are stored again in a public storage layer for anyone to verify.

Example:

• Suppose a user has 100 USDC. After encryption, a pointer h100 is created and stored onchain, while the ciphertext is saved in the public storage layer.

• Now the user wants to add 50 USDC. The system encrypts 50 USDC to get its ciphertext and computes a new pointer h50.

• onchain, this looks like h100 + h50. Nobody else knows what h100 or h50 represent, and calculates a pointer h150

Under the hood, the coprocessor retrieves the ciphertexts from the public storage layer, decrypts them securely inside the TEE using threshold decryption, performs the computation, and stores the updated ciphertext along with a new counterfactually constructed pointer h150 and sends it back in the DA layer and onchain.

2. Order Creation

Privacy-Preserving Order Submission

The order creation process ensures that trading intentions remain completely confidential while maintaining compatibility with Jupiter’s routing infrastructure.

Standard Order Parameters: To place a swap order on Jupiter, bare minimum details which users need to specify:

Encryption Process:

• The amount and receiver address are encrypted using the ElGamal public key, producing ciphertexts.

• Token mint addresses remain public as they’re needed for Jupiter’s routing algorithms

• All numerical parameters are wrapped and committed with range proofs to make sure the parameters are integral with respect to the protocol

Ephemeral Accounts: To completely avoid linking user identity to trading activity:

• An ephemeral account per swap is created on the client end, which places an order on the user’s behalf and which receives encrypted tokens from the owner address for placing an order via Anonymous transfer flow implemented within Encifher.

• After successful order completion, the account is immediately destroyed.

• The ephemeral account is itself responsible for initiating and completing order solving

3. Order Solving

For solving orders, Encifher does not maintain any third-party infrastructure; instead, orders are solved directly on the client end. The ephemeral account places the orders and transfers the encrypted assets back to the owner after order completion.

Order Solving Stages: There are four major steps in solving any order on the client end.

1. Withdraw/Unwrapping – Securely decrypt the encrypted token amount using the threshold decryption network

   • Nodes within the threshold network collaborate to decrypt without any single node seeing the plaintext

   • The amount decrypted is unwrapped from the protocol into plaintext form and sent back to the ephemeral account.

   • onchain access control checks validate that the correct authorised user is making the decryption request.

2. Solve – Execute the actual swap using Jupiter’s routing infrastructure

   • Once the tokens are unwrapped/decrypted and the ephemeral account receives tokens in plaintext, solving begins.

   • Decrypted order (e.g., 10 USDC → 10 USDT) is routed through Jupiter’s aggregation engine for solving.

   • Order is solved via Jupiter’s provided path to get the most efficient returns.

3. Wrapping – Re-encrypt the received tokens and generate new ciphertext pointers.

   • Swap output (10 USDT) is immediately wrapped/encrypted using fresh randomness via an ephemeral account

   • New ciphertext pointer (h10) is generated post wrapping and stored onchain in ephemeral account eTokenAccount.

4. Transfer – Complete the settlement process, post-unwrapping asset

   • Ephemeral account transfers the encrypted/wrapped tokens back to the encrypted receiver address specified in the order details via an anonymous transfer flow enabled within Encifher.

All of this happens seamlessly through our abstracted frontend:

The TEE used and their discussions.

Our coprocessor uses AWS Nitro TEEs for enabling computation at scale, unlike traditional TEE implementations designed for enterprise or general-purpose computing. We use TEE with proper KMS-backed attestation and storage keys, which keep rotating at a particular epoch frequency. The KMS-based key rotation mechanism ideally translates root of trust from the hardware to the underlying software

Built on AWS Nitro’s hardware-based security guarantees, TEE provides tamper-proof code execution, data confidentiality, and cryptographic attestation while adding blockchain-specific features like native secp256k1 key support and cost-effective onchain verification mechanisms.

Comparison

[team-encifher]

Privacy tax for users

The ‘Privacy Tax’ concept centres on minimising all costs financial, operational, and experiential to make privacy adoption frictionless for users.

Our approach to building privacy infrastructure is founded on two core principles: eliminating the privacy tax and DeFi primitivization.

Privacy Tax Elimination

Privacy tax encompasses all barriers that users face when choosing private transactions over transparent ones:

• Financial costs: Additional fees for privacy features

• Time penalties: Longer transaction finality and processing delays

• Opportunity costs: Reduced yields or rewards compared to public alternatives

• User experience friction: Complex interfaces and workflows

Our goal is to make privacy so seamless and cost-effective that users naturally adopt it, rather than viewing it as a premium feature requiring significant trade-offs.
DeFi Primitivization

All token interactions in DeFi can be reduced to seven fundamental operations:

Token Acquisition:

• Swapping in - Converting from other assets

• Minting - Creating new tokens

Token Exit:

• Swapping out - Converting to other assets

• Burning - Permanently destroying tokens

Utility Operations:

• Collateralization - Using tokens to open perpetual futures positions or as borrowing collateral

• Lending - Providing tokens to earn yield

• Staking/Restaking - Securing networks or protocols for rewards

• Governance - Participating in protocol decision-making

• Payments - Using tokens for transactions

Every DeFi application combines these primitives in different ways. This framework enables two strategic paths:

Strategic Implementation Paths

Path 1: Protocol Integration: Enable users to interact with existing Solana protocols using encrypted tokens, maintaining privacy while accessing the full DeFi ecosystem.

Path 2: Native Application Layer: As we capture significant order flow, develop privacy-native DeFi applications:

• Privacy Perpetuals + Staking: Create an Ethena-style delta-neutral digital dollar using Solana’s infrastructure

• Private Lending + Swapping: Build a Contango-style leveraged recursive looping protocol

Both paths leverage Jupiter’s infrastructure for liquidity sourcing, order flow, and trade execution while operating within Encifher’s privacy framework.

Network Effects

This approach creates compounding benefits:

• Increased anonymity set: More users and transactions strengthen privacy for all participants

• Expanded utility: Users can perform complex financial strategies while maintaining confidentiality

• Ecosystem growth: Privacy becomes a foundational layer rather than an isolated feature

The result is a privacy-first DeFi ecosystem on Solana where confidential transactions are the default, not the exception.

Time & Cost: Jupiter Standalone vs Jupter using Encifher

1. Component-Level Benchmarks

2. Cost Structure Analysis

Privacy premium target: 0.1-0.3% depending on trade size

Future of Privacy-Preserving DEX Architecture

Moving forward, optional and composable privacy is the way

DEXes will also evolve according to this, which will make sure that they are able to serve the purpose which the users are demanding

CEXs have already started decreasing in volume, which shows that users are needing more and more solutions which are able to cater for the composability which comes with public DeFi

The path of institutions will also be something similar; they will start with something like private blockchains, but as soon as they realise that liquidity and composability guarantees are bigger than siloed systems, as they have much higher value propositions, then they will move towards chains like Solana.

The convergence of TradFi and DeFi, which is a much-talked-about topic, is something which will be facilitated when these tools become mature enough that information flowing through them becomes encrypted and secure.

DEXes will need to evolve according to this, and optional privacy will become a default

Conclusion

We present a three-layer architecture enabling privacy-preserving swaps on Jupiter through threshold ElGamal encryption, TEE-based computation, and symbolic handle abstractions. The system maintains full composability with Jupiter’s aggregation infrastructure while providing transaction confidentiality. Key technical contributions include: (1) onchain encrypted state management via symbolic handles, (2) threshold decryption integration with AWS Nitro TEEs, and (3) ephemeral account systems eliminating address-based tracking. Proof-of-concept benchmarks demonstrate around 7 second (4) execution with 0.3% privacy premiums. The architecture scales horizontally through additional TEE instances and supports batched processing for efficiency optimization. Unlike isolated privacy protocols, this approach preserves access to Jupiter’s full liquidity and routing capabilities while adding confidential execution. This work establishes a foundation for privacy-first DeFi primitives on Solana, with applications extending beyond swaps to lending, perpetuals, and complex financial strategies requiring confidential execution.

Credits:
This essay was made possible by the work done at Encifher and with the immense support and feedback of Shek (Superteam India), Yash (SendAI) and YY (Jupiter).

Socials:
Website: https://encrypt.trade/
Twitter: https://x.com/encifherio

[BAYZWISE]

Why did Jupiter exchange really need private swap for what purposes ? I always believe in open market, transparency and Decentralised system.

[team-encifher]

Hey Bayzwise,

Thanks a lot for the question. Jupiter doesn’t require private swaps but users within Solana require privacy en large. We’ve been live for over 2 months and have received a tremendous response. Mainly, small teams to manage treasury i.e. pay vendors/employees in USDC by swapping treasury currency, memecoin traders to preserve the alpha etc.

We believe in open market and decentralised system as well. However, if we are to envision global adoption of crypto and DeFi en masse; users will require privacy to hide their earnings, savings and expenses. Moreover, our system is opt-in by nature and doesn’t enforce privacy on all participants. Hence, the selection of transparency lies in the hands of the user.

[BAYZWISE]

Alright, good response.