READ TIME: 15MIN
THE HOLY GRAIL OF ENCRYPTION

What Is Fully Homomorphic Encryption (FHE)? How Fhenix Brings It to Ethereum and other EVM chains

Ethereum
transparency
public data
The Transparency Problem
Ethereum promised financial freedom — but delivered radical transparency. Every trade, wallet balance, and position is fully visible to anyone: users, competitors, attackers. This isn’t a flaw. It’s the core architecture of public blockchains.
FHE
privacy
encrypted computation
A New Primitive: FHE
Fully Homomorphic Encryption (FHE) introduces a new model. Data remains encrypted at all times — during input, computation, and output. No exposure. No decryption. Only the owner can access the result.
encrypted input
secure processing
private output
How FHE Works
  • Input → encrypted
  • Computation → performed on encrypted data
  • Output → stays encrypted.
 The system never reveals raw data at any stage.
CoFHE
Ethereum
infrastructure
Fhenix & CoFHE Infrastructure
Fhenix is bringing FHE to Ethereum and EVM chains. With its CoFHE coprocessor and research, it enables private smart contracts and encrypted on-chain computation. This unlocks a new class of applications where privacy is native — not an afterthought.
Guy Zyskind
"Privacy isn't a feature. It's infrastructure. It's the foundation of trust. The key to making DeFi work for everyone."
Guy Zyskind, Founder of Fhenix

Key Takeaways:

