%20(16).svg)
Forward-looking statements. This paper describes future plans and functionality that is not yet live. These reflect current intentions only, may change or be abandoned without notice, and are not a commitment that any feature, timeline or mechanism will be delivered. No one should rely on them in making any decision.
References to a network token describe intended protocol functionality only. They are not an offer or solicitation to buy any token, security or other financial instrument, nor a representation as to its value or any return.
This paper is for informational purposes only and is not legal, financial, investment or tax advice.
Blockchains ensure correct execution and censorship resistance in a trust-minimized way, at the expense of data confidentiality. All on-chain state is public because every node must see the data to reach consensus. Despite popular belief, this extreme transparency is a by-product of how consensus works, not a design goal. It is also a hard ceiling on the type of applications that can be built on-chain: any application that requires sensitive data cannot run on a public chain without either exposing what it needs to protect, or moving that sensitive logic entirely off-chain - surrendering the trust guarantees that make blockchains valuable in the first place.
The practical consequences are well-documented. Maximal Extractable Value (MEV) — the profit available to block producers and searchers who observe pending transactions and exploit their ordering — extracts hundreds of millions of dollars from ordinary users through front-running, sandwich attacks, and liquidation racing; a single sandwich bot on Ethereum is estimated to have extracted roughly $295 million since 2023¹. These are rational responses to a system where every market participant's intentions are visible before they are settled. Beyond MEV, transparency leaks strategy: an on-chain fund discloses its rebalancing intent, a lending protocol exposes which positions are approaching liquidation thresholds, a DAO treasury broadcasts its sell pressure days before execution. Pseudonymity provides no durable protection: transaction-graph analysis, wallet clustering, and cross-chain linkage attribute addresses to individuals and entities with increasing accuracy; every on-chain action is a public signal regardless of whether a name is attached to it.
Financial institutions operate under trust obligations that prohibit broadcasting client positions. Trading strategies are proprietary. Loan terms and counterparty relationships in credit and derivatives markets are confidential by legal necessity. Regulators require audit access, but that is categorically different from permanent public visibility. The result is a hard exclusion: the DeFi lending market holds roughly $50 billion in TVL², yet institutional capital - which manages approximately $130 trillion globally³ - participates at the margins. The OTC market grew 106% year-over-year in 2024⁴ as insiders sought private settlement rails, yet the final on-chain settlement step remains publicly visible. Tokenized RWAs reached approximately $20 billion in on-chain value by end of 2025⁵ but cannot absorb institutional private credit, structured products, or OTC derivatives because their terms are incompatible with public ledgers. The missing primitive is not throughput or finality. It is confidentiality.
Fully Homomorphic Encryption (FHE) solves this problem at its root: it allows arbitrary computation to be performed directly over encrypted data, so smart contracts can operate on state that no one - including the party running the computation - can read.
Fhenix is a privacy infrastructure company built on the thesis that FHE performance has now crossed the threshold of practical utility. Its core product, CoFHE - an FHE-based Coprocessor - augments any EVM-compatible chain with programmable, policy-governed confidentiality, without requiring changes to the host chain or its execution environment. The long-term vision is for FHE-based confidentiality to become a standard primitive in every blockchain developer's toolbox: the natural answer to "my application needs privacy," across DeFi, institutions, gaming, identity, and AI.
This document provides a technical overview of the Fhenix protocol. It covers the privacy landscape and why FHE is uniquely suited to this problem (§2), Fhenix's approach and design principles (§3), the CoFHE architecture and its trust model (§4), the Threshold Decryption Network (§5), use cases and ecosystem (§6), the developer experience (§7), and the protocol roadmap (§8).
Several cryptographic approaches tackle parts of privacy, but each has a core limitation:
Zero-Knowledge Proofs (ZK) prove statements about private data without revealing it - great for selective disclosure, but they don’t provide general-purpose, autonomous computation over hidden contract state.
Trusted Execution Environments (TEEs) run plaintext inside hardware enclaves - fast and flexible, but security depends on hardware trust/side‑channel resistance and is hard to audit.
Multi-Party Computation (MPC) splits computation across multiple parties so no single party learns inputs - strong security, but high interaction/latency and liveness requirements.
Mixers / privacy chains mainly hide transaction links (who paid whom) - useful for payment anonymity, but they don’t hide or compute over long-lived private smart contract state.
Fully Homomorphic Encryption is distinguished by a single property: it enables arbitrary computation directly on ciphertexts, such that decrypting the result is identical to performing the same computation on the underlying plaintexts. No party performing the computation holds or requires the decryption key. No trusted hardware is involved. Security rests on the hardness of the Learning With Errors (LWE) problem over integer lattices - a problem believed to be resistant to attacks by both classical and quantum computers, and the foundation of post-quantum cryptographic standards.
FHE was first demonstrated as a plausible construction in 2009. For most of the following decade it remained impractical - computational overhead was orders of magnitude too high for production use. A succession of more efficient schemes (BFV, BGV, TFHE and CKKS), algorithmic advances such as faster bootstrapping and decomposition techniques, and hardware acceleration have changed this picture materially. Some Modern FHE implementations exploit SIMD-style plaintext packing, GPU acceleration, and ring-structured algebraic representations to achieve throughput and latency compatible with blockchain settlement timescales. Fhenix's own contributions - the dBFV scheme and the threshold decryption protocol published at ACM CCS 2025 - advance the state of the art further.
Fhenix's position in this landscape is to make FHE practical for the EVM: chain-agnostic, accessible through standard Solidity and a TypeScript SDK, and backed by production-grade cryptographic infrastructure. The goal is not to replace existing tools such as ZK and MPC which remain valuable for achieving privacy, but to supply what none of them combine: non-interactive computation over shared encrypted state by a single untrusted operator - autonomous, composable, and free of hardware trust - following the same logic as any plaintext contract, but with inputs, state, and outputs kept encrypted throughout.
No single technology wins every row — and they are complements more than competitors. CoFHE composes them by role: FHE provides the encrypted computation, ZK proofs validate encrypted inputs, threshold MPC governs decryption, and TEEs serve as interim key management in the MVP phase (Appendix A). The table above compares the underlying technologies; the chapters that follow describe how CoFHE combines them.
Fhenix's mission is to make encrypted computation a first-class primitive on Ethereum and other EVM-compatible chains, with support for additional chains over time. The goal is not to build a parallel execution environment that protocols must migrate to, but to extend the existing smart contract model with the ability to operate over encrypted state - so that confidentiality becomes an option any protocol can adopt, on any chain it already lives on.
CoFHE is “private computation as a service” for existing EVM ecosystems: instead of asking developers to migrate to a new chain or adopt a new VM, a coprocessor integrates alongside the chains, tooling, and liquidity they already use. Contracts keep their normal deployment and interfaces, while CoFHE executes FHE workloads off-chain and returns verified encrypted results to the host chain.
Three principles govern how CoFHE is built.
Chain-agnostic. CoFHE operates as a service layer alongside any EVM-compatible host chain - Ethereum, Arbitrum and beyond. The only integration boundary is the host contract interface; the encrypted computation is handled off-chain by CoFHE and verified against commitments published on-chain. Protocols do not choose between their existing deployment and confidentiality.
Developer-first. FHE's cryptographic complexity is fully abstracted from the application developer. Encrypted integer types (euint8 through euint128, ebool, eaddress) are available via a single Solidity import. Existing toolchains - Hardhat, Foundry, standard EVM deployment - work without modification. Client-side encryption and decryption are handled by the @cofhe/sdk TypeScript library, making interaction with FHE-enabled contracts indistinguishable from any standard web3 frontend flow.
Modular. Confidentiality in CoFHE is a service layer, not an execution silo. Encrypted state coexists with plaintext state within the same contract. Developers decide granularly what is encrypted and what remains public. Existing DeFi primitives can be augmented with encrypted state without being rewritten.
The key building blocks - the FHE Solidity library (FHE.sol), the CoFHE Engine, the Threshold Decryption Network, and the @cofhe/sdk client - are described in §4.
CoFHE can be understood as a shared computer with encrypted memory. Users submit encrypted values as input, operations are executed on those values while they remain encrypted, and results are returned to authorized parties as plaintext only upon an explicit decryption request. Unlike a conventional computer, no data is ever stored or processed in the clear: CoFHE’s equivalent of a CPU — the FHE Engine — evaluates homomorphic operations directly over ciphertexts, without needing to know the underlying values. Since the memory is always encrypted and the FHE Engine holds no secret material, the only sensitive points in this system are input and output: input integrity is enforced via Zero-Knowledge Proofs of Knowledge (ZKPoKs), which verify that submitted ciphertexts are well-formed without revealing their contents, and output is governed by threshold decryption (§5).
From the perspective of a smart contract, CoFHE operates as an asynchronous computation service: the contract submits an encrypted operation, and CoFHE returns a verified encrypted result — with data remaining private throughout the entire pipeline.
The underlying cryptographic machinery — ciphertext management, ZK proof verification, threshold decryption coordination — is fully abstracted from the contract developer and the end user. This abstraction does not come at the cost of security: access control and ciphertext integrity are enforced at every boundary of the system, as described below.
Before describing the CoFHE architecture in detail, it is useful to define the core concepts that appear throughout the system. CoFHE separates the value being protected, the encrypted representation of that value, and the on-chain reference used by smart contracts to operate on it. This section introduces that vocabulary so the lifecycle that follows — from input encryption, to off-chain FHE execution, to commitment verification and decryption — can be read as a single coherent flow.
CoFHE is a complex system that can be divided into two parts: on-chain components and off-chain components.
In practice, symbolic execution looks like ordinary Solidity:
euint64 newBalance = FHE.sub(balance, amount); // returns immediately - newBalance is a handle
balances[msg.sender] = newBalance; // stored and composable in the same transaction
FHE.allowThis(newBalance); // grant the contract access for future transactionsThe call returns within the same transaction, with a handle referencing the future encrypted result. Handles are first-class values: they can be stored, passed between contracts, and used as inputs to further FHE operations - all before the underlying computation has run. The heavy homomorphic work executes asynchronously in the off-chain Engine, and the Commitment Registry binds each handle to the hash of the ciphertext it eventually resolves to. Contract logic never blocks on cryptography.
CoFHE Architecture
Encryption. The user encrypts plaintext inputs client-side via @cofhe/sdk, which generates a ZK proof of knowledge attesting to the ciphertext's well-formedness. The ZK proof and the ciphertext are being verified by the ZK Verifier which returns a signature that proves the verification was done. Both the ciphertext and the signature are submitted as a function arguments and registered in the system with a handle.
FHE Operation. A contract calls FHE.sol, which forwards the request to the Task Manager. The Task Manager validates the request, checks ACL permissions, assigns an output handle, and emits an event. The off-chain layer picks this up, executes the homomorphic operation (by the FHE Engine), and registers the result. The output handle is immediately available to the contract, before the off-chain part begins - the cycle is asynchronous and non-blocking.
Decryption. The user is using cofhe/sdk to initiate a decryption. cofhe/sdk will generate a permit that is signed by the user in order to cryptographically prove that the user is who claims to be. The request, including the permit, is sent to the TN which verifies the request the ACL, executes the MPC decryption protocol across party members, and returns a signed result. A user who wants the result to be present on chain (for example: voting results) will be able to do so with the threshold signature that was provided by the TN in the end of the process.
Re-encryption. Another flow which is very similar to decryption, also referred as SealOutput. SealOutput ensures that the data that is being decrypted will be re-encrypted with the owner's credentials and while the data will never be plaintext in the way. This is user in order to let the owner of the data read it's own private data without it ever being public.
Encryption request flow
Consider Alice sending 100 tokens to Bob through a confidential FHERC20 token on the host chain of her choice.
At no point does the plaintext amount exist outside Alice's and Bob's own devices.
Each component of CoFHE is trusted with as little as possible. The table below summarizes what each component can observe, and the blast radius of its failure or compromise.
| Component | What it can see | If it is malicious | If it is offline |
|---|---|---|---|
| Task Manager & ACL (on-chain) | Handles and public call metadata only | Contracts on the host chain - misbehavior requires compromising the host chain itself | Available whenever the host chain is |
| ZK Verifier | Ciphertexts and validity proofs - no plaintexts | Could falsely attest to a malformed input; however, attestations are signed and auditable, and verification is expected to move on-chain per the roadmap, protected by multisig governance. | New encrypted inputs stall; existing state is unaffected |
| FHE Engine | Ciphertexts only - never keys or plaintexts | Can produce an incorrect result but cannot read data; commitments make execution reproducible and verifiable, with staked operators planned (see Roadmap) | Pending computations are delayed; no data is ever exposed |
| Commitment Registry | Public hashes only | Inherits Arbitrum One's security | Inherits Arbitrum One's liveness |
| Threshold Decryption Network - single Party Member | One key share; any sub-threshold coalition learns nothing | Can refuse to participate or submit a bad partial decryption - detected and excluded; cannot decrypt alone | Decryption proceeds as long as a sufficient quorum of PMs remains live |
| TN Coordinator | Routing metadata and masked intermediate values | Liveness-critical but not trusted for security: cannot learn the key or forge results without detection | Decryptions stall until restored; no security impact |
| @cofhe/sdk (client) | The user's own plaintexts, on the user's own device | - | - |
In the MVP mainnet release, some of these components are operated by Fhenix (see Appendix A); the guarantees above describe the full CoFHE architecture that the roadmap progressively activates.
Fhenix follows a "training wheels" approach to production deployment: ship to real users early with a clearly disclosed trust model, and progressively decentralize as the architecture matures. In the MVP mainnet release, the decryption key is protected by TEE-based key management, with key shares held within Fhenix-operated infrastructure - the training wheels - while the architecture described in this chapter is rolled out progressively. The CoFHE MVP architecture is described in Appendix A.
Mainnet decentralization target. The post-launch roadmap systematically eliminates each trust assumption. External, independently operated Party Members (PMs) join the TN under a threshold scheme in which no single operator — including Fhenix — can decrypt on its own. The Trusted Dealer is replaced via a public ceremony and ultimately a fully MPC-based Distributed Key Generation (DKG).
Auditable FHE Engine. The Auditable FHE Engine follows an optimistic security model in which all public protocol artifacts-including zero-knowledge proofs of knowledge (ZKPoKs), commitments, blockchain events, public keys, and computation keys-are published immutably and are available for independent verification. In the target design, the engine operator locks a security stake that can be slashed if a protocol violation or inconsistency is cryptographically proven. Because FHE execution is deterministic, any computation can be independently reproduced and verified using the publicly available data. As a result, incorrect execution is objectively detectable, making the engine fully auditable and accountable without requiring trust in the operator.
CoFHE Mainnet Architecture
In any FHE system, the decryption key is the singular point of maximum sensitivity. Homomorphic computation over encrypted data is fully secure as long as the key remains inaccessible - no party performing computation on ciphertexts learns anything about the underlying plaintexts. But every practical system eventually requires decryption: a user must retrieve their balance, a contract must reveal an auction result, a regulator must audit a position. The moment decryption is necessary, who controls the key defines the actual security guarantee of the entire system.
The underlying FHE scheme requires a Secret Key (Sk) - the piece of data that can decrypt any value stored in CoFHE’s memory. Sk also generates the public material (Pk, eval_keys), used by clients during input encryption and by the FHE Engine when evaluating homomorphic operations. Naively holding Sk in a single location would make it the most dangerous attack surface in the system, and key shares held within a single operator's infrastructure - even protected by hardware enclaves - still require users to trust that operator's systems and intentions. This is a meaningful starting point, but not the end state. CoFHE’s answer is to never assemble Sk at all: it is split into shares distributed across independently operated PMs using Multi Party Computation (MPC), such that decryption requires cooperation from a qualified threshold - a robust and verifiable trust model that removes the need to trust any single actor.
The Threshold Decryption Network (TN) implements a threshold secret-sharing scheme over the master decryption key, distributed across n independently operated Party Members (PMs). The threshold t is a security parameter: the protocol tolerates up to t corrupt PMs — any coalition of t or fewer learns nothing about the key and cannot produce incorrect decryption outputs — and, via Shamir Secret Sharing, remains live as long as a sufficient quorum of PMs responds.
Party Members hold individual key shares and participate in the MPC decryption protocol. In the target architecture, each PM independently verifies every decryption request before contributing its share.
The Coordinator routes requests and intermediate protocol messages between PMs and assembles the final output. It is liveness-critical but not trusted for security: it sees only routing metadata and masked intermediate values, and cannot learn the key or forge results without detection.
Before any PM participates in a decryption, it independently verifies that the request is authorized and that the ciphertext corresponds to the commitment recorded by the system. In practice, this means checking that:
Only requests that pass these checks proceed.
Once verification succeeds, the qualifying Party Members jointly execute the DKOP26 threshold decryption protocol (§5.4). No Party Member reconstructs the full secret key, and no sub-threshold coalition can decrypt independently. The result is returned only to the authorized requester through @cofhe/sdk.
For user-facing reads, the result is delivered via SealOutput - re-encrypted under the requester's key - so the plaintext is never published on-chain or exposed to the network.
Academic validation. DKOP26 builds on and improves Fhenix's ACM CCS 2025 threshold decryption protocol. It is an MPC-based modulus conversion scheme that achieves statistical UC security against malicious adversaries, with no noise flooding.
Performance. The threshold decryption protocol is estimated to sustain throughput in the thousands of Decryptions per Second (DPS), making it practical for the demand profiles of production on-chain applications.
For details on the mainnet launch trust assumptions and the transition path toward the full Threshold Decryption Network, see Appendix A.
CoFHE is general-purpose privacy infrastructure. The use cases it enables span any domain where on-chain logic must operate over data that cannot be publicly exposed. DeFi as the most immediate and most damaged by transparency, is the first deployment phase but the architecture is domain-agnostic by design.
Confidential DeFi. Every major DeFi primitive is improved by encrypted state. Encrypted AMMs and dark pools accept orders as ciphertexts, evaluate matching conditions (bid ≥ ask) directly on encrypted values, and reveal only executed trades to counterparties - removing the information that front-running and strategy copying depend on. Confidential lending encrypts collateral amounts, debt positions, and liquidation thresholds, allowing the protocol to monitor LTV ratios and trigger liquidations autonomously on encrypted state - removing the publicly-known thresholds that invite targeted manipulation. Shielded stablecoins implement encrypted balances and transfers via dual ERC-20 or fhERC-20, providing the private settlement rail that every other confidential DeFi primitive needs: dark pools, lending, OTC settlement, and institutional participation all require a confidential stable-value layer.
Tokenized Real-World Assets and TradFi Institutions. Private credit, structured products, and OTC derivatives are confidential by legal necessity in traditional finance - loan terms, counterparty identity, and deal economics cannot appear on a public ledger. CoFHE enables RWA protocols to execute loan logic (interest accrual, covenant monitoring, waterfall distributions) on encrypted data, with selective disclosure via access control permits: regulators can be granted full audit access, investors see their tranche, the public sees nothing. This unlocks institutional participation that is currently structurally excluded: asset managers can manage on-chain portfolios without broadcasting positions, funds can access DeFi yield without exposing their positions, and investment banks can settle OTC instruments atomically on-chain without either party's book becoming public record.
Governance. Token-weighted voting on public chains is attributable and gameable - delegate positions are tracked, large-holder votes signal outcomes before the period closes. FHE enables governance contracts where votes are submitted as ciphertexts, tallied homomorphically, and the result decrypted and published without any individual vote ever being visible. The outcome is verifiable; the process is confidential.
Decentralized Identity. FHE enables identity contracts where attributes - KYC status, jurisdiction, accreditation, credit score - are stored encrypted and disclosed selectively per verifier via access control permits. A contract confirms a threshold is met without learning the underlying value; a regulator audits the full record without that access being permanent or public. Encrypted on-chain reputation allows institutions to port off-chain credibility on-chain without doxxing themselves.
Gaming. Public contract state limits on-chain games to full-information designs. FHE enables hidden game state such as encrypted card hands, fog of war, sealed strategies, that is cryptographically enforced rather than trust-dependent, opening fully on-chain implementations of poker, strategy games, and any genre where private information is a core mechanic.
AI and Agentic Workflows. As FHE schemes and hardware acceleration improve, lightweight models will be able to run inference over encrypted inputs, letting sensitive data - financial records, medical data, behavioral signals - feed a model without exposure to the protocol or any intermediary. More immediately, blockchain and FHE together supply the trust layer that autonomous agents lack: privacy-preserving proof of humanity that ties an action to a verified person and resists bot-driven fraud, and verifiable delegation chains in which each agent's authority provably derives from - and never exceeds - what it was granted, while the details of its actions remain confidential.
Ecosystem spotlight. Several protocols are building on CoFHE today. The wallet module enables encrypted token wrapping, allowing any ERC-20 to be shielded into a confidential fhERC-20 equivalent without modifying the underlying token. fUSD is a confidential stablecoin providing encrypted stable-value transfers for retail and institutional users. Fluton is a universal confidential execution layer enabling private cross-chain swaps, bridging, and payments via encrypted intents - no third party can observe transaction details or balances. Obolos provides a protocol-level compliance infrastructure for tokenized equity, enforcing accreditation, jurisdiction, transfer, and cap-table rules. Privara provides private stablecoin transfers on compliant rails, with privacy as the default rather than an opt-in. Alpha Engine is a confidential execution layer for Uniswap V4, enabling end-to-end private swaps and encrypted liquidity management via V4 hooks.
Fhenix's developer experience is built on a single principle: a Solidity developer who has never worked with FHE should be able to write their first encrypted contract in minutes, using tools they already know.
Solidity-native encrypted types. A single import gives any smart contract access to the full FHE operation set:
import { FHE } from "@fhenixprotocol/cofhe-contracts/FHE.sol";Encrypted equivalents of standard Solidity types - ebool, euint8 through euint128, eaddress - are available as first-class contract primitives. Arithmetic, comparison, bitwise, and conditional operations run directly over encrypted values. Access control is enforced via FHE.allow* calls that govern which addresses may reference or decrypt each ciphertext handle.
Familiar toolchain. CoFHE integrates into the standard Ethereum development stack with first-class support for both Hardhat and Foundry. Deployment scripts, test suites, and task runners follow standard conventions - there is no parallel toolchain to learn, no new VM, no new language. CoFHE currently supports Ethereum and Arbitrum.
@cofhe/sdk Client SDK. The TypeScript client SDK handles all client-side cryptography across four operations: encrypting inputs (packing plaintext values, generating a ZKPoK, and submitting them to the CoFHE verifier); decryptForView (requesting decryption via the Threshold Decryption Network using a permit and returning plaintext locally for UI display, never published on-chain); decryptForTx (requesting decryption with a verifiable Threshold Decryption Network signature for on-chain use); and permit management (creating, storing, and managing EIP-712 permits that authorize decryption of specific ciphertext handles). The SDK ships with framework-specific entrypoints — @cofhe/sdk/web for browser environments, @cofhe/sdk/node for Node.js — and adapters for Ethers v5/v6, Wagmi, and Hardhat. From the user's perspective, interaction with an FHE-enabled contract is indistinguishable from any standard web3 flow.
Mock environment. A local mock environment - @cofhe/mock-contracts - simulates the full CoFHE behavior using plaintext values, allowing developers to iterate and test contracts without any dependency on the coprocessor or Threshold Decryption Network. Moving from mock to testnet or mainnet is a single environment configuration change; no contract code changes are required.
Integration patterns. Working templates are available for the most common CoFHE use cases: encrypted ERC-20 tokens (FHERC20) with hidden balances, confidential governance with sealed voting, encrypted sealed-bid auctions, and confidential lending with hidden liquidation thresholds.
Fhenix confidential contracts. Fhenix provides production-ready confidential contract implementations that developers can use directly or extend. Two of them are token standards, and choosing between them is the main design decision a token issuer makes on Fhenix.
FHERC20 is Fhenix's confidential token standard, implementing ERC-7984. Every balance is stored as an encrypted euint64 handle and every transfer amount is encrypted, so no party — including the contract itself — can read a balance or an amount without an explicit access grant. Transfers go through confidentialTransfer, and discloseEncryptedAmount lets a party that already has access voluntarily reveal a specific amount on-chain where transparency is required.
Two design decisions separate FHERC20 from a naive encrypted ERC-20. First, it replaces the allowance model with a time-based operator system that grants transfer rights until a timestamp rather than approving a specific amount, because an approved amount is itself a leak. Second, because balanceOf must return a uint256, FHERC20 returns a small non-confidential indicator rather than the real balance, so the token registers activity in existing wallets and explorers while revealing no amounts. Three variants cover the common deployments: a base FHERC20 for new confidential tokens, FHERC20ERC20Wrapper for shielding an existing ERC-20 into a confidential equivalent, and FHERC20NativeWrapper for shielding native ETH or WETH. Six decimals is the recommended configuration, keeping balances inside euint64 range and compatible with the wrapper contracts.
import { FHERC20 } from "fhenix-confidential-contracts/contracts/FHERC20/FHERC20.sol";
contract MyConfidentialToken is FHERC20 {
constructor() FHERC20("My Confidential Token", "MCT", 6) {}
}The second standard is ERC20Confidential — also called Dual ERC20 — which gives each holder two real balances in the same contract: a public ERC-20 balance that behaves exactly as on any ordinary token, and a confidential euint64 balance exposing the same ERC-7984 surface as FHERC20. That is the essential difference between the two standards: FHERC20 is confidential-only with a decorative public face, where transfer and approve revert and balanceOf returns an indicator, whereas with ERC20Confidential the public side is a genuine ERC-20.
Value moves between the two layers by shielding and unshielding. shield() transfers public tokens into a pool and credits the caller an equal encrypted balance, so every confidential unit remains fully backed by real public tokens held in that pool. Unshielding is asynchronous: the confidential balance is burned, the burned amount is decrypted off-chain, and the holder then claims the equivalent public tokens back out of the pool. The public side may use any number of decimals while the confidential side is capped at 6 to stay within euint64. The contract is abstract: inherit it and supply your own mint and access-control logic. Fhenix's own assets use this standard — fUSD and fUSDy are dual-mode tokens.
The choice between the two standards is straightforward. A token that must trade openly on public DeFi while supporting optional private holdings uses ERC20Confidential; a token where nothing should ever be publicly visible uses FHERC20. Full API details for both standards are available in the CoFHE documentation.
import { ERC20Confidential } from "fhenix-confidential-contracts/contracts/ERC20Confidential/ERC20Confidential.sol";
// 18 public decimals; the confidential layer is capped at 6
contract MyDualToken is ERC20Confidential {
constructor() ERC20Confidential("My Dual Token", "MDT", 18) {}
}Fhenix’s roadmap follows a progressive trust-minimization and adoption path: first launching CoFHE mainnet with clearly disclosed operational assumptions, then expanding usage through confidential DeFi, and finally removing those assumptions through external Party Members, auditable compute, an economic security model, and broader ecosystem adoption.
Delivered. CoFHE mainnet is live. The initial release brings Fhenix’s core encrypted-computation stack into production: the FHE Solidity library (FHE.sol), the @cofhe/sdk TypeScript client, developer tooling, confidential token infrastructure, and the first mainnet applications built around CoFHE. On the research side, Fhenix has published two core cryptographic contributions: the threshold FHE decryption protocol accepted at ACM CCS 2025 [Zyskind, Zarchy, Leibovich, Peikert], and the dBFV high-precision FHE scheme (PZZ26).
Permissioned mainnet. The initial CoFHE mainnet release uses a permissioned trust model. Decryption-key material is split into shares held within Fhenix-operated infrastructure and protected by TEE-based controls and attestation. This is a meaningful step beyond a single exposed key, while remaining an explicitly transitional architecture rather than the final decentralized Threshold Decryption Network. The focus of this phase is functionality, stability, user experience, and clear disclosure of the trust assumptions under which early production applications operate.
Trust minimization. After mainnet, Fhenix will progressively remove operational trust assumptions. External, independently operated Party Members will be onboarded to the Threshold Decryption Network under a threshold scheme. The Trusted Dealer path will be replaced first through a public ceremony and, subject to research and implementation readiness, a full MPC-based DKG. Input validation and ciphertext commitments will move toward stronger decentralized and/or on-chain verification, while the FHE Engine becomes externally auditable through immutable protocol artifacts, with staked-operator accountability as a design option.
Economic security model. The protocol is designed so that, as the network matures, staking of a network token, slashing, operator compensation and fee mechanisms can become active parts of its security and sustainability model. Whether and when any of these is activated depends on network readiness, governance and regulatory considerations, and none is committed to in this paper. The design intent is to shift CoFHE from an operationally managed service into an economically secured network in which correct execution, availability and decryption participation are enforced by incentives and penalties.
A new FHE scheme. The Fhenix research team is developing a FHE scheme variant designed to provide materially higher transaction throughput than FHE schemes in production today. The work targets the cost of homomorphic evaluation rather than the infrastructure around it, meaning the network can serve even more encrypted compute per unit of hardware. The scheme itself builds on the ideas of PZZ26. Developers will be able to take advantage of these performance improvements following a similar integration path to what Fhenix offers today.
Performance and scale. As usage grows, Fhenix will continue optimizing CoFHE for higher throughput, lower latency, and greater operational capacity. This includes performance improvements in the FHE Engine, better batching and scheduling of encrypted operations, hardware acceleration through GPU and FPGA infrastructure, alongside the cryptographic work described above. The goal is for performance to scale with adoption, so confidential applications are not bottlenecked as usage, AUM, transaction volume, and decryption demand increase.
Multi-chain and ecosystem expansion. CoFHE will expand to additional EVM-compatible host chains, with non-EVM runtime support as a longer-term target. In parallel, Fhenix will continue improving developer tooling, wallet integrations, key-rotation and compromise-response capabilities, SDK support, and the broader confidential-application ecosystem.
Confidential DeFi expansion. The first major adoption track is confidential DeFi, with fUSD as the flagship application and settlement asset. Fhenix will focus on use cases where privacy is economically necessary: high-value transfers, whale activity, institutional DeFi, OTC settlement, treasury operations, and TradFi-facing on-chain workflows. A major part of this expansion is selective disclosure: tools that allow users, institutions, protocols, auditors, and regulators to reveal exactly what is needed to the right parties, without making all balances, positions, or transaction details public by default.
The end state is a CoFHE network where encrypted computation is available across multiple chains, fUSD anchors a growing confidential DeFi ecosystem, decryption requires independent threshold participation, execution is externally auditable, performance scales with real usage, and the protocol is designed so that network operation can be secured by economic incentives rather than Fhenix’s operational control.
Public blockchains solved the problem of trust; confidentiality is the next challenge. As financial systems, institutional capital, and complex real-world logic move on-chain, the ability to compute over encrypted state, without exposing it, relying on trusted hardware, or sacrificing composability, becomes one of this era’s defining infrastructure challenges.
FHE is the right primitive for this problem: the only approach that lets a single untrusted operator compute autonomously over shared encrypted state, with security grounded in cryptography rather than hardware. CoFHE makes it practical - a single Solidity import, familiar tooling, and a live mainnet with a clear path to progressive decentralization. And Fhenix is advancing not just the infrastructure but the underlying science: from the threshold decryption protocol validated at ACM CCS 2025 to the new FHE scheme now in development, the team is pushing the frontier of what encrypted computation can do at production scale.
Privacy in blockchain is shifting from a niche concern to an institutional prerequisite.
Build. Start with the documentation and SDK at cofhe-docs.fhenix.zone. The mock environment lets you build locally; moving to testnet or mainnet is a configuration change.
Partner. If you are a protocol or institution exploring how CoFHE can enable your use case, we are actively working with design partners to co-build the first generation of confidential applications. Reach out at fhenix.io.
Grow. Grants, bounties, and builder support are available for teams building on CoFHE. Details at fhenix.io/ecosystem.
Footnotes: