> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/scripts-with-flow-control-conditional-clauses.md).

# Scripts with Flow Control (Conditional Clauses)

Conditional clauses are implemented in Bitcoin script using IF/NOTIF statements. There are several varieties of these clauses that can be used to build if statements in Bitcoin. Conditional clauses use the third stack in the Script validation engine to manage nested conditions making sure that OP\_ELSE or OP\_ENDIF statements which are nested inside OP\_ELSE conditional outcomes do not terminate the parent loop.

1. OP\_IF, OP\_NOTIF OP\_IF will execute the set of subsequent opcodes up-to the following OP\_ELSE or OP\_ENDIF if the value on top of the stack is True, or NON-ZERO. Similarly, OP\_NOTIF will execute the set of subsequent opcodes up-to the following OP\_ELSE or OP\_ENDIF if the value on top of the stack is FALSE, or ZERO. If an OP\_ELSE is the subsequent conditional clause and the first conditional clause was successful, the script will jump forward to the OP\_ENDIF at the conditional-stack height of the original clause. the script will jump to the subsequent opcode following the else on a failure of the conditional entry. The loop concludes after an OP\_ENDIF is processed.
2. OP\_VERIF, OP\_VERNOTIF **NOTE: OP\_VERIF and OP\_VERNOTIF are currently disabled in the BitcoinSV mining client and transactions that use them in executed script will fail** OP\_VERIF will execute the set of subsequent opcodes up-to the following OP\_ELSE or OP\_ENDIF if the value on top of the stack matches the protocol VERSION. Some, or all network nodes may refuse to evaluate certain protocol versions meaning transactions using these parameters must be careful. Similarly, OP\_VERNOTIF will execute the set of subsequent opcodes up-to the following OP\_ELSE or OP\_ENDIF if the value on top of the stack does not match the protocol VERSION indicated in the transaction serialisation string. Similarly to OP\_IF/OP\_NOTIF, ifan OP\_ELSE is the subsequent conditional clause and the first conditional clause was successful, the script will jump forward to the OP\_ENDIF at the conditional-stack height of the original clause. the script will jump to the subsequent opcode following the else on a failure of the conditional entry. The loop concludes after an OP\_ENDIF is processed.
3. Example 1 The following example uses IF, ELSE and ENDIF statements to manage four possible ScriptSigs which can unlock this output. ScriptSig1: 1 ScriptSig2: 2 ScriptSig3: 3 ScriptSig4:\
   The first three are PKH signatures with a numeric signal to show which conditional loop to enter for evaluation. Depending on which numeric signal is present, the script will enter the relevant height conditional clause. Each subsequent conditional IF statement is nested inside the else statement of the preceding level. If no numeric signal is present, the script goes into the third level else statement where the ScriptSig is tested against an R-Puzzle Hash and the script exits the loops. DUP 1 EQUAL IF DROP DUP HASH160 EQUALVERIFY CHECKSIG ELSE DUP 2 EQUAL IF DROP DUP HASH160 EQUALVERIFY CHECKSIG ELSE DUP 3 EQUAL IF DROP DUP HASH160 EQUALVERIFY CHECKSIG ELSE OVER 3 SPLIT SWAP DROP 1 SPLIT SWAP SPLIT DROP HASH160 EQUALVERIFY CHECKSIG ENDIF ENDIF ENDIF
4. Example 2 In this example, three possible ScriptSigs are accomodated. The entry to the conditional clauses is based on the depth of the stack subsequent to the processing of the ScriptSig. ScriptSig1:\
   ScriptSig2: 1\
   ScriptSig3:\
   Either of the first two ScriptSigs are evaluated in their own separate IF loops which exit using RETURN statements. If the ScriptSig has a stack depth that doesn't match either of the requirements, it passes through to a final evaluation which must have a different signature and a backup password. DEPTH 2 EQUAL IF DUP HASH160 EQUALVERIFY CHECKSIG RETURN ENDIF DEPTH 4 EQUAL IF 5 CHECKMULTISIG RETURN ENDIF DUP HASH160 EQUALVERIFY CHECKSIGVERIFY SHA256 EQUAL RETURN


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/scripts-with-flow-control-conditional-clauses.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.