OP_DROPProtocol
Press the slash key to focus search.

Bitcoin Universe original protocol

A payload you push, then drop

OP_DROP carries data inside a Taproot leaf script. The payload is pushed onto the stack as an ordinary data push, and the very next opcode, OP_DROP, removes it again. The bytes are committed to the blockchain and provable, but they never take part in whether the spend succeeds.

Lifecycle
Experimental
Chain
Bitcoin
Networks
mainnet, testnet, signet, regtest
Spec version
1.0.0
JSON protocol
op-drop
Carrier marker
bip110-op-drop
Tapleaf version
0xc0
Max data push
256 bytes

The mechanism

Bitcoin script has an opcode whose entire job is to throw away the top stack item. OP_DROP uses that opcode as a carrier. A leaf script pushes five fields, and after each of the first four it runs OP_DROP. What is left on the stack at the end is a public key and a signature check, so the leaf spends exactly like an ordinary key path would.

Exploded view of an OP_DROP leaf script The leaf script is drawn as five stacked parts. Part 1 is the 14-byte marker string bip110-op-drop followed by OP_DROP. Part 2 is the 16-byte content type application slash json followed by OP_DROP. Part 3 is the 32-byte SHA-256 digest of the payload followed by OP_DROP. Part 4 is the JSON payload itself, highlighted, followed by OP_DROP. Part 5 is the 32-byte x-only public key followed by OP_CHECKSIG, which is the only part that affects whether the spend succeeds. Leader lines connect each part to a note on the right. Leaf script, tapleaf version 0xc0 Function PUSH "bip110-op-drop" 14 bytes OP_DROP 1 Fixed carrier marker. Selects the OP_DROP grammar. PUSH "application/json" 16 bytes OP_DROP 2 Declared content type. Always application/json. PUSH <sha256 of payload> 32 bytes OP_DROP 3 Digest of part 4. Must match, or the leaf is rejected. PUSH <JSON payload> 1 to 256 bytes OP_DROP 4 The carried data. Pushed, then dropped, never executed. PUSH <x-only public key> 32 bytes OP_CHECKSIG 5 The only executing part. Decides whether the spend is valid. Parts 1 to 4 leave no trace on the stack
Exploded view of the leaf script. Parts 1 to 4 are pure data: each is pushed and immediately removed by OP_DROP. Only part 5 affects consensus validity.

The stack, step by step

Bitcoin script is a stack machine. The witness supplies the signature first, then the leaf script runs. Following the stack top to bottom makes the design obvious: the payload occupies the stack for exactly one opcode.

Stack contents at each step of an OP_DROP leaf Eleven columns show the stack after each script element. The stack starts holding only the witness signature. Each data push adds one item, drawn as a box above the signature, and the following OP_DROP removes it again, so the stack returns to holding just the signature. The fourth push, the JSON payload, is highlighted. After the final push of the public key, OP_CHECKSIG consumes both the key and the signature and leaves a single true value. Stack after each element (bottom of stack at the line) sig start witness sig mark push 1 sig drop 2 sig type push 3 sig drop 4 sig hash push 5 sig drop 6 sig data push 7 payload sig drop 8 removed sig key push 9 true checksig 10 The payload is on the stack for one opcode, then it is gone. The leaf ends the way a plain key spend ends: one true value.
The stack never carries the payload into a decision. That is the entire design: commit data in the script, prove it with the Taproot commitment, and keep the spend condition a single signature check.

Why build another carrier

Bitcoin already has ways to attach data. Each of them makes a trade you cannot undo later. OP_RETURN puts bytes in an output script, cheap to prune but small and permanently visible to every node's policy checks. Witness envelopes (the Ordinals construction) wrap arbitrary content inside an OP_FALSE OP_IF ... OP_ENDIF block that is never executed, which is cheap thanks to the witness discount but relies on a branch that is skipped rather than evaluated. Stamps deliberately place data in outputs that cannot be pruned at all.

OP_DROP takes a fourth position. The payload sits in the witness (so it gets the witness discount), it is inside code that does execute (the push and the drop both run), and there is no conditional branch anywhere in the script. The whole leaf is five pushes and five opcodes with a fixed shape, which makes both the encoder and the validator small.

The honest version of that comparison, including the places OP_DROP is worse, is on the carrier comparison page.

Two layers, one name

Read the name carefully, because OP_DROP describes two things that are specified separately.

The carrier and the ledger are separate
LayerWhat it fixesIdentifier
CarrierThe exact leaf script grammar, the Taproot commitment proof, and the 256-byte push bound. A leaf either parses or it does not.bip110-op-drop (internal marker string, never a user-facing name)
LedgerWhat the carried JSON means: deploy, mint, transfer, supply accounting, and balances."p":"op-drop" (the public protocol identifier)

A leaf can be a perfectly valid carrier and still change no balance, because the ledger applies a narrower profile on top. The test vectors include cases that pass one layer and fail the other.

Who this is for

Entry points

Specification

Numbered normative rules, transaction anatomy, script encoding, operations, state transitions, and every invalid condition.

Carrier comparison

OP_DROP against OP_RETURN, witness envelopes, and Stamps, including where OP_DROP is the worse choice.

Builder and decoder

Paste a leaf script and watch the stack evolve, or build a leaf from a payload and see its size and fee.

Test vectors

Real leaf scripts, digests, commit addresses, and control blocks, with valid and invalid cases.

Guide

What a deploy, mint, and transfer actually do, end to end, and which Bitcoin Universe surfaces support them.

Reference

Terminology, indexer semantics, fee and size figures, standardness, limitations, and security considerations.

What this protocol does not claim

  • OP_DROP does not change Bitcoin consensus. It uses opcodes that already exist.
  • OP_DROP is not an Ordinals inscription and not BRC-20. It shares the four-character ticker and first-valid-deploy ideas that BRC-20 popularised, and it says so in the ledger rules, but it produces no inscription number and no automatic interoperability with either system.
  • The leaf profile is built to survive the limits described in BIP-110, a published proposal that is marked complete as a document. That is a design choice about staying inside conservative bounds. It is not a claim that BIP-110 is active, nor that any node will relay or mine an OP_DROP transaction.
  • No claim is made that any third-party wallet, marketplace, miner, or indexer recognises OP_DROP.

Bitcoin Universe surfaces

Support claimed here is limited to what is wired in the organisation's own code. See the support matrix for the exact per-surface detail and its caveats.

Verified surfaces
SurfaceStatusWhat it does
Inscribe workspacewiredCreates deploy, mint, and transfer events on the dedicated op-drop route.
Core explorerfeature-gatedConfirmed deployments, supply, holders, and event history, behind the opDropIndex gate, which is off unless a deployment turns it on.
Core portfoliowiredAvailable, reserved, and total balances per address. Not gated.
Core marketplacefeature-gatedTrading is behind the opDropTrading gate, also off by default, and runs in external-execution mode. Selling is explicitly unsupported.

Reporting a problem

Report suspected vulnerabilities privately through GitHub private vulnerability reporting on this repository. Do not open a public issue for a security problem, and do not include private keys, seed phrases, or wallet files in a report. The security considerations section lists the failure modes this protocol is already known to have.