LatticA: Confidential Coprocessor for Solana
We propose a confidential-computation coprocessor to implement Confidential Contracts on the Solana SVM.
We place a “curtain of confidential computation” over the Solana SVM. Without changing Solana’s base specifications, we apply homomorphic encryption (FHE, fully homomorphic encryption) to parts of sensitive state (State Accounts) and program logic (Program Accounts) to provide an execution environment hidden from external observers.
We, at waLLLnut, are based in the Coding and Communications Research Laboratory at Hanyang University, where we have researched and developed FHE (including FHE16) and multi-party computation (MPC).
waLLLnut is not a team that suddenly appeared with FHE. We have accumulated diverse results in lattice-based cryptography, including Overflow-detectable Floating-point Fully Homomorphic Encryption, Analysis of Error Dependencies on NewHope, and Extended Number Theoretic Transform for Lightweight Post-quantum Cryptosystem in IoT.
“We want privacy.”
Would you give up anonymity if every moment were recorded forever?
In 1993, a cypherpunk declared:
“Privacy is the power to selectively reveal oneself to the world.” – A Cypherpunk’s Manifesto
Cypherpunks and crypto-anarchists, armed with cryptography, envisioned free exchange systems that no one could track and no authority could control. Paradoxically, today’s public blockchains have become transparent ledgers where every transaction is laid bare.
Public blockchains returned asset ownership to users, but they do not provide confidentiality that lets users control whether their transaction information is published. For censorship resistance, they sacrificed confidentiality—creating a structural trade-off.
Confidentiality vs. Transparency: The Dilemma
Public chains like Solana are permissionless networks open to anyone. Their trust model is upheld by a transparent ledger and re-execution-based verification that fully exposes all transactions and state. While this transparency has fostered rich on-chain analytics platforms such as Dune Analytics, it also creates issues:
MEV front-running
Exposed orders ⇢ HFT bots pre-empt prices → unfairness
Institutional barriers
Collateral/positions & customer lists leak → biz/legal risk
Regulatory reporting
Fragmented on/off-chain data → hard to prove/audit in real time
Bottom line:
Users cannot obtain strong privacy.
Institutions hesitate to adopt public chains and instead rely on complex on/off-chain hybrids.
Our Idea: Confidential Coprocessor
We propose the Confidential Coprocessor to reconcile confidentiality with transparency. The core idea: the Solana main chain continues processing transactions at high performance with public state, while only sensitive data/logic are handled in a separate confidential Coprocessor using homomorphic computation in encrypted form.
This is not entirely new. On EVM, Zama leverages the open-source FHE framework TFHE-rs to implement the FHEVM (Fully Homomorphic Encryption Virtual Machine). FHEVM offloads complex encrypted computation to a co-processor and gateway, committing only the results back to EVM state.
Likewise, the Arcium Network implements decentralized compute orchestration atop Solana:
A single mempool architecture queues compute requests and assigns them to clusters (Arx nodes) based on priority fees and network conditions.
Solana serves as the hub for verifying the compute queue and results, with only results committed on-chain.
Our Confidential Coprocessor design draws inspiration from Zama and other FHE projects, reflecting lessons learned in the broader FHE ecosystem.
Add a confidential-computation Coprocessor to the SVM.
Focus on optimizing FHE-based, blockchain-specific confidential logic (finance, voting, tokenization).
The Confidential Coprocessor separates Solana’s ultra-fast settlement/state updates from confidential computation (statistical processing, regulatory reporting, selective disclosure), opening new privacy design space without degrading L1 performance.
Confidential DeFi: DeFi with Selective Identifiability
Confidential DeFi reinterprets the dark-pool concept on-chain: instead of blanket anonymity, it offers selective identifiability. Individual positions and strategies remain encrypted at all times, yet under regulatory/audit needs, conditional decryption lets approved entities or wallets view the necessary data. Thus protocols can hide sensitive per-position data while still exposing market-level transparency and risk controls.
For example, large LPs or institutions can keep their position sizes private, while aggregate metrics (e.g., protocol TVL or stablecoin collateral ratios) remain public on-chain. This minimizes market distortion (e.g., MEV attacks triggered by whale moves) and information leakage while enabling dark-pool-like anonymous execution on-chain.
In short, Confidential DeFi lets individuals trade privately while the market retains the transparency it needs.
Confidential Voting: Attribute-Level Statistics with Privacy
Confidential Voting aims to publish statistics by voter attributes (e.g., gender, region, age group) without revealing individual votes or identities:
Submit encrypted ballots Each voter encrypts (choice, gender, region, age group) under an FHE public key and submits. Plaintext ballots are not written directly to chain.
Aggregate under encryption FHE/MPC co-processor nodes fetch encrypted ballots from chain and compute groupwise totals without ever exposing plaintexts (e.g., “votes for Candidate A by women in their 20s”).
Commit summarized stats on-chain Only attribute-level tallies per candidate are committed to Solana L1. Individual choices remain private, while useful stats (turnout by region or age) are public.
This approach protects voter privacy while enabling policymakers and the public to access meaningful statistics.
Functional Spec: Confidential Coprocessor
From analyzing Zama, Fhenix, and other confidential compute solutions, we generalize on-chain confidential data interaction into five representative patterns. Below we illustrate using Zama’s approach as a reference.
1. Upload off-chain confidential data to on-chain
Scenario: A user inputs sensitive data into a wallet or DApp.
Flow:
The SDK encrypts locally and generates a ZKPoK (Zero-Knowledge Proof of Knowledge).
The ciphertext + proof are sent to a Gateway → recorded under an FHE key in the Zama Network, returning an attestation
(handle, inputProof).The attestation is submitted to an L1 DApp that uses Zama’s FHE library.
Examples:
Confidential DeFi: An LP encrypts sensitive position data and submits.
Confidential Voting: A voter uploads encrypted attributes alongside the vote.
2. Computation between on-chain confidential data
Scenario: Operate on ciphertexts whose plaintexts are unknown.
Flow:
An L1 function that includes FHE operations is called; an FHEVM contract defines the operation order and emits an event log.
Off-chain co-processor nodes read the event log on the Zama Network and perform ciphertext computation.
The new ciphertext handle and HCU are verified and the result is committed back to L1 state.
Examples:
Confidential DeFi: Compute stablecoin collateral ratios.
Confidential Voting: Tally per-candidate vote counts.
3. Decrypt on-chain confidential data
Scenario: Encrypted on-chain data can be revealed when needed, with three modes:
3.1 On-chain public decryption
Scenario: Reveal results publicly on L1.
Flow:
Smart contract calls
requestDecryption.Gateway → MPC-based KMS network (e.g., 9-of-13) performs decryption.
Oracle writes the plaintext back to L1 asynchronously.
Examples:
Confidential DeFi: Publish total TVL after a major liquidity event.
Confidential Voting: Publish final outcome.
3.2 Off-chain personal decryption
Scenario: A user privately checks their own data.
Flow:
User calls
userDecryptin the SDK → Gateway requests KMS decryption.KMS re-encrypts the result under the user’s public key and returns it.
The user decrypts locally with their private key.
Examples:
Confidential DeFi: A wallet queries its encrypted balance.
Confidential Voting: A voter verifies their ballot.
3.3 Off-chain broadcast retrieval
Scenario: A plaintext result needs to be delivered to many users/admins.
Flow:
Gateway requests KMS decryption; a relayer delivers the plaintext directly.
Examples:
Confidential DeFi: Admin dashboard views aggregate liquidity stats.
Confidential Voting: Election console fetches attribute-level statistics.
4. On deleting and permanently disposing on-chain confidential data
By default, confidential data should be managed via access control, not deletion. To guarantee the “right to be forgotten” (e.g., GDPR), deletion of on-chain records would be required—but this conflicts with the immutability of on-chain state.
In conclusion, the Confidential Layer preserves Solana’s performance and transparency while providing selective privacy via FHE and MPC where needed. It aims to satisfy institutional privacy/regulatory requirements and return privacy rights over on-chain activity to everyday users.
Our Roadmap: Confidential Program for SVM
Benchmarking Zama’s FHEVM approach, we plan to build a Confidential Layer tightly integrated with Solana Programs. As Zama developed an EVM auxiliary layer (FHEVM) based on the open-source FHE framework TFHE-rs, we will leverage FHE16 (a 16-bit integer FHE engine) to design an SVM-optimized confidential layer.
This layer centers on “Confidential Analytics,” allowing users to upload sensitive information in encrypted form and selectively decrypt or extract statistical data when needed.
Zama’s FHEVM lets smart contracts define triggers and execution order for homomorphic computation and ties them to an off-chain compute layer. However, this can be inefficient.
Below is a portion of a research-purpose Confidential Voting contract we wrote:
contract ConfidentialVoting is SepoliaConfig {
/// @notice Encrypted vote data structure
struct VoteCipher {
euint8 choice; // 0: approve, 1: reject
euint8 gender; // 0: undisclosed, 1: male, 2: female
euint8 age; // 0: teens, 1: 20s, 2: 30s, 3: 40s, 4: 50s, 5: 60+
euint8 region; // 0: capital region, 1: Gangwon, 2: Chungcheong, 3: Jeolla,
// 4: North Gyeongsang (Gyeongbuk), 5: South Gyeongsang (Gyeongnam),
// 6: Jeju, 7: other
address voter; // public voter address
}
/// @notice Encrypted counters for choices (approve/reject)
euint32[2] public choiceCounts;
/// @notice Encrypted counters for gender (undisclosed/male/female)
euint32[3] public genderCounts;
/// @notice Encrypted counters for age groups (teens to 60+)
euint32[6] public ageCounts;
/// @notice Encrypted counters by region (8 regions)
/// 0: capital, 1: Gangwon, 2: Chungcheong, 3: Jeolla,
/// 4: Gyeongbuk, 5: Gyeongnam, 6: Jeju, 7: other
euint32[8] public regionCounts;
...
/// @notice Conditionally update all counters based on vote validity
/// @param choice Encrypted choice
/// @param gender Encrypted gender
/// @param age Encrypted age
/// @param region Encrypted region
/// @param isValid Whether to actually count this vote
function _updateCountersConditionally(
euint8 choice,
euint8 gender,
euint8 age,
euint8 region,
ebool isValid
) internal {
// Update choice counters
for (uint256 i = 0; i < 2; i++) {
ebool isMatch = FHE.eq(choice, FHE.asEuint8(uint8(i)));
ebool shouldIncrement = FHE.and(isMatch, isValid);
euint32 increment = FHE.select(shouldIncrement, FHE.asEuint32(1), FHE.asEuint32(0));
choiceCounts[i] = FHE.add(choiceCounts[i], increment);
FHE.allow(choiceCounts[i], address(this));
}
// Update gender counters
for (uint256 i = 0; i < 3; i++) {
ebool isMatch = FHE.eq(gender, FHE.asEuint8(uint8(i)));
ebool shouldIncrement = FHE.and(isMatch, isValid);
euint32 increment = FHE.select(shouldIncrement, FHE.asEuint32(1), FHE.asEuint32(0));
genderCounts[i] = FHE.add(genderCounts[i], increment);
FHE.allow(genderCounts[i], address(this));
}
// Update age counters
for (uint256 i = 0; i < 6; i++) {
ebool isMatch = FHE.eq(age, FHE.asEuint8(uint8(i)));
ebool shouldIncrement = FHE.and(isMatch, isValid);
euint32 increment = FHE.select(shouldIncrement, FHE.asEuint32(1), FHE.asEuint32(0));
ageCounts[i] = FHE.add(ageCounts[i], increment);
FHE.allow(ageCounts[i], address(this));
}
// Update region counters (optimized loop)
for (uint256 i = 0; i < 8; i++) {
ebool isMatch = FHE.eq(region, FHE.asEuint8(uint8(i)));
ebool shouldIncrement = FHE.and(isMatch, isValid);
euint32 increment = FHE.select(shouldIncrement, FHE.asEuint32(1), FHE.asEuint32(0));
regionCounts[i] = FHE.add(regionCounts[i], increment);
FHE.allow(regionCounts[i], address(this));
}
}
/// @notice Reveal voting results — callable ONCE by anyone after voting ends
/// @dev Initiates decryption oracle for choice counts only
function requestReveal() external onlyAfterEnd {
require(!choiceRevealed, "Choice results already revealed");
require(!choiceRequested, "Choice reveal already requested"); // prevent duplicates
// Prepare ciphertexts for decryption (choice counts only)
bytes32;
cts[0] = FHE.toBytes32(choiceCounts[0]); // approve count
cts[1] = FHE.toBytes32(choiceCounts[1]); // reject count
// Request decryption from oracle
uint256 requestId = FHE.requestDecryption(cts, this.revealChoiceResults.selector);
requestIds["choice"] = requestId;
choiceRequested = true;
emit RevealRequested("choice", requestId);
}
As the code shows, adding confidentiality to portions of the L1 EVM logic entails defining FHE operation order via on-chain handles, performing follow-up computation in an off-chain co-processor, and reflecting the result back on-chain via an oracle. To process confidential statistics, every branch/loop must be concealed under homomorphic operations, producing an inefficient pattern that touches all confidential state slots. This stems from the layered separation between EVM execution and FHE computation and is also necessary to prevent inferring confidential state from execution traces.
Moreover, because confidential computation and access control occur at the smart-contract level, developer mistakes or misconfigured permissions can compromise confidentiality.
We plan to improve on these FHEVM limitations, aiming for a demo that visualizes anonymized statistics (e.g., Confidential Voting) on Dune from Solana L1, extracting meaningful insights while minimizing disclosure.
FHE16 vs. TFHE-rs Performance, and FHE-based MPC vs. Fhenix Threshold Decryption (Summary)
1. Gate-based FHE16 vs. TFHE-rs
Gate op latency
~3.8 ms
~13 ms
Evaluation key
≤ ~14 MB; compact via 16-bit integer design
~55 MB; larger by TFHE design
Outlook 1: sub-2.5 ms homomorphic ops expected in the next iteration.
Outlook 2: TFHE-rs is floating-point-oriented, while FHE16 is 16-bit integer-based; hardware acceleration is likely to widen the performance gap in favor of FHE16.
2. Arithmetic performance:
3. FHE16-based MPC vs. Fhenix
Coming soon (Eurocrypt 2026 paper in parallel; planned public release in October)
Companies Building on TFHE-rs: Funding & Tech Snapshot
Funding: ≈ $150M raised to date
Role: Open-source FHE frameworks (TFHE-rs, FHEVM) and on-chain confidentiality
Vision: Make on-chain privacy standard; 100× performance; dedicated hardware
Tech: TFHE-rs (gate-level FHE library) and FHEVM
Funding: ≈ $22M
Role: FHE-based, EVM-compatible Layer-2 enabling confidential dApps
Vision: Establish on-chain privacy and expand via FHE co-processors
Tech: FHE-based MPC with fast 3-round threshold decryption; L2 support
Funding: ≈ $30M
Role: FPGA-based FHE accelerator hardware (Enable chip)
Vision: Practical-speed FHE to transform blockchain/cloud security paradigms
Tech: High-speed FPGA based on TFHE-rs
Funding: ≈ $115M
Role: ASICs for FHE acceleration and blockchain security processors
Vision: Next-gen secure computing via (likely TFHE-rs-aligned) FHE acceleration
Tech: TFHE-style accelerator (inferred)
Q&A
Why FHE instead of ZK?
FHE (Fully Homomorphic Encryption) allows complex logic, including branching and conditional statements, to be executed directly in encrypted form, thereby granting native confidentiality to smart contract computations. This enables developers to write and run partial statistical logic on-chain as-is, within an “encrypted execution space”—which is the core value we emphasize. Furthermore, FHE technology is advancing rapidly, and we expect it to become increasingly competitive in terms of performance.
Aren’t there already projects implementing Confidential Contracts on Solana?
Yes, Arcium is one such project. However, our focus is on Solana-specific use cases leveraging FHE, such as statistical reporting and confidential voting, which are tightly coupled to blockchain-native requirements. We plan to provide a detailed comparison with Arcium in the future.
Is this truly decentralized—or just a centralized server layered on top of Solana?
The design goal of the Confidential Coprocessor is to avoid reliance on centralized servers and instead extend Solana’s trust model through cryptographic guarantees (MPC/FHE) and distributed consensus structures. For example, Zama’s FHE co-processor operates under a 51% honest majority assumption, its KMS under a 2/3 honest assumption, and Fhenix leverages an Optimistic Rollup model to achieve decentralized trust. Following these precedents, we are designing our own optimal distributed network architecture.
Conclusion: New Possibilities Through Privacy
The privacy dilemma facing today’s blockchain industry is the challenge of “how to safeguard personal and corporate confidentiality within decentralized networks.” Confidential Coprocessor for Solana is our answer to that question.
By preserving the advantages of a high-speed L1 blockchain while applying cutting-edge cryptography only where confidentiality is needed, this approach opens up new opportunities across domains ranging from DeFi and governance to healthcare and public data.
We will continue to closely follow the development of ZK and FHE technologies and strive to pioneer the practical realization of on-chain privacy. In the near future, we plan to release a prototype demo that demonstrates on-chain statistics integrated with Dune dashboards in action.
Through this, we aim to prove the feasibility of a new paradigm: a “privacy-preserving public blockchain.” Looking ahead, we hope to establish Confidential Coprocessor as a solid foundation within the Solana ecosystem, enabling a Web3 world where everyone can participate with confidence and peace of mind.
Last updated