> ## Documentation Index
> Fetch the complete documentation index at: https://fhenix-docs-deep-dive-rewrite.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Future Plans

> Roadmap for CoFHE decentralization, upcoming features, and planned improvements

## Road to decentralization

Integrating FHE into a blockchain runtime is a hard and complex task. Our engineering philosophy is to ship fast: to build the best possible product we need to meet real users early. Similar to the approach described in [Vitalik's "training wheels" post](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571) (in the context of rollups), CoFHE ships with training wheels of its own.

Outlined here is a non-exhaustive list of trust points, centralized components, and compromises made to ship CoFHE to users as fast as possible. Each row notes how we plan to address it, and the list will be updated as things progress.

| Component   | Compromise                                                          | Plan to solve                                                                       | Status  |
| ----------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------- |
| Teecryptor  | Decryption is served by a single TEE service operated by Fhenix     | Replace with multi-party computation (below)                                        | Planned |
| Teecryptor  | Trust in the TEE hardware vendor and its attestation chain          | Multi-party computation removes the hardware trust anchor                           | Planned |
| ZK Verifier | Input proofs are checked by a single TEE service operated by Fhenix | Move to multi-party computation, with each partner verifying inputs on its own side | Planned |
| Key custody | The FHE key is reconstructed inside one attested enclave at runtime | Threshold decryption, where no party ever holds the full key                        | Planned |
| CoFHE       | Trust in CoFHE to perform correct FHE computations                  | External verification                                                               | Planned |
| CoFHE       | User inputs stored in a centralized manner                          | Use a decentralized DA                                                              | Planned |
| All         | Codebase is unaudited                                               | Perform a security audit                                                            | Planned |
| All         | Codebase is not fully open source                                   | Open-source the codebase                                                            | Planned |

One training wheel has already been narrowed: the ZK Verifier now runs inside a hardware-attested TEE, with its signing key released only to the attested code image. The enclave itself stays a trust point until the move described below.

## The path to multi-party computation

CoFHE runs two TEE services today, [Teecryptor](/deep-dive/cofhe-components/teecryptor) and the [ZK Verifier](/deep-dive/cofhe-components/zk-verifier). Both move to multi-party computation, and they move together. No TEE stays on the critical path after that.

Decryption becomes a Threshold Network. Independent parties decrypt through multi-party computation, so no single party (and no single machine) ever holds the FHE key. Robustness goals for it include a t-out-of-n protocol (no requirement that every party stays online), party share rotation, and full protocol key rotation.

Input verification follows the same model. Each partner runs ZK verification on its own side, instead of one attested enclave checking every proof and signing the batch alone.

See [Research in Fhenix](/deep-dive/research/research-in-fhenix) for the threshold decryption protocol behind this plan.

## Upcoming features

In the spirit of transparency, here is the general feature roadmap planned for CoFHE.

| Feature                      | Type    | Description                                                 | Status                |
| ---------------------------- | ------- | ----------------------------------------------------------- | --------------------- |
| RNG                          | DevX    | Secure randomness in contracts (`FHE.random`)               | Shipped               |
| Additional host chains       | DevX/UX | Multiple EVM host chains (three run on the current testnet) | Shipped, more planned |
| Hardhat and Foundry plugins  | DevX    | First-party tooling for the standard EVM dev stacks         | Shipped               |
| React SDK                    | DevX    | `@cofhe/react` hooks and components for dApp frontends      | Shipped               |
| Additional external devtools | DevX    | Remix, Alchemy SDK and more                                 | Planned               |
| GPU support                  | UX      | Run FHE operations on a GPU backend for lower latency       | In progress           |
| FPGA support                 | UX      | Run FHE operations on an FPGA backend                       | Planned               |
| FHE ops in view functions    | DevX    | Execute FHE operations in contract view functions           | Planned               |
| Alternative runtimes         | DevX    | Support for runtimes other than the EVM                     | Planned               |