Skip to main content
CoFHE (Coprocessor for Fully Homomorphic Encryption) lets smart contracts compute on encrypted data. Contracts request operations through onchain calls; a set of offchain services executes them and commits to the results. Data stays encrypted until an authorized decryption, and every result can be verified against an onchain commitment.

The onchain contracts

  • FHE.sol: the Solidity library your contract imports. It exposes arithmetic, comparison, and logical operations on encrypted values, plus access control (allow, allowGlobal) and decrypt-result verification.
  • TaskManager: the gateway for all FHE operation requests. It validates requests, emits task events for the offchain services, and manages permissions through the ACL.
  • ACL: the access control contract. It records who may use or decrypt each handle; all writes to it go through the TaskManager.
  • PlaintextsStorage: stores decrypted results after they are published onchain with a verified Teecryptor signature.
  • CommitmentRegistry: lives on a dedicated registry chain and records a hash commitment for every ciphertext the coprocessor produces or verifies. Teecryptor checks it before decrypting anything.

The offchain components

  • Client SDK (@cofhe/sdk): the TypeScript library applications use to encrypt inputs, manage permits, and decrypt outputs.
  • ZK Verifier: a standalone service that verifies encrypted inputs in batches. It checks each zero-knowledge proof, stores the ciphertexts, and signs one approval for the whole batch.
  • FHE Engine: the execution pipeline. It subscribes to TaskManager events, validates and orders operations, runs them on encrypted data, and posts a commitment for every result.
  • Ciphertext store: the database that holds every ciphertext, fronted by the CT Server. The ZK Verifier writes verified inputs, the FHE Engine reads operands and writes results, and Teecryptor fetches bytes to decrypt.
  • Teecryptor: the decryption service. It runs inside a hardware-attested TEE, authorizes every request against the onchain ACL, verifies the ciphertext commitment, and returns signed or sealed results.
  • Partners: independent custodians of the key material. Each holds a Shamir share and releases it only to an attested enclave. See Key Management.

Data flows

  1. Encryption request: an input is encrypted client-side and proven valid with a zero-knowledge proof before it enters the chain.
  2. FHE operation: a contract requests a computation; the coprocessor executes it and commits to the result.
  3. Decryption: the SDK asks Teecryptor to decrypt a handle, either as a signed plaintext for onchain publication or sealed to a permit for offchain reads.

Future plans

Two components run inside hardware-attested TEEs today: Teecryptor, which decrypts, and the ZK Verifier, which checks input proofs. Both move to multi-party computation in one planned step. See Future Plans.