How It Works?

The Big Picture

Here's what happens when you trade on Encifher: you deposit regular tokens, and they immediately get wrapped into encrypted versions (eTokens) using threshold ElGamal encryption. The actual encrypted data lives off-chain in a secure layer, while the blockchain only sees lightweight cryptographically binded "pointers" - ciphertext shadows capturing using execution intents.

When you want to trade, your order amounts and recipient addresses get encrypted before hitting the blockchain. Token types stay visible so Jupiter can still route your trades efficiently. A secure Co-Processor running in hardware isolated environment performs computations on the intents and facilitates solving of the order via Jupiter.

Post solving the output amount again gets wrapped by the solving entity and the final wrapped amount is sent to the owner (receiver address) this action of sending wrapped amount back to owner is not visible onchain to third parties.

How We Handle Encrypted Balances

Traditional DEXs expose every balance and transaction to anyone with a block explorer. We flip this model entirely by encrypting balances at the protocol level while keeping them execution fully programmable.

When you deposit assets, our Wrapper Program don't hold/takes custody of your tokens - it immediately encrypts them using threshold ElGamal on client end. The resulting ciphertext gets stored in a secure Data Availability layer, while the Solana blockchain only maintains pointers to the ciphertext. These aren't random identifiers; they're cryptographic references computed from the actual ciphertext.

Solana programs can operate on these pointers without ever touching plaintext values. While users can still verify their specific encrypted balances, but the amounts stay completely private. This lets us maintain full composability with other Solana protocols while solving the core privacy problem. The handles essentially act as encrypted state variables that contracts can manipulate, but the underlying values remain confidential throughout every operation.

Private Order Creation

Creating orders on Encifher looks similar to any DEX from the user side, but the privacy mechanics are quite different under the hood.

Your trading parameters - amounts, recipient addresses, slippage tolerance - all get encrypted into pointers before reaching the public blockchain. We keep token identifiers in plaintext because Jupiter's routing algorithms need to see what assets are being swapped to find optimal paths through various liquidity sources. This selective transparency gives you access to Jupiter's full routing capabilities without exposing your trading intent.

Every order runs through ephemeral accounts that exist for exactly one transaction lifecycle. No persistent identity, no address reuse, no way to link trades together. Each ephemeral account gets generated on client side and get destroyed post use, making transaction graph analysis effectively impossible.

The orders also include zero-knowledge proofs that verify you actually own the values which are valid natural numbers via range proofs all without revealing any sensitive details. Think of it as cryptographic verification that you're allowed to make this trade without anyone seeing your actual financial state.

The TEE Co-Processor Architecture

The real magic happens inside our Co-Processor, which runs in a hardware-secured environment that even privileged system processes can't access.

We're using AWS Nitro Enclaves to create isolated execution environments where encrypted computations happen safely. When encrypted orders arrive, the Co-Processor decrypts them within this secure boundary, re-encrypts values and update it onchain post that solver picks it up and executes swaps using Jupiter's exactly like you'd expect, then re-encrypts everything before sending results back. The TEE hardware isolation is just for enabling computation at scale but the key for the encrypted data lies within threshold network.

Key management uses threshold cryptography across multiple independent nodes. No single node can decrypt your balances alone - they need a quorum to authorize any computation. This distributes trust and prevents single points of failure while maintaining the performance you expect from modern DEX infrastructure.

Orders get batched together for efficiency, and the TEE processes multiple swaps in parallel while maintaining strict isolation between different users' data. The architecture scales horizontally by spinning up additional Co-Processor instances as trading volume increases.

Pointers based Execution Strategy

One major challenge with encrypted computation is latency - cryptographic operations take time, and blockchain transactions can't wait around for complex calculations to finish.

Our solution is pointer based execution. Instead of directly processing encrypted data, Solana programs work with pointers that represent the encrypted state. When you initiate a swap, the transaction completes immediately using these pointers, while the actual encrypted computation happens asynchronously in the background.

Solana programs can manipulate these pointers according to their programmed logic while the Co-Processor works on the actual encrypted computation in parallel offchain in a verifiable manner.

This separation lets the Solana Virtual Machine maintain its normal performance characteristics while encrypted operations run at their own pace. Users don't experience the latency of cryptographic computation because the blockchain layer processes state transitions immediately using pointers. The Co-Processor catches up asynchronously and publishes the resolved encrypted states when ready.

Settlement and State Updates

Settlement in Encifher works differently from traditional DEXs - there's no need to broadcast explicit transaction data because everything happens through encrypted state transitions.

After the Co-Processor executes your swap, it re-encrypts the output tokens using fresh randomness and generates new pointers reflecting your updated balances. From outside the system, observers only see opaque pointer updates with no indication of amounts, counterparties, or even whether a trade occurred.

Users can authorize encrypted balance transfers through cryptographic signatures that the Co-Processor validates and processes without exposing transaction details.

The whole process maintains cost-neutrality with public DEX trading while providing complete transaction privacy. Your trades execute at the same speed and cost as Jupiter swaps, but without revealing any sensitive information to the public ledger or other users.

Data Integrity and Verification

Keeping encrypted computations honest requires robust verification mechanisms that don't compromise privacy.

The Co-Processor processes encrypted states per block, applying compression to batches of pointers, ciphertexts, and operation data before submitting everything to our Data Availability layer. This compressed data gets a pointer reference - essentially a content-addressed identifier showing where the data lives off-chain.

We generate fixed size merkle tree for each batch processed further each batch root gets accumulated and generated a accumulated root periodically, Within merkle tree each leaf hash incorporates the pointer data, ciphertext information, operation metadata, and chain identifiers. The resulting Merkle root gets concatenated with the DA pointer and signed by the TEE using its attestation keys. This creates an end-to-end proof that the encrypted computations were performed correctly within the secure hardware.

After merkleization, the accumulated root gets appended to an on-chain ciphertext merkle tree that anyone can verify. You can cryptographically prove that any specific ciphertext stored in the DA layer was computed correctly by the TEE without revealing the underlying plaintext values.

This verification system maintains the trustless properties blockchain users expect while enabling private state transitions. The TEE's hardware attestation combined with cryptographic proofs ensures that encrypted computations are both correct and tamper-proof, even though the actual computation happens off the main blockchain.