Encrypted state requires contracts plus an off-chain compute stack
FHEVM lets Solidity code operate on encrypted values without exposing the underlying data on the host chain. Contracts record symbolic FHE operations, and a coprocessor performs the costly encrypted computation away from the EVM. Gateway and host contracts coordinate requests, while a KMS connector participates in key handling and decryption. This split supports confidential balances, bids, votes, and game state, but it creates more moving parts than a normal contract deployment.
The repository is organized around that protocol, not one library. It contains gateway contracts, host contracts, a Rust coprocessor, KMS integration, Helm charts, golden container images, SDK code, and an end-to-end test suite. The README says encrypted integers can reach 256 bits and lists arithmetic, comparisons, Boolean operations, and conditional selection. Developers still define access control in Solidity, since encryption does not decide who may decrypt a result.
The root npm install is 2,071 MB before protocol services start
Our clean install added 2,587 packages in 154 seconds and occupied 2,071 MB. That is only the JavaScript workspace dependency layer. The checkout itself had 3,828 files, about 1,029,780 lines of source, and 110.6 MB before installation. Rust crates, Solidity toolchains, images, databases, chain nodes, and deployed services add separate costs that our npm measurement does not include.
The monorepo had 64 CI workflow files, evidence of a large release and integration matrix. Our scan found no Dockerfile and no directory literally named tests, while the documented tree does contain test-suite and golden container images. Those details are compatible: the signal scanner checks exact conventional paths, while this repository uses its own layout. Buyers should read the actual workflows and component instructions instead of judging readiness from folder names.
What happened when we ran it
In our sandbox, npm installation succeeded in 154 seconds with 2,587 packages. The root package had no build script or target, so there was no build to run. We used commit 1118538 in an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. Skipping the build is a repository result, not a successful compilation of the Rust, Solidity, or TypeScript components.
The test command failed with exit code 127 after 5 seconds. It changed into test-suite/fhevm and called bun run test; the shell answered bun: not found. The log does not show whether the tests themselves pass once Bun is installed. It shows that a fresh Node 22 environment, after the root npm install, still lacks a required test runner that the package script assumes.
Our npm audit found 108 known vulnerabilities: 3 critical, 43 high, 38 moderate, and 24 low. That scan covers the installed npm dependency tree, not Rust crates or deployed services, and it does not prove every advisory is reachable. The counts are too large to waive away. A team evaluating FHEVM should triage each critical and high finding against the exact workspace and deployment bundle it will ship.
v0.14.0 changes decryption and upgrade contracts
The latest GitHub release was v0.14.0, published August 14, 2026. Its notes describe KMS context and epoch rotation, unified user decryption, confidential bridging, coprocessor migration work, and SDK compatibility changes. The upgrade section is substantial: decryption permits move to signDecryptionPermit(), durations change from days to seconds, low-level SDK exports are removed, and contract storage gains new protocol state.
Those changes tell an operator what maturity means here. The project has release tooling and migration paths, yet protocol upgrades span contracts, SDKs, the KMS connector, relayer behavior, and coprocessor state. Version matching is part of normal operation. Pinning only the JavaScript package or only the contracts is insufficient when the services disagree about context IDs, permits, or key epochs.
Mainnet key activation can block an otherwise healthy relayer
Issue 3573 reports an integrator running a self-hosted v0.14.0 relayer against Ethereum mainnet. According to the report, listeners and the database were healthy and symbolic FHE transactions worked, but getCurrentKmsContextAndEpoch() reverted. The relayer could not initialize its v2 key URL, leaving input proofs and decryption unavailable. The issue asks which commit matches the active mainnet protocol state.
That report does not establish a universal outage, and it does not say the architecture is broken. It does show the cost of a versioned, multi-service protocol: individual health checks can pass while a required cross-component capability is unavailable. Before committing to mainnet, test encryption, proof creation, user decryption, public decryption, key rotation, and upgrade rollback against the exact hosted or self-hosted components you will operate.
Commercial use requires a separate patent decision
The code uses BSD-3-Clause-Clear, but the README adds an important limit. Zama says development, research, prototyping, and experimentation are free under that license, while commercial use of its open-source code requires a commercial patent license. The repository API therefore labels the license as Other with no SPDX assertion. Legal review belongs near the start of evaluation, before an architecture depends on FHEVM-specific contracts and services.
Contributions also have a gate: the README asks prospective contributors to contact Zama, sign its contributor license agreement, and become approved before submitting pull requests. GitHub showed 24,825 stars, 121 open issues and pull requests combined, and a push on August 27, 2026. The project is active. Its technical and licensing commitments are simply much larger than installing an ordinary Solidity package.