Skip to main content

​
Decryption Request Flow

The process of requesting decryption through Smart Contracts starts the same as every other FHE Operation Request 📌steps 1-4 Here we’ll continue from FheOS server handling such request as follows:

​
Flow Diagram

The following diagram illustrates the complete flow of an FHE Decryption request in the CoFHE ecosystem:
End-to-end flow of an FHE Decryption request through the CoFHE system components
Figure 1: End-to-end flow of an FHE Decryption request through the CoFHE system components

​
Step-by-Step Flow

1

Steps 1-4 - FHE Operation Request

The decryption request follows the same initial steps as a standard FHE operation request:1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣Refer to FHE Operation Request Flow for details on steps 1-4, which include:
  • Integration with Cofhejs
  • Requesting an FHE Operation
  • Task Manager Processing
  • Slim Listener Processing
2

FheOS server - Decryption Execution

The FheOS server handles decryption requests:
  1. Create execution thread on the fheOS server
  2. FheOS server calls the threshold network with:
    • The ciphertext to be decrypted
    • Transaction hash from the host chain
    • Original operation handle
3

Threshold network security protocol

The Threshold Network performs secure decryption:
  • Verify the host chain requested the desired decryption
  • Retrieve the actual ciphertext hash from private storage
  • Validate ciphertext hash integrity
  • Perform secure decryption
4

Result Delivery (Two Paths)

After decryption is complete, the result can reach the chain via two paths: 7️⃣Path A — Result Processor (default):
  • FheOS calls the Result Processor with the decrypt result
  • The Result Processor publishes the result to the TaskManager on the host chain
Path B — Client-Published with Signature:
  • The Dispatcher returns the decrypt result along with an ECDSA signature to the client (via cofhejs HTTP)
  • The client (or any relayer) calls FHE.publishDecryptResult(ctHash, result, signature) on-chain
  • The TaskManager verifies the signature against the registered decryptResultSigner before storing the result
Path B enables permissionless result delivery — anyone holding a valid signature can publish. This is useful for client-driven settlement or relayer patterns.
5

TaskManager emit event with decryption result

The TaskManager finalizes the decryption process: 8️⃣
  • Provide decrypted result by emitting an event DecryptionResult
  • The event consists of ciphertext handle, result, requestor (of that decrypt operation)
  • In Path B, requestor is msg.sender (the publisher), not the original decrypt requester