> ## 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.
# ZK Verifier
> Offchain component that verifies user inputs using Zero-Knowledge Proofs of Knowledge (ZKPoK) to ensure encrypted data is safe to use in smart contracts
**ZK Verifier** checks every encrypted input before it can enter a confidential smart contract.
| Aspect | Description |
| - | - |
| **Type** | Offchain component running inside a hardware-attested TEE. |
| **Function** | Verifies the user's input, ensuring that it is safe to use. |
| **Responsibilities** | • Receives users' ZKPoKs for their input batches.
• Verifies those proofs.
• Signs one approval per verified batch.
• Stores the verified ciphertext bytes. |
## Why ZKPoK?
A **Zero-Knowledge Proof of Knowledge (ZKPoK)** lets a user prove they know the plaintext behind an encrypted input, without revealing that plaintext.
ZKPoKs protect against potential malicious vectors, including:
1. **Malleability attacks**: Without ZKPoK protection, attackers could transform observed ciphertexts into new valid-looking ones without knowing their contents, for example by combining them with encrypted zeros.
2. **Chosen ciphertext attacks (CCAs)**: Attackers submit modified ciphertexts and observe the results, potentially exploiting homomorphic operations to infer sensitive information or even recover the secret key.
Requiring a ZKPoK for each encrypted input is what makes it safe to run an encryption system in a public runtime like a blockchain. Only someone who knows the original plaintext can produce a valid proof.
## Sending encrypted inputs
When providing ciphertexts as an input to a smart contract, users have to generate a ZKPoK and get a verification approval first. The Client SDK (`@cofhe/sdk`) and `FHE.sol` handle most of this work; the mechanism is described here end to end (also in the diagram below).
Color marks the zone. Your app and the Client SDK run client side, your contract and the TaskManager on the host chain. The ZK Verifier and compute pipeline run offchain inside CoFHE, and the CommitmentRegistry sits on the registry chain. Hover any component or message in the [explorable version](/deep-dive/cofhe-components/zk-verifier-explorable).
The process of sending inputs to a smart contract:
1. Your app encrypts the inputs through the Client SDK, which generates a ZK proof of knowledge for each one.
2. The Client SDK sends the ciphertexts and proofs to the ZK Verifier, as one batch.
3. The ZK Verifier verifies each proof. If all are valid, it stores the encrypted values in the CT Server and signs one message approving the whole batch.
4. The ZK Verifier returns the handles and the batch approval to your app.
5. Your app sends the handles and the approval as inputs to a contract call.
6. The TaskManager verifies the batch signature and emits `InputVerified` 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](/deep-dive/cofhe-components/commitment-registry), so the input becomes decryptable later.
7. The contract performs the actual logic.
Most of this process is abstracted away. Steps 1 to 6 all happen behind the SDK and library calls, while step 7 (the actual logic) is up to you to write.
## Trust model
The ZK Verifier runs inside a hardware-attested TEE (Intel TDX). Its signing key is held as Shamir shares by independent partners and released only to the exact attested code image. Neither the operator nor anyone else can sign approvals outside the reviewed program. See [Key Management](/deep-dive/cofhe-components/key-management) for how shares are created and released. After a successful verification, the component stores the ciphertext bytes in the CT Server. It also archives the inputs and their proofs in a public Google Cloud Storage bucket for independent auditing.
The signed message is verified onchain by the TaskManager using `ecrecover`; the verifier's signer address is registered there as `verifierSigner`.
## Signature format
For developers integrating without the SDK, the signature covers a batch digest. Each input is hashed, the hashes are concatenated in input order, and the digest of that concatenation is signed:
```text theme={null}
h_i = keccak256(ct_hash (32 bytes) || utype (1 byte) || security_zone (1 byte)
|| sender (20 bytes) || chain_id (32 bytes, big-endian) || consuming_contract (20 bytes))
digest = keccak256(h_0 || h_1 || ... || h_n)
```
The digest binds the sender and the consuming contract, so a verified batch cannot be replayed by another account or into another contract. The `recid` value the component returns (0 or 1) must be adjusted to 27 or 28 for Solidity's `ecrecover`.