diff --git a/docs.json b/docs.json
index 7475f23..894fadc 100644
--- a/docs.json
+++ b/docs.json
@@ -111,6 +111,7 @@
               "fhe-library/core-concepts/data-evaluation",
               "fhe-library/core-concepts/encrypted-operations",
               "fhe-library/core-concepts/conditions",
+              "fhe-library/core-concepts/require",
               "fhe-library/core-concepts/access-control",
               "fhe-library/core-concepts/decryption-operations",
               "fhe-library/core-concepts/randomness",
diff --git a/fhe-library/core-concepts/conditions.mdx b/fhe-library/core-concepts/conditions.mdx
index 3d4637c..bec1a15 100644
--- a/fhe-library/core-concepts/conditions.mdx
+++ b/fhe-library/core-concepts/conditions.mdx
@@ -1,5 +1,5 @@
 ---
-title: "Conditions"
+title: "Conditions (if .. else)"
 description: "Understanding why if..else isn't possible with FHE and exploring the alternatives"
 ---
 
@@ -135,6 +135,26 @@ euint32 feeRate = FHE.select(isPremiumUser, PREMIUM_FEE, STANDARD_FEE);
 euint32 totalFee = FHE.mul(amount, feeRate);
 ```
 
+### 6. Require
+
+Simulate `require` statements by using encrypted zero when a condition fails:
+
+```solidity
+// Check if user has sufficient balance
+ebool hasSufficientBalance = userBalance.gte(amount);
+
+// If condition fails, use encrypted zero; otherwise use the actual amount
+euint32 transferAmount = FHE.select(hasSufficientBalance, amount, FHE.asEuint32(0));
+
+// Process the transfer (will be zero if condition wasn't met)
+userBalance = userBalance.sub(transferAmount);
+recipientBalance = recipientBalance.add(transferAmount);
+```
+
+<Note>
+This pattern simulates transaction invalidation by using encrypted zero when conditions aren't met, effectively making the operation a no-op while maintaining constant-time execution. Learn more in the [Require](/fhe-library/core-concepts/require) guide.
+</Note>
+
 ---
 
 ## Best Practices
diff --git a/fhe-library/core-concepts/require.mdx b/fhe-library/core-concepts/require.mdx
new file mode 100644
index 0000000..a966f9a
--- /dev/null
+++ b/fhe-library/core-concepts/require.mdx
@@ -0,0 +1,58 @@
+---
+title: "Require"
+description: "Understanding require statements with encrypted data in FHE"
+---
+
+## Overview
+
+The `require` statement in FHE contracts works similarly to [Conditions (if .. else)](/fhe-library/core-concepts/conditions) because both involve conditional logic on encrypted data. Just as you can't use traditional `if...else` statements with encrypted values, you also can't directly use `require` statements with encrypted booleans.
+
+<Warning>
+Traditional `require` statements cannot evaluate encrypted conditions directly. You must decrypt the condition first or use alternative patterns.
+</Warning>
+
+---
+
+## Why Require is Similar to Conditions
+
+Both `require` and conditional statements face the same fundamental challenge in FHE:
+
+<CardGroup cols={2}>
+<Card title="Encrypted Evaluation" icon="lock">
+The condition being checked is encrypted, so the contract cannot directly evaluate whether it's true or false.
+</Card>
+
+<Card title="No Direct Branching" icon="code-branch">
+Both require branching logic that reveals information about encrypted data, which breaks FHE's privacy guarantees.
+</Card>
+</CardGroup>
+
+---
+
+## Working with Require in FHE
+
+Since decryption is asynchronous, you cannot use traditional `require` statements with encrypted conditions in the same transaction. Instead, simulate the behavior by using encrypted zero when conditions fail:
+
+```solidity
+// Check if user has sufficient balance
+ebool hasSufficientBalance = userBalance.gte(amount);
+
+// If condition fails, use encrypted zero; otherwise use the actual amount
+euint32 transferAmount = FHE.select(hasSufficientBalance, amount, FHE.asEuint32(0));
+
+// Process the transfer (will be zero if condition wasn't met)
+userBalance = userBalance.sub(transferAmount);
+recipientBalance = recipientBalance.add(transferAmount);
+```
+
+<Note>
+This pattern simulates transaction invalidation by using encrypted zero when conditions aren't met, effectively making the operation a no-op while maintaining constant-time execution and privacy.
+</Note>
+
+---
+
+## Related Topics
+
+- Learn more about conditional logic in [Conditions (if .. else)](/fhe-library/core-concepts/conditions)
+- Understand decryption in [Decryption Operations](/fhe-library/core-concepts/decryption-operations)
+- Explore access control in [Access Control](/fhe-library/core-concepts/access-control)