> ## Documentation Index
> Fetch the complete documentation index at: https://fhenix-docs-broken-sample-fixes.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Encryption Request Flow

> How a plaintext becomes a verified encrypted input: local encryption, ZK proof, verification, and onchain use

This page follows encrypted inputs from the plaintext in your application to handles a smart contract can compute on. Everything sensitive happens client-side: the values are encrypted and proven locally, and only the ciphertexts and their proofs ever leave the user's machine. Inputs travel as one batch, verified with a single signature that is bound to the contract that will consume them.

## Key components

| Component | Runs in | Description |
| - | - | - |
| **Your app** | Client side | The application that interacts with the user and the contracts |
| **Client SDK** (`@cofhe/sdk`) | Client side | TypeScript library that encrypts inputs locally and submits them for verification |
| **Your contract** | Host chain | Consumes the handles and the proof, and forwards them to the TaskManager |
| **[TaskManager](/deep-dive/cofhe-components/task-manager)** | Host chain | Verifies the ZK Verifier's batch signature when the inputs are used onchain |
| **[ZK Verifier](/deep-dive/cofhe-components/zk-verifier)** | CoFHE, offchain | Attested offchain component that verifies the proofs of every encrypted-input batch |
| **CT Server** | CoFHE, offchain | Stores the verified ciphertext bytes. Not drawn in the diagram; the ZK Verifier writes to it during verification |
| **[Compute pipeline](/deep-dive/cofhe-components/compute-pipeline)** | CoFHE, offchain | Picks up each `InputVerified` event and posts the commitment |
| **[CommitmentRegistry](/deep-dive/cofhe-components/commitment-registry)** | Registry chain | Records a commitment for every verified input |

## Flow diagram

<Frame>
  <img src="https://mintcdn.com/fhenix-docs-broken-sample-fixes/R2TEFe1LBG2Y-SXN/images/encryption-request-flow.svg?fit=max&auto=format&n=R2TEFe1LBG2Y-SXN&q=85&s=0bee1442eafb952e9ec6192271ad48b0" alt="Encrypted inputs travelling from your app through the Client SDK and ZK Verifier, onchain into your contract and the TaskManager, and finally anchored in the CommitmentRegistry by the compute pipeline" width="1440" height="677" data-path="images/encryption-request-flow.svg" />
</Frame>

<Tip>
  Each color in the diagram is one zone from the table above. Hover any component or message in the [explorable version](/deep-dive/data-flows/encryption-request-flow-explorable).
</Tip>

## Step-by-step flow

<Steps>
  <Step title="Install and initialize the Client SDK">
    Install and initialize the Client SDK in your project. Full details are in the [installation guide](/client-sdk/introduction/installation).

    ```bash theme={null}
    npm install @cofhe/sdk
    ```

    ```javascript theme={null}
    const { Encryptable, FheTypes } = require("@cofhe/sdk");
    const { createCofheConfig, createCofheClient } = require("@cofhe/sdk/node");
    const { chains } = require("@cofhe/sdk/chains");

    const config = createCofheConfig({ supportedChains: [chains.sepolia] });
    const cofheClient = createCofheClient(config);
    await cofheClient.connect(publicClient, walletClient);
    ```
  </Step>

  <Step title="Encrypt and prove locally">
    The application encrypts its values with a single builder call, naming the contract that will consume them:

    ```typescript theme={null}
    const [encryptedInput, proof] = await cofheClient
      .encryptInputs([Encryptable.uint32(42n)])
      .setConsumingContract(contractAddress)
      .execute();
    ```

    Internally, `encryptInputs` encrypts each value with the TFHE library and generates a zkPoK (zero-knowledge proof of knowledge) that the encryption is correct. It then submits the whole batch to the ZK Verifier. The verifier's signature is bound to the consuming contract, so the batch cannot be replayed into a different one.
  </Step>

  <Step title="Verification and storage">
    The ZK Verifier checks each proof inside its attested enclave. A valid proof shows the ciphertext is a correct, untampered encryption of a known plaintext. On success, the verifier stores the ciphertext bytes in the CT Server and returns the handles with one signature covering the batch. The SDK hands your application the tuple `[handles..., proof]`; each handle is an `external` encrypted value such as `externalEuint32`.
  </Step>

  <Step title="Use the encrypted input onchain">
    The application passes the handles and the proof to the contract as encrypted inputs. When the contract consumes them, the TaskManager's `batchVerifyInputs` checks the ZK Verifier's signature over the batch and emits an `InputVerified` event per input. The [compute pipeline](/deep-dive/cofhe-components/compute-pipeline) picks those events up and posts a commitment for each input to the CommitmentRegistry. Inputs are anchored onchain the same way every computed result is.
  </Step>
</Steps>

<Note>
  Read more about the client-side API in [Encrypting Inputs](/client-sdk/guides/encrypting-inputs).
</Note>