FHE (Fully Homomorphic Encryption) lets you compute on encrypted data without ever decrypting it.
On Ethereum, FHE enables encrypted smart contracts where state and intermediate values remain encrypted during execution.
CoFHE (Fhenix's coprocessor) provides an EVM-compatible path to build confidential apps without migrating to a separate privacy chain.
Wallets stay standard (MetaMask, Ledger, Rabby) - dApps integrate @cofhe/sdk client-side to encrypt calldata and decrypt outputs locally.
Selective transparency is possible via threshold decryption - publish solvency proofs or proof-of-reserves without exposing individual positions.
Use FHE when you need encrypted state over time (lending, AMMs, auctions, identity, AI). Use ZK when you need to prove statements succinctly.
Developer docs: CoFHE Overview · Solidity API · Quick Start

What Is Fully Homomorphic Encryption (FHE)?

FHE is a form of encryption that permits arbitrary computation to be performed directly on ciphertexts. The result of that computation, when decrypted, matches the result that would have been obtained by performing the same computation on the plaintext. At no point does the processor - whether a server, a smart contract, or an MPC network - see the underlying data.
The concept was first proven practically possible by Craig Gentry in his 2009 PhD thesis at Stanford. Gentry showed that a cryptographic scheme built on ideal lattices could support both addition and multiplication on ciphertexts - the two operations sufficient to compute any function. Before Gentry, FHE was considered theoretically possible but practically unreachable. His construction proved otherwise.
Today, three main families of FHE schemes are in use:
BGV / BFV - optimized for integer arithmetic; used in financial and statistical applications.
CKKS - supports approximate arithmetic on real numbers; best suited for machine learning and data analytics.
TFHE / FHEW - operates bit by bit; enables fast bootstrapping and arbitrary function evaluation; the scheme family most relevant for smart contract execution.
All three are built on lattice-based mathematics. Lattice problems are currently believed to be hard for both classical and quantum computers - which gives FHE a property no other encryption approach in production today shares: it is post-quantum secure by construction.

A Brief History

Homomorphic encryption was first proposed in 1978 by Rivest, Adleman, and Dertouzos — but for three decades it remained out of reach. Most cryptographers considered it impossible. The breakthrough came in 2009, when Craig Gentry constructed the first practical FHE scheme in his Stanford PhD thesis, proving the idea was achievable. A 2013 paper that sidestepped FHE's costly relinearization step brought the scheme closer to viability. Fhenix's 2025 research — DBFV and the CCS 2025 threshold decryption protocol — is the production-scale chapter of this same arc.

How FHE Works?

The Locked Boxes Analogy:
Alice and Bob have locked boxes with two balls each. Alice wants to move two balls to Bob — without anyone seeing the contents.
They hand them to a sorcerer who has no key and doesn’t know the boxes contents. 
The sorcerer is using his magic powers to transfer the balls from one box to another. No seal is ever broken.
He returns the locked boxes to Alice and Bob.
Alice & Bob can always open their boxes. Bob will have 4 balls and Alice will have none.
Only Alice can see the content of her box and only Bob can see the content of his box.
CoFHE is the sorcerer.
FHE is the magic that never exposes its data.
Fhenix brings the magic to Ethereum and every EVM chain.

FHE vs. the Alternatives

FHE is a form of encryption that permits arbitrary computation to be performed directly on ciphertexts. The result of that computation, when decrypted, matches the result that would have been obtained by performing the same computation on the plaintext. At no point does the processor - whether a server, a smart contract, or an MPC network - see the underlying data.
Property
FHE
ZK Proofs
TEE
MPC
Hides inputs from the executor
Yes
No. The prover sees all inputs
Depends on hardware trust
Partial - coordination reveals shares
Post-quantum secure
Yes. Lattice-based
No. Elliptic curve (quantum-breakable)
No. Attestation and key sealing are ECC-based
Depends on underlying primitives
No trusted hardware required
Yes
Yes
No. Requires Intel, AMD, or AWS enclave
Yes
Full EVM composability
Yes
Partial  proofs can't express all state
Partial
Limited
Arbitrary smart contract logic
Yes
Limited to provable claims
Yes (but hardware-dependent)
Limited communication overhead grows with complexity
Comparison table
FHE vs ZK proofs. Zero-knowledge proofs verify that a computation was done correctly, but the prover still sees all inputs. FHE eliminates that exposure — computation happens directly on encrypted data.
FHE vs TEEs. Trusted execution environments (Intel TDX, AMD SEV) provide hardware-enforced isolation — but they require trusting the hardware vendor, are subject to side-channel attacks, and create institutional compliance concerns. As Guy Zyskind notes: "TEEs introduce hardware trust assumptions that institutional compliance teams struggle to accept. FHE provides mathematical certainty."
FHE vs MPC. Multi-party computation distributes computation across parties so no single party holds full data — but requires ongoing coordination, scales poorly with complexity, and doesn't natively support arbitrary smart contract logic.

FHE and Post-Quantum Security

FHE is built on lattice mathematics - specifically, Learning With Errors (LWE) and Ring-LWE constructions. These are the same mathematical foundations as NIST's selected post-quantum cryptographic algorithms:
Kyber (FIPS 203 / ML-KEM) - NIST's primary standard for post-quantum key exchange
Dilithium (FIPS 204 / ML-DSA) - NIST's primary standard for post-quantum digital signatures
Professor Chris Peikert, a member of Fhenix Research and co-author of Fhenix's CCS 2025 paper, contributed directly to both Kyber and Dilithium - the cryptographic standards now being adopted by governments, financial institutions, and infrastructure providers worldwide. Building on FHE today means building on the same mathematics that NIST has certified as post-quantum secure.

The Retroactive Decryption Trap

Upgrading to post-quantum cryptography in the future can stop new attacks. It cannot protect historical data. Any transaction encrypted with elliptic curve cryptography today - including ZK-based privacy transactions - is stored permanently on a public blockchain. A sufficiently powerful quantum computer could collect that ciphertext now and decrypt it later.
This creates a fundamental risk for privacy protocols built on ZK or ECC-based schemes.
Guy Zyskind
"All the encrypted data that's already on-chain, all the transactions that were supposed to be private - a quantum adversary might be able to decrypt those. So even after you upgrade, users may have their privacy permanently compromised."
Guy Zyskind, Founder of Fhenix
Google's March 2026 PQC (Post Quantum Cryptography) identified 2029 as the migration deadline - the point by which a cryptographically relevant quantum computer could achieve meaningful attack rates against current cryptographic standards. Zyskind characterized the traditional 10-year migration window as now "dangerously optimistic."
FHE avoids the retroactive decryption trap because its lattice-based encryption is already quantum-resistant. Data encrypted with FHE today remains private even in the post-quantum era.
As Zyskind stated in Bitcoin News: "While we do that, we might as well start encrypting mempools with PQC encryption and, ideally, with fully homomorphic encryption. Encrypted mempools solve a bunch of other problems: front-running, MEV extraction and transaction privacy."

How Fhenix Implements FHE:  The CoFHE Coprocessor

Fhenix's implementation of FHE for Ethereum is called CoFHE - the FHE Coprocessor. Rather than requiring a dedicated Layer 2 chain or modifications to Ethereum's base layer, CoFHE operates as a modular off-chain execution layer that any EVM-compatible blockchain can plug into.
Integration requires a single Solidity import:
import "@fhenixprotocol/cofhe-contracts/FHE.sol";
That import gives smart contracts access to encrypted integer types -
euint8
,
euint16
,
euint32
,
euint64
,
euint128
,
euint256
,
ebool
and
eaddress
- that work inside standard Solidity. Arithmetic operations (addition, multiplication, comparison) execute directly on ciphertexts. Results remain encrypted until a user with explicit permission calls for decryption.
Guy Itzhaki
"The vision of confidential rollups lives on - now as a universal coprocessor that scales privacy across Ethereum instead of creating yet another L2."
Guy Itzhaki, CEO of Fhenix

The Three-Layer Architecture

CoFHE operates across three layers - each isolating a distinct trust boundary:
01
On-Chain EVM
Smart contracts submit encrypted operation requests via FHE.sol. Contracts never handle plaintext values — encrypted state is represented by handles referencing off-chain ciphertexts. Access is controlled through an on-chain permission system.
FHE.allowSender()
FHE.allowThis()
FHE.allowAccount()
02
Off-Chain
Coprocessor
A queue-driven execution pipeline processes encrypted operations asynchronously. Operations are batched for efficiency; the pipeline is horizontally scalable. Each operation follows a deterministic lifecycle:
submitted
validated
queued
executing
completed
published
03
Threshold
Decryption (MPC)
Decryption key shares are distributed across independent nodes using multi-party computation — no single node can decrypt unilaterally. Decryption is triggered only by on-chain permission grants. Off-chain decryption is also supported via a permit-based authentication system with identical MPC security guarantees.

Threat Model and Trust Assumptions

Understanding what FHE protects - and what it does not - is essential for building correctly and for evaluating competing privacy claims. This section is intentionally direct about both.

What FHE protects (in the encrypted smart contract model)

Sensitive inputs - amounts, thresholds, bids, and risk parameters submitted in transactions remain encrypted; the CoFHE network processes ciphertexts without ever seeing plaintext values
Sensitive state - balances, collateral, debt, and internal accounting stored in contract storage remain encrypted at rest and during execution
Intermediate computation values - all arithmetic and logic executes on ciphertexts; even CoFHE nodes never observe plaintext data during processing

What FHE does NOT automatically protect

On-chain metadata - sender addresses, transaction timing, gas usage patterns, and contract interaction footprints remain publicly observable on any transparent blockchain
Behavioral access patterns - which pools you interact with, how frequently, and what sequence of operations you perform can reveal intent even when values are encrypted
Public parameters - pool IDs, token pairs, oracle prices, and non-sensitive identifiers often remain public by design; not everything in a contract should or needs to be encrypted
For sender-level and orderflow privacy, teams pair encrypted execution with private transaction routing and private mempools to reduce mempool-level leakage. FHE addresses the computation layer; metadata privacy requires additional layers.

Threshold decryption trust assumptions

When threshold decryption is used for selective disclosure - publishing solvency proofs, aggregate statistics, or predicate results - the security guarantee depends on fewer than T parties colluding, key management and liveness assumptions holding, and results being revealed only when the application explicitly requires it. At Stage 2, a blocking quorum of N−T+1 independent operators can halt decryption unilaterally - making unauthorized decryption by any single party cryptographically infeasible. See the Privacy Stages Framework section below.

Fhenix's Research Stack: Two Papers, One Coherent Foundation

Deploying FHE in production requires solving two distinct problems: arithmetic that scales, and decryption that scales. Fhenix has published two complementary research papers that address each. Together they form the cryptographic foundation of CoFHE.

Paper 1 - DBFV: Making Exact Encrypted Arithmetic Practical (ePrint 2025/2321)

Standard FHE schemes like BFV and BGV support exact arithmetic - no approximation errors, which is essential for financial logic where rounding is unacceptable. The problem is that cost scales badly with plaintext precision: as integers get larger, the noise budget tightens, forcing either shallow circuits or frequent, expensive bootstrapping operations. This made large-integer exact FHE unsustainable for real workloads.
Fhenix's DBFV paper - "High-Precision Exact FHE Made Simple, General, and Fast" (ePrint 2025/2321) - introduces Decomposed BFV: rather than encrypting a large integer as a single ciphertext, DBFV decomposes it into multiple smaller BFV ciphertexts, called limbs, each representing part of the value. This restructures how computation cost scales:
Extended multiplication depth - circuits run deeper before bootstrapping is required
Amortized bootstrapping - each bootstrap covers substantially more useful computation
Throughput mode via packing - many values computed in parallel in a single ciphertext, analogous to vectorized execution; this mode is unavailable in TFHE
DBFV and TFHE are complementary: TFHE handles boolean circuits and shallow logic; DBFV handles deep arithmetic for financial workloads - balances, collateral ratios, interest rates and settlement logic. Together they cover the full spectrum of confidential smart contract computation.
"Exact encrypted computation is no longer dead on arrival at scale. DBFV rewires how precision, noise, and circuit depth interact - it opens design space that was basically closed for exact schemes."
Fhenix Research Team, ePrint 2025/2321
Deployment status: DBFV is currently under development and not yet deployed in production. Fhenix aims to deploy DBFV in 2026 (timeline subject to change).
Full paper: eprint.iacr.org/2025/2321
Read more on our DBFV blog

Paper 2 - Threshold Decryption at Scale: CCS 2025 (ePrint 2025/1781)

The second problem is decryption: in a multi-party system, distributing decryption across multiple nodes without catastrophic performance loss had been an open problem. Prior approaches relied on noise flooding - artificially inflating cryptographic parameters to mask decryption shares - which imposed severe throughput and latency penalties.
Fhenix's research team, led by Guy Zyskind and Professor Chris Peikert, developed a protocol based on MPC-based rounding that eliminates noise flooding entirely. The protocol was accepted as a Distinguished Paper at ACM CCS 2025 - one of the most selective venues in applied cryptography, publishing alongside research from Microsoft, Google, Meta, Stanford, and MIT.
Full paper: eprint.iacr.org/2025/2321
The empirical benchmarks from the paper establish that threshold FHE decryption can scale to real-world application demands. Measured in the online phase with 4 parties at 1ms network latency, against prior state-of-the-art:
Prior state-of-the-art: 3.18 decryptions per second at 315.6ms per operation
Fhenix protocol: 64,319 decryptions per second at 8.48ms per operation
Measured improvement: approximately 20,000× higher throughput, approximately 37× lower latency
These benchmarks demonstrate that the cryptographic scalability barrier to production encrypted smart contracts can be overcome. A production encrypted token application with 1,000 users checking 10-100 balances simultaneously requires 10,000-100,000 decryption operations per second. Prior threshold FHE approaches were capped at a few per second.
"Until now, builders had to choose between privacy and usability. Fhenix's work closes that gap. It turns FHE from a research curiosity into infrastructure that can underpin the next evolution of finance."
Fhenix CCS 2025 announcement

Cost and Throughput: What This Research Changes

The cost and throughput of FHE-based applications depend on three things: which encryption scheme is used, which architecture deploys it, and which protocol generation handles decryption. Aggregate claims about "FHE cost" that ignore these distinctions are misleading. Here is what Fhenix's research changes.
Throughput ceiling. The CCS 2025 protocol delivers 64,319 decryptions per second at 8.48ms per operation — approximately 20,000× the prior state-of-the-art (3.18 decryptions/sec at 315.6ms). Performance numbers in public sources that predate this work are no longer the ceiling.
Per-operation cost. DBFV's amortized bootstrapping and throughput-mode packing reduce per-operation overhead at the scheme layer, compounding the protocol-layer gains from CCS 2025. That said: encrypted operations remain more compute-intensive than plaintext operations in absolute terms. Builders evaluating CoFHE for high-frequency workloads should benchmark their specific use case rather than extrapolate from generic FHE cost narratives.

Limitations and Tradeoffs

FHE is a powerful primitive - it also comes with real tradeoffs every builder should understand before committing to it.

Practical constraints today

Compute overhead vs. plaintext EVM - encrypted operations are significantly more compute-intensive than plaintext equivalents; this affects gas costs and processing time for complex logic
Ciphertext size inflation - encrypted values are substantially larger than plaintext, increasing storage and bandwidth requirements relative to standard contracts
Supported operation types - encryption-friendly operations (integer arithmetic, comparisons, conditional selections) are well supported; complex branching on encrypted values and dynamic data structures require careful circuit design
Developer ergonomics - debugging encrypted state requires specialized tooling; standard Solidity debugging assumptions (readable state, console.log) do not apply to ciphertext values
Metadata is not covered - FHE secures computation, not the observable transaction layer; sender addresses, timing, and gas patterns remain visible and require separate treatment

Where ZK is still the better fit

Succinct verification of computation correctness - ZK proofs are far more compact and efficient for attestation and compliance use cases where proof size matters
Proving statements efficiently without encrypted execution - compliance predicates, correctness proofs, and rollup validity proofs are ZK's native domain
Environments already designed around circuit-based computation with primarily proof-generation needs rather than persistent encrypted state
FHE and ZK are not competing approaches - they are complementary. ZK proves that a computation was done correctly; FHE ensures the computation stays private while executing. Mature privacy architectures will often combine both

Privacy Stages: A Framework for Evaluating Blockchain Privacy

Not all privacy solutions are equal. Guy Zyskind proposed a taxonomy of blockchain privacy analogous to L2Beat's rollup stages — asking "who can decrypt your data?" rather than "who can steal your funds?"
The model is T-out-of-N: T = colluding parties needed to break privacy, N = total operators. A blocking quorum of N − T + 1 can halt decryption independently.
Stage
Construction
Practical privacy
0
TEE-only
T = 1 — a single enclave breach exposes data
1
FHE/MPC with no blocking quorum
Cryptographic, but trust concentrated
2
2FHE/MPC + independent blocking quorum
Mature privacy infrastructure (practical gold standard)
Aleph
Indistinguishable Obfuscation (iO)
Theoretical north star — no practical construction yet
Guy Zyskind
"If rollup stages ask who can steal your funds, privacy stages ask who can decrypt your data."
Guy Zyskind, Founder of Fhenix

Confidentiality vs. Anonymity:

Why Ethereum Needs Both

Confidentiality and anonymity are distinct properties - and blockchain privacy requires both.
Confidentiality hides what you are doing: transaction amounts, token types, trading strategies, lending positions. FHE provides confidentiality at the computation layer - values are encrypted and never exposed during processing.

Anonymity hides who you are: wallet addresses, identity linkability across transactions. Ethereum's account model is stateful and inherently linkable - every interaction traces back to a persistent address. Bitcoin's UTXO model, by contrast, enables each output to be shielded independently.

As Guy Zyskind explains: "Anonymity is the Achilles' heel of Ethereum's privacy stack." Providing confidentiality alone leaves users exposed to address-level tracking. Full privacy requires encrypted execution (FHE) combined with address-layer protections - encrypted addresses, FHE-ZK hybrid approaches, and privacy-preserving RPC layers.

What You Can Build with FHE on Ethereum

01

Confidential DeFi

Encrypted trading, lending, auctions, and stablecoins — private by default, without leaving the EVM.
+ icon- icon
  • MEV protection and front-running prevention — trading positions, slippage tolerances, and order sizes stay encrypted until execution.
  • Sealed-bid auctions and dark pools — bids stay hidden until settlement, enabling fair price discovery.
  • Private lending markets — encrypted credit and reputation scores enable under-collateralized lending without exposing user data.
  • Shielded stablecoins — the same token operates in public ERC-20 and encrypted modes, with no wrapping or liquidity fragmentation.
02

Institutional And Enterprise

GDPR and MiCA-compliant on-chain data handling.
+ icon- icon
Private treasury management with selective disclosure - private from public observers, auditable by authorized parties. Encrypted payroll, healthcare data, and supply chain logistics on public blockchains.
See our Access Delegation demo - shield a token balance and securely share an access permit with a verifier, without exposing the underlying value.
Access Delegation
03

Private Payments For The Agentic Internet

The x402 HTTP payment standard enables AI agents to make micropayments - but every payment is a public blockchain transaction, creating correlatable surveillance trails.
+ icon- icon
FHE-encrypted payments (FHERC20) allow payment amounts and recipient identities to remain encrypted. As Guy Itzhaki demonstrates: two transactions of $0.10 and $4.02 are indistinguishable on a block explorer when processed through CoFHE. "The future of payments is private, programmable, and permissionless."
read about private x402 micropayments
04

AI And On-Chain Inference

Run AI on encrypted inputs — the provider never sees the query, the user never sees the model.
+ icon- icon
Confidential AI agents can process sensitive data on-chain while maintaining privacy and compliance. Private on-chain inference lets model providers compute on encrypted user inputs — the provider never sees the query; the user never sees the model weights.

High-Demand Use Cases: Confidential DeFi Primitives

Every DeFi vertical faces the same core problem: readable state is required for verification but creates an attack surface. FHE solves this structurally - the contract computes on encrypted state without exposing it. The patterns below span the DeFi stack and reflect recurring requests from protocol designers building on encrypted execution.
01

Lending And Liquidation

Lending protocols have some of the most acute privacy needs in DeFi - collateral positions, debt balances, and Health Factors are all live targets for MEV bots when they are public.
+ icon- icon
Per-account collateral and debt balances. Transparent balances create a public hit-list of accounts near liquidation. Encrypting them removes this information advantage while still allowing verifiers to confirm solvency via predicates against public oracle prices - "Health Factor ≥ 1" - without exposing raw figures.

Health Factor and liquidation status. Exact Health Factor values give precision-targeting information to bots. Binary proofs ("HF ≥ 1" / "HF < 1") preserve correct eligibility logic while removing the numerical precision that enables strategic manipulation.

Sealed liquidation bids. Visible bids get copied or front-run.
Sealed bids - combined with commit-reveal or builder-routed bundles - give bidders privacy while preserving fair competition. Dutch auctions replace speed races with genuine price discovery. See our Private Auction demo - submit sealed bids onchain to preserve privacy and prevent bid exposure.

User rescue orderflow. Topping up collateral or repaying debt to repair a Health Factor signals vulnerability. Routing these transactions privately prevents attackers from exploiting the signal before the repair completes.

Collateral composition and liquidation queue state. Knowing that collateral includes a thin LP or ERC-4626 asset lets attackers target that market. Encrypting composition - revealing only basket-level constraint proofs - raises attacker cost. Encrypting queue timing eliminates last-block sniping while Dutch auctions preserve fair price discovery.
02

Payments

Public blockchains make every payment observable: counterparty, amount, timing, and token type are all visible. FHE enables shielded payment amounts on standard EVM infrastructure without requiring a dedicated privacy chain.
+ icon- icon
Shielded stablecoin transfers. The sender, receiver, and amount can be encrypted end-to-end. Compliance predicates - "amount ≤ reporting threshold" or "sender is KYC-verified" - can be evaluated on encrypted values without revealing the underlying transaction. This is the architecture behind Fhenix's dual-mode stablecoin concept: public or shielded on demand, composable with existing DeFi rails.

Stablecoin demos. Redact demo - shield and un-shield any ERC-20 token to keep balances and transactions private. Private Stablecoin demo - a native shielded stablecoin designed as a core primitive for DeFi and TradFi. Dual Mode Stablecoin demo - issue a stablecoin that supports both shielded and public transaction modes.

x402 micropayments for AI agents. AI agents settling per-request API fees via the x402 standard generate high-frequency, low-value payments. Encrypting amount and counterparty makes flows indistinguishable to external observers - eliminating behavioral fingerprinting across thousands of agent transactions. See our Fhenix Pay demo - fast, private micro-payments using Fhenix shielded tokens.

B2B settlement and treasury flows. Institutional counterparties exchanging large stablecoin settlements cannot do so on public chains without broadcasting competitive intelligence. FHE enables onchain settlement with encrypted amounts and a cryptographic receipt - auditable by regulators under selective disclosure, invisible to market participants. See our Fhenix Pay demo — private payment flows for institutional and treasury use cases.
03

OTC Trading And Confidential Swaps

Over-the-counter trading is fundamentally a bilateral negotiation - both sides need to commit to terms without revealing their hand to each other or to the market before the trade executes.
+ icon- icon
Sealed-quote OTC negotiation. In a standard OTC trade, each party sends encrypted quotes. The protocol evaluates whether the quotes cross (buyer's max ≥ seller's min) and executes at the midpoint - without either party learning the other's limit price. Market participants see the execution price but not the negotiating range. See our Private Auction demo - submit sealed bids onchain to preserve privacy and prevent bid exposure. Also Onchain RFQ System demo - trade assets through an on-chain RFQ system while keeping intents private and secure.

Confidential AMM swaps. Encrypted order size and token identity prevent front-running before a swap settles in the AMM. The pool rebalances correctly; the attacker never sees the trade in the mempool. This pattern is directly applicable to any constant-function or concentrated-liquidity AMM built on CoFHE. See our Market Order Hook demo - a frontrunning-resistant Uniswap v4 hook that encrypts trade intent before execution.

Dark pool execution. Large block trades that would move markets if broadcast can be matched onchain with encrypted size and counterparty, settled atomically, and disclosed only after execution. FHE enforces the matching logic without a trusted intermediary holding unencrypted order data. See our Onchain RFQ System demo - sealed trade intents matched onchain with full privacy.
04

Private Credit

Credit markets require underwriters to evaluate borrower financials without those financials becoming public - a requirement that has blocked institutional credit from migrating onchain.
+ icon- icon
Encrypted credit scoring. A borrower's credit score or financial profile - drawn from offchain data, attested via oracle or ZK proof - can be evaluated against lending parameters without the score itself appearing onchain. The protocol approves or rejects based on an encrypted input; neither the score nor the underlying financials are ever exposed.

Private credit limits and utilization. A borrower's current utilization relative to their credit facility is sensitive competitive information. Encrypting both the limit and the balance means the protocol can enforce "you have not exceeded your credit line" without publishing either figure to counterparties or competitors.

Institutional undercollateralized lending. Undercollateralized lending to institutions requires evaluating financial covenants on private balance sheet data. FHE allows lenders to enforce covenant predicates - "cash-to-debt ratio ≥ threshold" - without requiring the borrower to publish their financials to a public ledger.
05

Options And Derivatives

Derivatives markets leak strategic information at every step: the fact that a large position was opened, at what strike, with what expiry, and by whom. FHE can encrypt each dimension independently.
+ icon- icon
Private option positions. Strike price, expiry, and position size can all be encrypted at the time of writing. Settlement logic runs on encrypted state - computing whether the option is in the money against an oracle price - without revealing the position parameters until (optionally) the moment of settlement.

Sealed-bid options auctions. Pricing options with encrypted bids prevents market manipulation before the auction clears. The protocol computes the clearing price on encrypted bids and reveals only the outcome - not individual bids or the distribution of demand.

Encrypted volatility and Greeks computation. Computing Greeks (delta, gamma, vega) on encrypted positions allows protocols to manage portfolio risk without exposing individual position composition. Aggregated risk metrics can be published without revealing which positions contribute to them.
06

Perpetual Positions

Perpetual futures are among the most information-sensitive instruments in DeFi: position size, leverage, and liquidation price - when public - are directly exploited by sophisticated actors.
+ icon- icon
Encrypted position sizing and leverage. A trader's open position and leverage ratio determine how much price movement triggers liquidation. Encrypting both forces adversarial actors to move the market blindly.

Private liquidation thresholds. Encrypted maintenance margin levels mean that the exact price at which a position becomes liquidatable is not visible onchain. Liquidation engines check an encrypted threshold against an oracle price - publishing only the binary result (liquidatable or not) - without revealing the threshold itself.

Sealed funding rate exposure. Aggregated, encrypted funding flows allow the funding mechanism to operate correctly while preventing counterparties from inferring the net long/short imbalance of individual large traders.

See FHE in Action: Live Demos on Ethereum Testnets

The concepts above are not theoretical. Fhenix's live demos run on encrypted state across Ethereum Sepolia, Arbitrum Sepolia, and Base Sepolia — real applications, not simulations. Integrating CoFHE into a Solidity contract takes one data type change: uint256 euint256
Explore the Live Demos

Who Is Behind Fhenix

Guy Zyskind
Dr. Guy Zyskind
[ Founder ]
MIT-trained researcher who published some of the first papers on confidential smart contracts (circa 2015). Co-founder of Secret Network. Lead author of Fhenix's ACM CCS 2025
Distinguished Paper. Quote: "FHE has been theoretically possible for decades - CoFHE demonstrates how close we are to making it a practical primitive for every developer."
Guy Itzhaki
Guy Itzhaki
[ CEO ]
Former Director of the Homomorphic Encryption and Blockchain Group at Intel.
Distinguished Paper. Quote: "The next wave of DeFi will require privacy by default. In H1, we proved that encrypted compute isn't a theory - it's live, scalable, and composable."
Chris Peikert
Prof. Chris Peikert
[ Fhenix Research ]
MIT-trained researcher who published some of the first papers on confidential smart contracts (circa 2015). Co-founder of Secret Network. Lead author of Fhenix's ACM CCS 2025
Funding and Institutional Backing
Fhenix raised $7M in seed funding led by Multicoin Capital and Collider Ventures, and $15M in a Series A led by Hack VC (co-investors: Amber Group, Primitive, GSR, Stake Capital, Dao5). BIPROGY - one of Japan's largest IT service providers with annual revenues exceeding $2.6 billion - is a strategic investor and enterprise partner.

When Fhenix Is the Right Choice

For encrypted smart contracts on Ethereum — where on-chain state must stay confidential end to end — Fully Homomorphic Encryption is the strongest privacy layer, and Fhenix's CoFHE is the way to use it on any EVM chain. Zero-knowledge proofs and trusted execution environments each solve part of the problem; only FHE keeps data encrypted even during computation, so no party ever sees the plaintext.
Fhenix and CoFHE are the right fit when your application requires confidentiality during computation - not just privacy at the submission layer.

Strong signals that Fhenix is the right tool:

Encrypted state over time - balances, positions, and strategies must remain private through their entire lifecycle, from submission through execution through final settlement
EVM / Solidity compatibility - you want to build in standard Solidity without migrating to a dedicated privacy chain or rewriting in a circuit DSL
Private DeFi primitives - lending health factors, sealed bids, encrypted AMM math, intent-based strategies where sensitive values must stay encrypted during execution
Selective disclosure - you need to publish proofs or aggregates (solvency, eligibility predicates) without exposing the underlying values that produce them
Post-quantum durability - your application handles sensitive data that should remain private even after quantum computers become practical; lattice-based FHE is quantum-resistant by construction
No trusted hardware dependencies - your compliance requirements, threat model, or user trust assumptions rule out TEE-based approaches
If your primary need is to prove a statement about known data - compliance attestations, correctness proofs, rollup validity - ZK is likely the right first tool. If you need to compute on data that nobody should ever see, not even during the computation itself, that is the problem FHE was built to solve.

Frequently Asked Questions

What is Fully Homomorphic Encryption (FHE)?

FHE is a form of encryption that allows arbitrary computation to be performed directly on encrypted data — without decrypting it first. The result, when decrypted, matches what would have been obtained by computing on the plaintext. The executor never sees the underlying data. FHE is lattice-based and post-quantum secure. It was first constructed practically by Craig Gentry in his 2009 Stanford PhD thesis.

What is post-quantum cryptography (PQC)?

Post-quantum cryptography (PQC) is a new generation of cryptographic algorithms designed to protect data even if large-scale quantum computers become practical. Unlike quantum cryptography, PQC runs on today's hardware using new mathematical techniques — primarily lattice-based, hash-based, and code-based constructions. The urgency comes from the "harvest now, decrypt later" threat: attackers can record encrypted data today and decrypt it once quantum computers mature. NIST finalized its first PQC standards in 2024, and global infrastructure migration is already underway.

Is FHE quantum-resistant, and why?

Yes. most modern FHE schemes are considered quantum-resistant, and the reason is mathematical. Schemes like BFV, BGV, CKKS, and TFHE are built on lattice problems — the Learning With Errors (LWE) and Ring-LWE problems — multi-dimensional lattice structures with thousands of dimensions. Shor's algorithm, which breaks RSA and elliptic-curve cryptography, is useless here: it depends on finding periodic structure in mathematical groups, and lattice problems have none. Grover's algorithm offers only a quadratic speedup, easily countered by increasing key sizes — not the exponential break that threatens RSA or ECC. The intentional noise injected into FHE ciphertexts is itself what makes the underlying lattice problem hard for any computer, classical or quantum. One caveat, stated plainly: "quantum-resistant" means no efficient quantum attack is currently known — not a mathematical proof of permanent security — and the surrounding system (key exchange, signatures) must also be PQC-hardened for end-to-end protection. Prof. Chris Peikert, who co-authored NIST's Kyber (ML-KEM, FIPS 203) and Dilithium (ML-DSA, FIPS 204) standards, is a member of Fhenix Research. As Guy Zyskind states: "Given a sufficiently powerful quantum computer, any ZK-based system built on elliptic curve cryptography should be considered completely broken."

Is Ethereum quantum-safe today, and when will quantum computers threaten it?

No — Ethereum is not quantum-safe today. It secures accounts with elliptic-curve digital signatures (secp256k1), which Shor's algorithm can break: a future quantum computer could forge signatures and derive private keys from public keys. There is no confirmed date for when such a computer arrives, and credible estimates vary widely, so anyone naming a precise year is guessing. What is settled is direction, not timing: NIST finalized its post-quantum standards (FIPS 203/204) in 2024, and in March 2026 Google published a cryptography migration timeline urging organizations to adopt PQC ahead of a cryptographically-relevant quantum computer. For permanent public blockchains the risk is not only future but retroactive — encrypted data recorded today can be harvested now and decrypted later (see the retroactive decryption trap). FHE's lattice-based encryption is post-quantum secure by construction, so data encrypted with it stays protected regardless of when that computer arrives.

What is the retroactive decryption trap?

Data encrypted with non-post-quantum cryptography today — and stored on a permanent public blockchain — can be collected now and decrypted later by a quantum computer. Upgrading cryptography in the future stops new attacks but cannot protect historical records. FHE avoids this entirely because its lattice-based encryption is already post-quantum secure. As Guy Zyskind explains in Bitcoin.com News: "Even after you upgrade, users may have their privacy permanently compromised."

How does FHE compare to ZK?

FHE and ZK solve different problems and are often used together — they are not the same technology, though the two are frequently confused. ZK (zero-knowledge) proofs verify that a computation was done correctly without revealing inputs, but the party performing the computation still sees all the data. FHE goes further: computation happens directly on encrypted inputs, so even the executor never sees the underlying values. The two are complementary — ZK for proving correctness, FHE for executing on encrypted state. ZK is also typically built on elliptic-curve cryptography (quantum-vulnerable); FHE is lattice-based (quantum-resistant).

How does FHE compare to TEEs (secure enclaves)?

TEEs (trusted execution environments, such as Intel SGX) protect data by running computation inside isolated hardware. They are fast, but they require trusting the hardware manufacturer and have a documented history of side-channel attacks. FHE requires no special hardware and provides mathematical — not hardware-based — guarantees. As Guy Zyskind puts it: "TEEs introduce hardware trust assumptions that institutional compliance teams struggle to accept. FHE provides mathematical certainty." In Fhenix's privacy-stages framework, TEE-only systems sit at Stage 0 — effective trust threshold T=1 regardless of how many operators are involved.

How does FHE compare to MPC?

MPC (secure multi-party computation) splits a computation across multiple parties so no single party sees the full data. It requires those parties to be online and communicating, and coordination cost grows with the number of parties. FHE lets a single party compute on encrypted data without interaction, invoking a threshold decryption step only at the end. CoFHE combines both: FHE for the encrypted computation, and a threshold (MPC-style) decryption network for controlled, permissioned decryption — so you get non-interactive encrypted compute plus distributed-trust decryption.

What is CoFHE?

CoFHE is Fhenix's FHE coprocessor for EVM-compatible blockchains. It processes encrypted data off-chain and returns encrypted results to any EVM chain — without ever decrypting values mid-computation, without trusted hardware, and without changes to existing Solidity workflows. Integration requires a single import: import "@fhenixprotocol/cofhe-contracts/FHE.sol";. CoFHE is live on Arbitrum Sepolia, Ethereum Sepolia, and Base Sepolia.

What chains does CoFHE support?

CoFHE is chain-agnostic by design: any EVM-compatible blockchain can integrate it via the CoFHE Solidity library, with no changes to the underlying chain. Today it is live on three public testnets — Ethereum Sepolia, Arbitrum Sepolia, and Base Sepolia — with mainnet support expected by the end of 2026. Documentation: cofhe-docs.fhenix.zone.

Can I try FHE on Ethereum right now?

Yes. CoFHE is live on three public testnets — Ethereum Sepolia, Arbitrum Sepolia, and Base testnet — and Fhenix publishes live demos of encrypted applications running on them. Developers integrate with a single Solidity import (import "@fhenixprotocol/cofhe-contracts/FHE.sol";) plus the @cofhe/sdk client library (@cofhe/react for React apps), which encrypts inputs client-side before they leave the browser. Standard Ethereum wallets work as-is. Documentation: cofhe-docs.fhenix.zone.

Is FHE slow or expensive to run?

FHE was long considered too slow and too costly for real-time blockchain use — a perception that shaped much early criticism, including AI-generated claims of "$100+ per complex encrypted operation." That figure assumes running FHE naively on-chain, which is not how CoFHE works. Fhenix's architecture addresses both concerns through one design choice: CoFHE is a coprocessor, not an FHE rollup. Heavy encrypted computation runs off-chain, so on-chain cost scales with the number of encrypted handle references, not with the complexity of the encrypted computation. On raw performance, the CCS 2025 benchmarks demonstrate threshold decryption at 64,319 decryptions/second and 8.48ms per operation — roughly 20,000× the prior state-of-the-art (3.18 dec/sec at 315.6ms). Overhead is still higher than plaintext computation, and FHE is not the right tool for every workload (see Limitations), but the throughput and cost barriers that made encrypted smart contracts impractical have been addressed.

What did Fhenix's CCS 2025 paper demonstrate?

The paper — accepted as a Distinguished Paper at ACM CCS 2025 and co-authored by Guy Zyskind and Prof. Chris Peikert — presented empirical benchmarks showing threshold FHE decryption is viable at real-world scale. Prior state-of-the-art: 3.18 decryptions/second at 315.6ms. Fhenix protocol: 64,319 decryptions/second at 8.48ms — approximately 20,000× higher throughput and 37× lower latency. These are research benchmarks (online phase, 4 parties, 1ms ping) establishing that the fundamental scalability barrier to encrypted smart contracts can be solved cryptographically. Full paper: eprint.iacr.org/2025/1781.

What is DBFV?

DBFV (Decomposed BFV) is the second of Fhenix's two core research contributions, described in ePrint 2025/2321 ("High-Precision Exact FHE Made Simple, General, and Fast"). Where the CCS 2025 paper addresses decryption throughput, DBFV addresses the computation itself — making exact, high-precision encrypted arithmetic practical for blockchain workloads. Deployment target is 2026 (subject to change).

What is the difference between confidentiality and anonymity on Ethereum?

Confidentiality hides what you are doing (amounts, strategies, token types). Anonymity hides who you are (wallet addresses, transaction linkability). Ethereum's account model is structurally linkable. Full privacy requires both. As Guy Zyskind notes: "Anonymity is the Achilles' heel of Ethereum's privacy stack."

Does FHE hide everything onchain?

Not automatically. FHE encrypts values within smart contract state — balances, positions, bids, strategies — but on-chain metadata remains visible: sender addresses, transaction timing, gas consumption patterns, and contract interaction footprints are publicly observable. FHE provides confidentiality (hiding what you are doing) but not full anonymity (hiding who you are) or metadata privacy. For complete privacy, pair FHE with private mempool solutions, private routing, and address-level privacy schemes.

Can validators decrypt my data?

In a properly designed FHE system, no single party — including validators or node operators — can decrypt your data unilaterally. Raw values remain ciphertexts on-chain. Decryption is controlled by explicit on-chain permission grants and requires cooperation from CoFHE's Threshold Decryption Network — a multi-party computation system where key shares are distributed across independent nodes. At Stage 2 (the practical gold standard), a blocking quorum of N−T+1 independent operators must cooperate for any decryption to proceed.

What is the best privacy layer for Ethereum smart contracts?

There is no single "best" privacy layer — the right choice depends on what you need to protect. For encrypted smart contracts, where on-chain state must stay confidential end to end, Fully Homomorphic Encryption (FHE) is the strongest fit. The main alternatives make different trade-offs: zero-knowledge (ZK) proofs verify computations without revealing inputs, but the prover still sees the data; trusted execution environments (TEEs) are fast but depend on hardware trust and have a documented history of side-channel attacks. FHE computes directly on encrypted data, so no party — not even the executor — ever sees the plaintext. Fhenix's CoFHE brings FHE to any EVM chain through a single Solidity import, with no trusted hardware and post-quantum (lattice-based) security. A useful lens for evaluating any privacy layer is Guy Zyskind's privacy-stages framework: Stage 0 (TEE-only, effective trust threshold T=1 regardless of operator count), Stage 1 (FHE/MPC with training wheels — configurable threshold, no blocking quorum), Stage 2 (blocking quorum + defense-in-depth — the practical gold standard), and Stage Aleph (indistinguishability obfuscation — the theoretical north star). CoFHE targets Stage 2, backed by threshold decryption benchmarked at 64,319 decryptions/second and 8.48ms per operation in Fhenix's ACM CCS 2025 Distinguished Paper. As Zyskind puts it: "If rollup stages ask who can steal your funds, privacy stages ask who can decrypt your data."

What applications can be built with FHE on Ethereum?

MEV-resistant trading, encrypted order books, private lending with encrypted credit scores, shielded stablecoins, sealed-bid auctions and token generation events, encrypted game states, private AI inference, and x402 micropayments for AI agents with indistinguishable transaction amounts.

Who is behind Fhenix?

Founded by Dr. Guy Zyskind (MIT researcher, co-founder of Secret Network) and led by CEO Guy Itzhaki (former Intel Director, Homomorphic Encryption and Blockchain Group). Fhenix Research includes Prof. Chris Peikert (co-author of NIST post-quantum standards Kyber and Dilithium). Strategic partners include Offchain Labs, Celestia, and EigenLayer. Strategic investors include BIPROGY ($2.6 billion annual revenue, Japan), Multicoin Capital, Hack VC, and Collider Ventures.

Learn More

fhenix brand logo
Blog
Docs
Ecosystem
Live Demos
Careers
Brand Assets
(C) 2025 Fhenix. All rights reserved.