OP_EQUAL

Byte 0x87 does the only comparison bitcoin really needs: are these two blobs identical? The comparison is on raw bytes rather than on numbers, which is why the language carries a separate opcode for arithmetic equality. Every payment you have ever sent to an address starting with 3 ends its script with this one instruction.

How it works

Two items come off the stack and one goes back on: a single byte of 0x01 when they match, or an empty item when they do not. Bitcoin treats an empty item as false, so the result can be tested by anything that follows.

Byte comparison is stricter than it sounds. Two values that a person would call the same number can be different strings of bytes, and this opcode calls those unequal. That is the correct behaviour for its real job, which is comparing hashes and preimages where any difference at all should fail, and it is why arithmetic results are compared with OP_NUMEQUAL instead.

The interesting property is what it does not do: it leaves a result rather than acting on one. A script ends successfully only when the item left on top is true, so a script that finishes with this opcode is asking a question and letting the result stand as the answer. Bitcoin Core's cleanstack rule adds that nothing else may be left behind, which for a script hash spend means exactly one true value and nothing more.

That last detail is more consequential than it looks. Pay-to-script-hash is not a general rule about hashed scripts; it is a rule about one exact 23-byte pattern, a hash opcode, a 20-byte push, and this opcode at the end. Write the same logic with the combined verify form instead and the special handling does not apply, the redeem script is never extracted or executed, and the output behaves like an ordinary hash puzzle that anyone who guesses the preimage can spend.

Where you see it

Every unspent output on an address beginning with 3 shows the same three-token assembly on a block explorer, ending here. So does every wrapped SegWit withdrawal an exchange has ever sent you.

It also appears in hash-locked contracts. Lightning's payment scripts hash a secret and compare the result to a fixed value, which is what lets a payment settle across several hops the moment the recipient reveals a 32-byte preimage. Atomic swaps between chains use the same shape.

OP_EQUAL vs OP_EQUALVERIFY

OP_EQUALVERIFY is OP_EQUAL with the test built in. Byte 0x88 performs the same comparison and then aborts the script immediately if the answer is false, leaving nothing on the stack when it succeeds. Choosing between them is a question of what comes next. Use the plain form when the comparison is the script's final answer, as pay-to-script-hash does. Use the verify form when the comparison is one condition among several and execution must continue, as the legacy single-key template does before it checks a signature. The verify form also saves a byte over writing the comparison and a separate verification instruction, which mattered a great deal more when every byte of a script sat in the non-witness part of the transaction at four weight units each.