Official whitepaper artifact already saved locally:
zama-fhevm-whitepaper.pdf
Key takeaways from primary sources
FHEVM is worth separating from the broader Zama entry because it is the framework layer where the architecture becomes crisp: encrypted Solidity types and ACL flows onchain, actual FHE computation offchain, and gateway / TKMS layers as the operational choke points.
The most reusable mechanism insight is the handle-based execution model. Contracts manipulate encrypted handles and emit events onchain, while ciphertext computation, verification support, and decryption plumbing happen across coprocessor and gateway infrastructure.
The docs make clear that confidentiality policy is not just the chain is private. It is programmable: contracts choose who can access ciphertexts, when decryption is allowed, and how external encrypted inputs are admitted.
The quick-start flow matters because it shows FHEVM is trying to minimize developer-friction by turning ordinary Solidity into confidential Solidity rather than forcing a wholly different language or app model.
Compared with TEE-heavy systems, the core pitch is verifiable encrypted computation via FHE plus MPC-backed key management rather than enclave trust. Compared with privacy L2s, the main appeal is middleware-style deployment on existing EVM-compatible chains.
The README FAQ is a real adoption signal: open-source development use is broad, but commercial deployment depends on Zama’s separate patent license. That means commercialization rights remain a practical governance surface around the framework even if the code is publicly available.
Specific source signals worth retaining
README: best compact summary of the repo structure and the split between contracts, coprocessor, KMS connector, deployment charts, and end-to-end tests.
Library overview: clearest short explanation of encrypted types, handle semantics, FHE operations, encrypted branching, external-input attestation, and ACL methods.
Litepaper: strongest high-level statement that the surrounding protocol is intended as a confidentiality layer on existing chains rather than a new standalone chain.
ask architecture answers: useful because they condense gateway, host-contract, coprocessor, and TKMS responsibilities into a control-plane map quickly.
Quick-start ask answer: useful because it makes the asynchronous-decryption and proof-verification workflow explicit for developer UX analysis.
Why this entry belongs in the corpus
It gives the confidential-execution cluster a stronger lower-layer comparison point beneath the broader Zama brand.
It is a good contrast case for Fhenix, Oasis Sapphire, and TEN because it separates encrypted contract programming, offchain compute, gateway policy, and key management more explicitly than a generic private smart contracts label would.
The reusable insight is that confidential-smart-contract systems often centralize power not only in cryptography choice, but in the bridge between onchain symbolic state and offchain compute/key services.