Skip to main content
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

Flow diagram

Step-by-step flow

1

Install and initialize the Client SDK

Install and initialize the Client SDK in your project. Full details are in the installation guide.
2

Encrypt and prove locally

The application encrypts its values with a single builder call, naming the contract that will consume them:
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.
3

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 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.
4

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 coprocessor picks those events up and posts a commitment for each input to the CommitmentRegistry, so the ciphertexts are anchored onchain like every computed result.
Read more about the client-side API in Encrypting Inputs.