%20(16).svg)
The main paper describes the full CoFHE architecture: a progressively decentralized system for encrypted computation, threshold decryption, verifiable execution, and policy-governed access control. This appendix describes what ships at mainnet launch, where the launch architecture differs from the full target design, and how each remaining trust assumption is expected to be removed over time.
The goal is to make the launch trust model explicit. CoFHE's core privacy guarantee remains that computation is performed over ciphertexts and that the FHE Engine does not hold decryption keys or plaintexts. The differences described here concern operational decentralization, verification, economics, and the transition from the initial mainnet architecture to the full CoFHE architecture.
| Component | Full CoFHE architecture | Mainnet launch state | Transition path |
|---|---|---|---|
| Decryption key management | Threshold Network with independently operated Party Members under a T-of-N scheme | Key shares held by trusted partners' secret managers and gated by Fhenix-operated TEE attestations | Onboard external Party Members, then move toward a public ceremony and MPC-based DKG |
| Input validation | Full target ZKPoK verification model, with verification moving toward stronger decentralization and/or on-chain verification | Encrypted input validation is handled through an attested verifier path | Move verification toward a more trust-minimized path |
| FHE Engine verifiability | Externally verifiable execution with staked operators and slashing for provable misbehavior | Fhenix-operated engine; execution is deterministic and auditable after the fact | Publish required artifacts, introduce staked operators, and activate slashing conditions |
| Fee mechanism | Metered FHE operations with protocol-level fee capture | No active fee mechanism; usage is permissioned and subsidized by Fhenix | Publish and activate the fee model in the technical whitepaper |
| Staking and governance | Staking supports network security; governance controls protocol parameters and value allocation | Simple staking may exist at launch, but governance is not active at genesis | Activate mature staking, then governance over protocol parameters and fee revenue allocation |
| FHE library | dBFV integrated into CoFHE for high-precision arithmetic and improved throughput profile | Engine runs on tfhe-rs at launch | Integrate dBFV as the production cryptographic stack matures |
The main paper describes the trust model of the full CoFHE architecture. This section describes the trust model as it stands at mainnet launch. The core cryptographic guarantee is unchanged: the FHE Engine operates exclusively on ciphertexts and never holds keys or plaintexts, so no component in the computation path can read user data. What differs at launch is who operates each component and how its correct behavior is enforced.
| Component | Current state at launch | What a user must trust |
|---|---|---|
| Decryption key | Split via Shamir secret sharing across trusted partners' secret managers, gated by attestation reports from Fhenix-operated TEEs | That the threshold of partners and the Fhenix TEE attestation gate are not jointly compromised |
| Input validation | Encrypted input validation is handled by an attested verifier path rather than the full target ZKPoK verification model | The verifier's attestation, rather than multi-party consensus or on-chain verification |
| FHE Engine | Operated by Fhenix. Execution is deterministic and reproducible from published artifacts, including ciphertext commitments and events, so incorrect execution is objectively detectable | Detection is after the fact: there is no on-chain fraud proof or staked-operator slashing on day one |
| Commitment Registry | Live on Arbitrum One | Arbitrum One's security and liveness |
| Access control: Task Manager and ACL | On-chain on the host chain | The host chain itself |
In addition, the master key was generated by a Trusted Dealer whose elimination is a post-mainnet milestone, first through a public ceremony and ultimately through MPC-based DKG. Economic security via a staked operator set is not yet active. Once staking secures the network, staked value must significantly exceed the value decryptable through misbehavior, a condition that must be actively managed as encrypted state grows. Certain denial-of-service vectors, such as ciphertext fetching at scale, are being addressed through redundancy but are not yet fully resolved. Each of these assumptions maps to a committed item on the decentralization roadmap.
At launch, CoFHE does not yet run the decentralized Threshold Network described in Section 5 of the main paper. Instead, the decryption key is protected through a multi-share setup operated with trusted partners. The key is split using Shamir secret sharing, and each share is held in a trusted partner-operated secret manager. Shares are released only against a valid attestation report from Fhenix-operated TEEs, so decryption requires both partner-side share release and a validly attested Fhenix execution environment.
This is a deliberately disclosed training-wheels architecture. It provides meaningful key distribution from day one while the full Threshold Network is rolled out. The committed transition path is to onboard external, independently operated Party Members under a T-of-N scheme in which Fhenix-operated infrastructure is not sufficient to decrypt alone, followed by elimination of the Trusted Dealer through a public ceremony and ultimately a full MPC-based DKG.
At launch, encrypted input validation is handled through an attested verifier path rather than the full target ZKPoK verification model. This means malformed inputs should be rejected before registration, while the plaintext remains hidden. The remaining trust assumption is that users rely on the attested verifier service rather than on-chain verification or decentralized verifier consensus.
The roadmap moves input verification toward a more trust-minimized path. The intent is to reduce reliance on a Fhenix-operated attested service and make input validation increasingly auditable, decentralized, and/or on-chain-verifiable over time.
At launch, the FHE Engine runs on tfhe-rs. This is the production cryptographic library used for the initial mainnet release and defines the launch performance envelope, supported encrypted types, and per-operation cost profile.
dBFV, described in Section 6 of the main paper, is not yet integrated into the production engine. It should be read as the next-generation cryptographic direction for CoFHE rather than as a launch-state capability. Once integrated, dBFV is expected to improve CoFHE's ability to support high-precision arithmetic over the kinds of values DeFi applications actually use, including large balances, prices, collateral ratios, and other 64-bit-or-wider values. It also enables a stronger batching story through SIMD-style computation over many values per ciphertext.
Until dBFV is integrated, the performance and precision claims associated with dBFV should be understood as roadmap targets, not as properties of the mainnet launch system.
The full CoFHE model treats FHE operations as metered compute units, with fees designed to support protocol sustainability and operator economics. At mainnet launch, however, the final fee mechanism is not yet active. FHE operations are subsidized by Fhenix, and access is managed through a permissioned contract allowlist.
This allowlist is the interim capacity-management and abuse-prevention mechanism: contracts must be approved before they can submit CoFHE workloads. The final fee model, including metering units, supported payment assets, and any relationship to FIX or fUSD, will be published in the technical whitepaper before activation.
Staking and governance are phased into the protocol over time. At launch, staking is primarily a bootstrapping mechanism; it does not yet represent the complete economic-security layer described in the full CoFHE architecture. Governance is also not active at genesis.
As the network decentralizes, staking becomes more directly tied to operator accountability and protocol security, while governance becomes responsible for upgrades, parameter changes, and fee-revenue allocation. The detailed staking and governance model will be published with the full tokenomics documentation.
Several trust assumptions remain at mainnet launch and are intentionally disclosed.
First, the Trusted Dealer has not yet been eliminated. The long-term target is to replace this with a public ceremony and ultimately a full MPC-based DKG, but that transition depends on the relevant research and implementation path reaching production readiness.
Second, FHE Engine correctness is auditable but not yet enforced by an automated on-chain fraud-proof or slashing mechanism. Because FHE execution is deterministic, incorrect execution can be independently detected from the relevant public artifacts, but day-one enforcement is not yet the same as the full staked-operator model.
Third, the launch architecture relies on attested TEEs for parts of key-share usage and input validation. This is a meaningful improvement over a single trusted operator, but it is not the final Threshold Network trust model.
Fourth, economic security is not yet fully active. Once staking secures the network, the amount of value staked must be managed relative to the value of encrypted state that could be affected by misbehavior.
Finally, some denial-of-service risks, such as ciphertext retrieval or request handling at scale, are mitigated through operational redundancy but are not eliminated as protocol-level concerns on day one.
Each of these assumptions maps to the post-mainnet decentralization roadmap: external Party Members, Trusted Dealer elimination, verifiable FHE Engine execution, mature staking, and additional redundancy across the data and coordination layers.
For developers, the mainnet launch architecture is designed to preserve the same integration surface as the full CoFHE architecture. Contracts use the same Solidity libraries, encrypted types, access-control patterns, and SDK flows. As the system decentralizes, developers should not need to rewrite application logic to benefit from stronger trust assumptions.
For users, the core interaction model is also unchanged: inputs are encrypted client-side, encrypted state remains hidden from the host chain and the FHE Engine, and outputs are released only to authorized parties. What changes over time is not the user-facing privacy model, but the degree of decentralization and verifiability behind the infrastructure.
The practical launch limitations are operational rather than conceptual: supported chains, supported encrypted types, throughput limits, allowlisted contracts, and fee activation may be introduced or expanded in phases. These constraints are expected to relax as the network matures.