Fhenix / CoFHE: hardware trust, audit scope and unpriced dilution

Problem/Question Can Fhenix make confidential applications practical on existing EVM chains, and what evidence is still missing before evaluating a possible native-token investment? CoFHE targets exposed balances, bids and contract state. Its appeal is keeping familiar Solidity tooling while moving expensive encrypted computation offchain. This is a product-research case, not a recommendation to buy a token. [1] Data & Evidence CoFHE contracts operate on handles referencing encrypted values. The client SDK encrypts inputs; the offchain pipeline computes; access controls gate decryption. This supports confidential application state without requiring migration to a dedicated FHE chain. It does not establish anonymity or remove every trust assumption. [1,2] Current security architecture Teecryptor runs in Intel TDX. Six custodians hold Shamir shares; three shares reconstruct the full FHE key inside one attested enclave at startup. The key exists there during runtime. Threshold-MPC decryption is a future replacement, not the current design described in this component documentation. Hardware attestation and approved code images are therefore security dependencies. [2] Code and audit scope The project repository reports a September 2026 Consensys Diligence engagement, fixes completed on 2 September and release 1.0.0. This is the project’s audit summary, not an independently inspected auditor report. Finding 5.15 accepts that approved operators can read exact holder balances. FHERC20ERC20WrapperUUPS and FHERC20NativeWrapperUUPS are explicitly outside the audit scope. An audited library is not a blanket assurance for every deployment or integration. [3] Team and funding signals The official Series A announcement reports $15M and names institutional investors. It describes an earlier L2 design, so current architecture claims above use current CoFHE docs instead. Founder Guy Zyskind’s own site identifies Fhenix and links his MIT dissertation and publications. Those are inspectable identity/research signals, not independent proof of operating performance, legal compliance or future delivery. [4,5] Eligibility and source limits Across the official sources listed below, no public Fhenix token sale or active ICO/TGE was identified. The materials disclose no native-token supply, allocation or vesting schedule. The official funding announcement establishes a $15M institutional Series A, not a public-sale history. These are findings from the reviewed sources, not proof that an undisclosed public raise or launchpad agreement cannot exist. Product mainnet plans and confidential-token standards are not native-token TGE announcements. [1,3,4,7] Interpretation: tokenomics and dilution No verified native-token price, maximum/total supply, circulating supply, allocation split, cliff dates, linear vesting or emission schedule was located in the reviewed sources. FDV and circulating market cap are therefore not calculable, rather than zero. The FHERC20 application-token standard is not evidence of a Fhenix native-token launch. [1,3] Scenario model, not Fhenix tokenomics Illustration only: assume 1B capped tokens, $0.10 per token and 100M circulating at launch. FDV = $100M; circulating market cap = $10M. If a 200M team/investor allocation has a 12-month cliff followed by 24 equal monthly releases, each release adds 8.33M tokens. The first release equals 8.33% of starting float; after 12 releases float doubles to 200M, holding all other flows constant. At unchanged circulating market cap, price would halve to $0.05. That is a sensitivity case, not a forecast. A 200M one-shot cliff would instead raise float to 300M immediately. Minting, burns and other allocations must be modeled separately. Risks and decision gates Technical: hardware compromise, key-custodian availability, access-control mistakes and operator balance visibility can undermine the privacy users expect. The general explainer’s “no trusted hardware” language conflicts with the current Teecryptor description; current component documentation should take precedence pending reconciliation. [2,3,6] Execution/governance: inspect deployment addresses, release versions, upgrade owners and emergency controls before using funds. The audit summary does not cover every wrapper. Confirm actual throughput, cost and availability instead of treating research results as production benchmarks. [2,3] Incentives/legal: no reviewed native-token economics establishes fee capture or holder rights. Confidential amounts also do not automatically conceal addresses, timing or interaction patterns, and they do not remove an application’s compliance obligations. These are unresolved investment and operational risks, not a finding of unlawful conduct. [6] Conclusion Keep Fhenix on a technical research watchlist. Published code and documentation make the product thesis inspectable, but do not establish a token valuation. Before underwriting a token position, require supply and vesting schedules, token rights, deployment-specific audit coverage and clear upgrade/key-custody controls. This report submits the linked evidence and its limits for review; it does not assert prior approval or guaranteed eligibility. Disclosures Research contributor gookbab. reports no Fhenix tokens, equity, investment rights, points or project-specific compensation, and no current plan to buy or sell. The only incentive for this work is possible Republic quest rewards. This disclosure concerns the research contributor, not other squad members. Primary sources [1] CoFHE introduction (checked 19 Oct) [2] Teecryptor (checked 19 Oct) [3] Contract audit summary (checked 19 Oct) [4] Series A announcement (checked 17 Oct) [5] Founder biography (checked 17 Oct) [6] FHE explainer (checked 17 Oct) [7] Official homepage (checked 19 Oct) Not investment advice.