CoFHE Architecture update: Scalable, Queue-Driven Encrypted Execution

CoFHE has been upgraded from a monolithic “aggregator” into an explicit, queue-driven execution pipeline with clear separation between validation, computation, publishing, and decryption.

What changed:

• The former Aggregator is now an explicit pipeline: event ingestion → validation → queued execution → result publishing.
• The former fheOS server is split into:
  • a single-instance control plane (input verification + lifecycle tracking), and
  • a scalable data plane for batched FHE computation.
• Message queues and DLQs are first-class primitives, defining retry and failure behavior explicitly.
• FHE execution is batched (e.g. 100 operations per worker) for higher throughput under load.
• Result publishing is handled by a dedicated service, decoupled from compute.
• Threshold decryption is modeled as an explicit, asynchronous request-and-poll lifecycle.
• Storage is concrete and inspectable (PostgreSQL + GCS), replacing abstract “DA layer” assumptions.

What this means for developers:

• Encrypted operations have a deterministic async lifecycle instead of opaque background execution.
• Failures are visible and debuggable (retry vs terminal error).
• High-volume workloads scale without changing contracts or client code.
• Decryption is a first-class, supported async pattern, both on-chain and off-chain.

These changes do not alter existing contracts or encrypted types. They materially improve scalability, reliability, and developer experience without introducing migration friction.

Developer Impact

Clear, Deterministic Async Mental Model

Encrypted computation is inherently asynchronous. By making queues, stages, and state transitions explicit, developers can reason about encrypted operations as:

submitted → validated → queued → executing → completed → published

instead of treating FHE execution as a black box.

Actionable Debugging and Failure Modes

Retries, backpressure, and terminal failures are now explicit:

• Pending inputs are retried automatically.
• Missing inputs route to a Dead Letter Queue (Although this is less common).
• Execution state is persisted and inspectable.

This eliminates silent stalls and makes failures reproducible during development and production.

Higher Throughput Without Contract Changes

Batched FHE execution allows the system to process large volumes of encrypted operations efficiently.

Developers building:

• trading systems,
• games,
• batch-heavy hooks,
• or high-traffic applications

benefit from higher throughput and reduced queue congestion without modifying contracts or client logic.

Clean Separation Between Compute and Chain Latency

Encrypted computation and on-chain publishing are decoupled.

This means:

• successful FHE execution is not blocked by RPC congestion,
• publishing failures are isolated and retryable,
• frontends can distinguish “compute done” from “tx still pending.”

First-Class Off-Chain Decryption Pattern

Off-chain decryption is an intentional, supported workflow:

• permit-based authorization,
• immediate request acknowledgment,
• polling-based result retrieval,
• identical MPC security to on-chain decryption.

This enables safer UX patterns and avoids unnecessary on-chain decrypt transactions.

Safer, Canonical Encryption Ingress

Client-side encryption with zk-verified proofs and signed attestations establishes a clear, verifiable entry point for encrypted inputs.

Developers no longer need to guess:

• what constitutes a valid encrypted value,
• how to prove correctness,
• or how inputs are trusted on-chain.

No Changes to Core Developer Primitives

Encrypted types, ACLs, permits, and sealing/unsealing semantics remain unchanged.

Developers get a more predictable, scalable, and debuggable system — without rewriting contracts or rethinking their encryption model.

High-Level System Model

CoFHE is composed of three cooperating layers:

1. On-chain layer (EVM)Smart contracts using FHE.sol emit encrypted operation requests and receive results.
2. Off-chain coprocessorA microservice-based, scalable execution environment that validates requests, executes FHE operations, and publishes results.
3. Threshold network (MPC)A distributed decryption plane that performs secure, threshold-based decryption when explicitly requested.

On-Chain Layer

Smart Contracts (EVM)

Smart contracts integrate CoFHE via the FHE.sol library and follow a consistent pattern:

• Accept encrypted user inputs (InEuint, InEbool, etc.)
• Convert inputs to encrypted values (euintX)
• Compose encrypted operations (arithmetic, comparisons, select)
• Emit events describing requested operations
• Enforce access control over ciphertext handles (ACL)

Contracts never decrypt values during normal execution. All encrypted state is represented by handles referencing ciphertext stored off-chain.

User (Web3 Client)

The user (via a dApp) is responsible for:

• Encrypting inputs client-side
• Managing permits for authorized decryption
• Submitting transactions to contracts
• Optionally requesting off-chain decryption of results

Client-side logic is implemented using cofhejs.

Off-Chain Coprocessor

The coprocessor is implemented as a message-driven pipeline composed of specialized services with clearly scoped responsibilities.

This decomposition is intentional: validation, computation, and publishing have very different scaling and failure characteristics.

Event Ingestion

slimlistener (per chain)

• One listener per supported EVM chain
• Subscribes to CoFHE-related on-chain events
• Normalizes encrypted operation payloads
• Forwards them into the queue backbone

This allows a single coprocessor deployment to support multiple chains concurrently.

FHE Computation Core

FHEOS — Input Verifier (Single Instance)

FHEOS acts as the control plane for encrypted computation.

It:

• Consumes events
• Verifies that referenced inputs exist and are well-formed
• Creates a placeholder record in persistent storage to track lifecycle
• Publishes validated jobs

Engine — FHE Operations (Scalable)

The Engine is the data plane responsible for FHE execution.

• Executes homomorphic operations over encrypted data
• Persists encrypted results to storage

Decision logic is explicit:

• Inputs ready → execute
• Inputs pending → requeue
• Inputs missing → DLQ

Result Publishing

The Result Processor is responsible solely for posting results back on-chain.

It:

• Consumes responses from fheos
• Submits transactions to the appropriate chain
• Handles retries and confirmation tracking

This separation decouples FHE throughput from blockchain transaction latency.

ZK Verifier (Encryption Ingress)

The ZK Verifier validates encrypted user inputs before they enter the system.

It:

• Receives ciphertext + zk proof from users
• Verifies proof correctness without decryption
• Returns a signed attestation (handle + metadata) to the user

Only verified inputs are usable by contracts.

Execution Flows

On-Chain FHE Computation

1. Contract emits encrypted operation event
2. slimlistener ingests event
3. FHEOS validates request and creates placeholder
4. Engine executes encrypted computation
5. Result Processor publishes encrypted result on-chain

Threshold Decryption (On-Chain)

1. Engine submits decrypt request to Dispatcher
2. MPC ceremony is executed
3. Result stored in TN-DB
4. Engine retrieves result and publishes on-chain

Threshold Decryption (Off-Chain)

1. User submits permit + handle to Dispatcher
2. MPC ceremony executed
3. Result stored in TN-DB
4. User polls and retrieves plaintext

Encryption & Input Submission

1. User encrypts input and generates zk proof
2. ZK Verifier validates proof
3. Ciphertext persisted; proof archived
4. User receives signed handle for contract usage

‍