Glossary / Developer reference
OP_EQUALVERIFY
- Definition
- OP_EQUALVERIFY compares the top two stack items and kills the script instantly if they differ, which is how a legacy spend proves it presented the right public key.
Byte 0x88 is the checkpoint in the middle of bitcoin's oldest script template. It leaves nothing behind when it passes and stops execution dead when it fails, so an input that supplies the wrong key does not produce a failed payment, it produces an invalid transaction that no node will relay. Whether your wallet signed with the right key at all is usually decided here.
How it works
OP_EQUALVERIFY takes two items off the stack, compares them byte for byte, and either continues in silence or ends the script.
By the time it runs in a legacy spend, the stack holds two 20 byte strings. One is the fingerprint the output committed to when the coins arrived, possibly years earlier. The other is the fingerprint of the public key the spender has just supplied. A single differing bit across those 20 bytes ends the evaluation, and there is no recovery from it: Bitcoin Script has no exception handling and no second attempt.
Success pushes nothing back. That is the whole reason the fused form exists, and it is why the 25 byte pay-to-public-key-hash script can finish on a signature check rather than on a leftover boolean nobody wants. Bitcoin Core's interpreter implements the fusion literally, running the comparison case and then falling through into the general assertion case, so the two are one code path rather than two similar ones.
The pattern repeats across the language. Every fused verify opcode sits exactly one byte above its plain counterpart: 0x87 and 0x88 for equality, 0xac and 0xad for signature checking, 0xae and 0xaf for the old multisig opcode. Where a condition has to hold before anything else can happen, script authors reach for the higher byte.
Where you see it
The clearest place to meet OP_EQUALVERIFY is a rejection message rather than a block explorer.
Broadcast a transaction signed with a key that does not match the address and Bitcoin Core answers with mandatory-script-verify-flag-failed, naming the failed OP_EQUALVERIFY operation in the parenthesis that follows. In practice that error nearly always means one thing: the signing device derived its key from a different path or a different seed than the one that owns the coins. Restoring a wallet under the wrong derivation path and then trying to spend produces exactly this.
Decoded scripts show it plainly too. Any output paying an address that begins with 1 renders as a five token script with this opcode fourth, and bitcoin-cli decodescript prints the same assembly for a redeem script you paste in.
OP_EQUALVERIFY vs OP_VERIFY
OP_EQUALVERIFY is a specific test with an assertion welded on, and OP_VERIFY is the assertion by itself. The general form, byte 0x69, knows nothing about what produced the value it examines; it pops a single item and demands that the item be true. OP_EQUALVERIFY performs the comparison and the demand together in one byte, which is why the two are rarely written out separately. Reach for the general form when the condition comes from arithmetic, a timelock check, or a preimage test that is not a plain equality. Reach for the fused form whenever the question really is whether two byte strings match, which in a single key spend it always is.