Deterministic FHE16

Deterministic Privacy as a Default

We are implementing a deterministic confidential computation coprocessor that provides on-chain privacy as the default on top of the Solana SVM ecosystem.

This coprocessor ensures that transactions, sensitive state data, and even public statistics can be computed and verified entirely in encrypted form, removing the structural information asymmetry that enables MEV extraction and achieving privacy, fairness, and regulatory compliance simultaneously on public blockchains.

In areas such as finance, governance, data marketplaces, and AI analytics, it delivers a new execution environment that preserves the speed and transparency of existing L1s, while ensuring that no transaction is pre-exposed and results are revealed only selectively, when and how policy allows.

The Reality of High-Performance L1s and User Needs

High-performance L1s (Big Blockchains) like Solana already handle large-scale real-world usage. However, what users and institutions ultimately seek is not faster settlement, but privacy and fairness.

Question: What changes when we add deterministic confidential computation on top of Solana?

Limits of MEV Extraction and Distribution Models

“The essence of MEV is not merely a speed race, but information asymmetry.”

Currently, Ethereum’s PBS, Solana’s Jito, and Arbitrum’s sequencer auctions intentionally insert an auction wait window—transactions are buffered rather than included immediately, adding artificial latency.

While this design is presented as an attempt to improve market efficiency, from the user’s perspective it artificially extends the pre-exposure window, leading to side effects:

Searchers and builders gain extra time to analyze and simulate transactions
More sophisticated front-running, sandwiching, and backrunning strategies can be executed
The total amount of MEV does not decrease—in fact, the intensity and frequency of harm increase

While MEV revenue distribution can be optimized, the mitigation of user harm remains limited.

If this structural imbalance—where transaction contents are pre-exposed to only a select few—is not resolved, no distribution model can fundamentally secure fairness.

Evaluation of Existing Fairness Models

Type

Strengths

Structural Limitations

① Dark Pool / ② Encrypted Mempool

Strong privacy

Reduced transaction transparency, reliance on operators/key managers (SPOF), lack of redistribution model

③ FCFS

Simple and predictable ordering

MEV monopolized by ultra-low-latency infra owners, accessibility gap

④ Auction Based Ordering / ⑤ Priority Ordering

Mitigates latency arms race

Harms shifted onto users

⑥ App Specific Sequencing / ⑦ Intent-based Market

Allows MEV defense and internal redistribution at the app level

Leads to ecosystem fragmentation, potential for cross-chain MEV

⑧ Protocol Revenue Sharing

Satisfies redistribution demands

Complex design and governance, requires chain-wide consensus

Dark pools (1) and encrypted mempools (2), designed to mitigate MEV, create single points of failure (SPOFs) and impose trust risks due to reliance on centralized operators.

FCFS (3) results in MEV monopolization by ultra-low-latency infrastructure owners. Auction Based Ordering (4) and Priority Ordering (5) attempt to counterbalance this but instead create artificial latency environments, shifting harm onto users.

App-Specific Sequencing (6) and Intent-based Markets (7) allow for MEV defense and internal redistribution at the application level, but ultimately lead to ecosystem fragmentation and cross-chain MEV risks.

While these existing approaches each have strengths, they all share a common flaw: they fail to eliminate information asymmetry and leave other side effects behind.
The Confidential Coprocessor aims to fundamentally remove this structural imbalance by ensuring that transactions remain encrypted not only until block inclusion, but also until the policy-driven reveal point, thereby blocking pre-exposure entirely.

Deterministic Confidential Coprocessor -Architecture (Draft)

Solana L1 Ordering + Deterministic Confidential Coprocessor

This architecture abstracts how the Confidential Coprocessor preserves Solana L1’s ordering while deterministically executing the FHE logic of each transaction in the block in the same sequence.

Separation of Consensus · Execution · Reveal:

Consensus phase: Block inclusion is finalized in real time without FHE computation.
Execution phase: Computation may be carried out immediately after inclusion, or deferred until just before the reveal window (lazy execution).
Reveal phase: Results are disclosed selectively, with the timing and scope determined by policy.

In this design, transaction outcomes are already fixed at the point of Solana L1 consensus, while deferred execution allows for strategic reveals aligned with resource optimization, regulatory requirements, or service-specific strategies.

Key Components

Deterministic FHE16 Computation

Fully Homomorphic Encryption (FHE) specialized for 16-bit integers
PRF-based randomness ensures full determinism, independent of hardware or environment
With the same inputs and ordering, anyone worldwide can re-compute and verify results
No FHE required during L1 consensus → real-time performance preserved
Selective encryption supported → only necessary data encrypted for efficiency and cost optimization

MPC-KMS Decryption (Under Discussion)

Enables policy-driven, selective disclosure
Applications and protocols can directly design when and what to reveal

Operating Principle

L1 finalizes a log: (function_id, input_handles, order)
Confidential Layer executes FHE16 computation, producing an encrypted state root → outcome fixed
Disclosure timing and scope are determined through MPC network consensus

Confidential Layer’s Reveal Phase and Redesign of the Timing Game

Source: Frontier Research

In traditional Web3, MEV competition unfolds across four stages: Trigger → Tick-to-Trade → Propagation → Inclusion. In current L1/L2 structures, even with private routing, plaintext transaction flows are exposed almost in real time to key participants, making success dependent on who can observe, compute, and transmit the fastest.

The Confidential Layer shifts the starting point of this competition to the KMS (MPC) reveal phase.

From the moment a transaction is included in a block until just before settlement, the state transition path is cryptographically fixed, and none of its contents are observable from outside.

Trigger Latency: Transactions are queued as ciphertext, eliminating any advantage from early detection.
Tick-to-Trade: Computation is performed deterministically between ciphertexts (FHE16), preventing advantages from pre-simulation.
Propagation: The pre-inclusion phase is completely hidden, removing biases from network propagation.
Supply Chain: Slot-start timing races disappear, with short and fair competition concentrated at the reveal moment.

This structure provides especially strong protection in the DeFi domain:

Large positions or complex strategies can be executed instantly without prior exposure
Only essential metrics (e.g., TVL, collateral ratios) can be selectively disclosed
Good-MEV (liquidity provision, liquidation incentives, etc.) can be directly designed and allocated by the application

As a result, malicious MEV such as sandwiching and backrunning is structurally blocked, while Good-MEV can be controlled and redistributed in line with each application’s policies.

The Confidential Layer goes beyond simply suppressing MEV; it provides an environment where MEV revenue can be designed and redistributed at the application level.

App-specific design of the reveal window
- Example: A DeFi app may introduce a 500ms delayed reveal to create opportunities for Good-MEV, while an NFT marketplace may choose immediate reveal to maximize fairness.
App-driven allocation of Good-MEV revenue
- Policies can be designed for purposes such as DAO treasury funding, user rebates, or validator partnership incentives.
Compatibility with existing MEV infrastructure
- The builder–relay structure remains intact, but the starting point of competition shifts to the KMS/MPC reveal phase, ensuring all participants compete under the same informational conditions.

The goal is not to “eliminate MEV competition,” but to shift the starting line and rules of competition into the hands of applications.

Value by Stakeholder

Stakeholder

Core Value

Enterprises / Service Operators

Maintain L1 + create new revenue models based on reveal policies

dApp Developers

Suppress malicious MEV + integrate Good-MEV into tokenomics

End Users

Reduced exposure to front-running and sandwich attacks, selective transparency

Infrastructure Providers

Reuse existing low-latency infrastructure for reveal-phase competition