Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Writing Encrypted Data to Contract

This page covers the “encrypt → write tx” flow: encrypt plaintext values into InE* structs and pass them directly into a contract call.

encryptInputs returns EncryptedItemInput objects that match the Solidity InE* input structs. The on-chain CoFHE library validates the verifier signature before the contract can use the ciphertext.

The flow is as follows:

  1. Ensure your contract function accepts encrypted InE* parameters.
  2. Encrypt the plaintext values with encryptInputs.
  3. Send a transaction and pass the encrypted structs as the InE* arguments.

Prerequisites

  1. Create and connect a client (see the client page).

  2. Your contract function must accept encrypted InE* structs.

The encrypted type you choose in JavaScript/TypeScript must match the Solidity parameter type:

  • Encryptable.uint32(...) → InEuint32
  • Encryptable.bool(...) → InEbool
  • Encryptable.address(...) → InEaddress

Example: encrypt and call a contract

The reference contract used throughout these docs is EncryptedCounter.sol. It exposes setCount(InEuint32) which is the canonical “encrypt input → send in the same transaction” flow.

Solidity
// From EncryptedCounter.sol (see /reference/encrypted-counter-sol)
function setCount(InEuint32 memory _inCount) external onlyOwner {
  count = FHE.asEuint32(_inCount);
  FHE.allowThis(count);
  FHE.allowSender(count);
  decrypted = false;
  decryptedCount = 0;
}

Common pitfalls

  • Wrong Encryptable type: the Encryptable.* factory must match the Solidity parameter type (InEuint32 vs InEuint64, etc).
  • Wrong account / chain: encrypted inputs are authorized for a specific account + chainId. If you encrypt under the wrong wallet/network, the contract call may revert.
  • ABI struct shape mismatch: if you hand-write an ABI, ensure the tuple fields are (ctHash, securityZone, utype, signature) in the same order your client library expects.