TERM_DEF // MODULE_3_COMPARISON / OP_VERIFY
OP_VERIFY
OP_VERIFY. Fail the script if the top item is falsy.
OP_VERIFY pops the top item and fails the entire script execution if that item is falsy (empty array or negative zero). Nothing is pushed. It acts as an assertion opcode: "this must be true or the transaction is invalid." Many opcodes have VERIFY variants (OP_EQUALVERIFY, OP_CHECKSIGVERIFY) that combine the base opcode with an implicit OP_VERIFY.
This page sits in the Module 3 — Comparison section — Vocabulary introduced in the Comparison module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
OP_VERIFY pops the top item and fails the entire script execution if that item is falsy (empty array or negative zero). Nothing is pushed. It acts as an assertion opcode: "this must be true or the transaction is invalid." Many opcodes have VERIFY variants (OP_EQUALVERIFY, OP_CHECKSIGVERIFY) that combine the base opcode with an implicit OP_VERIFY.
This page sits in the Module 3 — Comparison section — Vocabulary introduced in the Comparison module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_OP_VERIFY_IS
OP_VERIFY — at a glance
MODULE 3
OP_VERIFY is a Bitcoin Script opcode in the FLOW family. Its stack effect is
x → (fail if falsy). Pop top; fail the script if it is empty/zero. Inline assertion. Fail the script if the top item is falsy.OP_VERIFY pops the top item and fails the entire script execution if that item is falsy (empty array or negative zero). Nothing is pushed. It acts as an assertion opcode: "this must be true or the transaction is invalid." Many opcodes have VERIFY variants (OP_EQUALVERIFY, OP_CHECKSIGVERIFY) that combine the base opcode with an implicit OP_VERIFY.
Why it exists
DESIGN
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Every UTXO is locked by a scriptPubKey — the output's locking script. To spend it, you provide a scriptSig (or witness) containing data that satisfies the lock. The node concatenates them, runs the combined script on a stack machine, and accepts the spend if and only if execution finishes with a single truthy value on the stack. OP_VERIFY contributes a specific stack effect within that process — opcodes either push, pop, copy, hash, branch, or verify, and they do so left-to-right deterministically.
1. The script is parsed into a sequence of opcodes and push-data items.
2. Execution starts with an empty stack and an empty alt-stack.
3. Each opcode runs in order — push opcodes add to the stack, others consume the top items and may push results.
4. When OP_VERIFY is reached, it performs its specific stack effect (see below).
5. Final state: a single non-zero (truthy) value on top → the spend is authorised. Anything else (empty stack, false, error) → the script fails and the tx is rejected.
WORKED_EXAMPLE
OP_VERIFY — stack effect + canonical use
EXAMPLE
Opcode : OP_VERIFY
Family : FLOW
Stack effect: x → (fail if falsy)
Behaviour : Pop top; fail the script if it is empty/zero. Inline assertion.
Open /playground in another tab and search for OP_VERIFY.
Drag the opcode in, watch the stack visualisation step through it
against any combination of inputs you choose.
KEY_PROPERTIES
FAMILY
Belongs to the FLOW family of Script opcodes — siblings share validation rules and historical evolution.
STACK EFFECT
Exactly x → (fail if falsy). Every full node enforces the same effect, byte-for-byte.
ACTIVE
Active on mainnet today; every spend that uses it is being validated by every full node.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- Opcode semantics are consensus — verify against the latest Bitcoin Core source before relying on any subtle behaviour.
RELATED_CONCEPTS
Other terms from Module 3 — Comparison — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
OP_VERIFY
Fail the script if the top item is falsy.
Boolean
True or false; in Script any non-zero, non-negative-zero is true.
OP_EQUAL
Pop two items; push 1 if identical bytes, else 0.