Skip to main content

​
Overview

The require statement in FHE contracts works similarly to Conditions (if .. else) because both involve conditional logic on encrypted data. Just like you can’t use traditional if...else statements with encrypted values, you also can’t use standard require statements that depend on encrypted conditions.
Traditional require statements that check encrypted conditions will leak information about your encrypted values through execution paths.

​
Why Require is Like Conditions

Both require and conditional statements face the same fundamental challenge in FHE:

Encrypted Evaluation

The condition being checked is encrypted, so the contract can’t directly evaluate it to decide whether to revert.

Information Leakage

If a transaction reverts based on an encrypted condition, observers can infer information about the encrypted data.

​
The Solution

Instead of using require with encrypted conditions, you should:
  1. Use FHE.select to handle the conditional logic (see Conditions (if .. else))
  2. Only use require for non-encrypted conditions like access control checks, address validation, or other plaintext values
// Good - require on plaintext condition
require(msg.sender == owner, "Not authorized");

// Good - use select for encrypted logic
euint32 result = FHE.select(encryptedCondition, valueA, valueB);

// Bad - require on encrypted condition leaks information!
require(FHE.decrypt(encryptedValue.gt(threshold)), "Value too low");

​
Learn More

For detailed guidance on handling conditional logic with encrypted data, see the Conditions (if .. else) page.