Guide
Using OP_DROP
You do not need to read the specification to use OP_DROP, but you do need to understand one idea: nothing counts until a transaction confirms and the rules accept it. A wallet preview is a proposal, not a balance.
Three operations
| Operation | In plain language | Fields you choose |
|---|---|---|
| Deploy | Define a new token: pick a four-character ticker, a maximum supply, and how much one mint may request. The first valid deploy for a ticker wins, permanently. | tick, max, lim |
| Mint | Ask for units of a token that already exists, under the rules its deploy set. | tick, amt |
| Transfer | Move units you already hold. This happens in two confirmed steps, not one. | tick, amt |
Tickers are not reserved. Anyone can attempt a deploy for any four-character ticker at any time, and only chain order decides who gets it. Check the explorer before you plan a launch around a name.
The path an action takes
Worked example: a mint, end to end
Minting 1000 drop. Every value here is real, and comes from vector V2 on the test vectors page.
Step 1: the event
{"p":"op-drop","op":"mint","tick":"drop","amt":"1000"}54 bytes, exactly as written. No spaces, no reordering, values as strings.
Step 2: the leaf
The event is hashed, and the digest and the event are both pushed into a leaf script along with the marker, the content type, and your public key. That script is 158 bytes:
PUSH "bip110-op-drop" OP_DROP
PUSH "application/json" OP_DROP
PUSH 3c0153…12e1 OP_DROP
PUSH {"p":"op-drop",…} OP_DROP
PUSH 8836f3…bf3b OP_CHECKSIGStep 3: the commit transaction
The leaf is committed into a Taproot address. For this leaf and this key that address is:
bc1pjx22xhtzlyxn2fef89l9t2z3qrsfypyuufau6uszequgcc64n5kqtlwnapYou pay that address. On chain this looks like any other Taproot payment. Nobody can tell what it commits to.
Step 4: the reveal transaction
You spend that output along the script path. The witness carries exactly three items: your signature, the leaf script, and the 33-byte control block c18836f3…bf3b. Output 0 of this transaction is the anchor, and its address is credited with the minted units. The reveal is about 160 vB, so at 5 sat/vB it costs roughly 800 sat plus whatever the commit cost.
Step 5: the result
Once the reveal reaches the deployment's confirmation depth, an indexer applies the rules. If drop is deployed and supply remains, output 0's address gains 1000 available units and the event id {revealTxid}:i0:w1 appears in the event ledger with status valid. If supply had run out, the same transaction would appear with status invalid and reason supply_exhausted, and you would have paid the fee for nothing.
That last sentence is not a bug. Bitcoin has no way to tell you in advance that a mint will lose a race. Check remaining supply immediately before you sign, and expect the last mints of a popular token to fail.
Worked example: a transfer
A transfer is two confirmed steps, and the units are visible in a third state in between. This is the part of OP_DROP that surprises people.
| Step | What you do | What the ledger shows |
|---|---|---|
| 1 | Create a transfer event at address A for amt 250. Commit and reveal. | Nothing. Pending. |
| 2 | The reveal confirms. | A: 750 available, 250 reserved. Event status transfer_pending. B has nothing. |
| 3 | Spend the anchor, output 0 of the reveal, in a new transaction that pays B at its output 0. | Still 250 reserved until this confirms. |
| 4 | That transaction confirms. | A: 750 available, 0 reserved. B: 250 available. A settlement event appears with status settled. |
Three details decide whether step 4 works:
- Output 0 is the destination. Not output 1, not the change output, not the address that signed. If your wallet puts change at output 0, the change address receives the units.
- If output 0 has no address, an
OP_RETURNfor example, the transfer is invalid and the 250 units return to A. Nothing is destroyed. - Only the first spend counts. Once the anchor is spent, the transfer is finished either way.
A transfer also cannot share a transaction with another transfer. Two valid transfer leaves in one transaction would both claim the same anchor, so both are rejected with ambiguous_transfer_anchor. A transfer alongside a mint is fine.
Reading a result
| You see | It means | What to do |
|---|---|---|
| Pending order | A transaction step has not confirmed. It is not a balance. | Wait. Check the transaction on any Bitcoin explorer. |
| Indexer warming up | The confirmed view is still catching up to the chain tip. | Recheck later before relying on totals. |
Status valid | A deploy or mint passed every rule and changed state. | Nothing. |
Status transfer_pending | Units are reserved. The anchor has not been spent yet. | Spend the anchor to complete the transfer. |
Status settled | A transfer credited its destination. | Nothing. |
Status invalid with a reason | The transaction was seen but a rule failed. No balance changed. | Read the reason. The full list is in the specification. |
| No token found | No valid confirmed deploy for that ticker on this network. | It does not mean a pending deploy will fail, and it does not mean the ticker is free. |
The $DROP token
$DROP is a display label. The wire ticker is drop, four lowercase characters like every OP_DROP ticker.
| Wire ticker | drop |
|---|---|
| Maximum supply | 21,000,000 whole units |
| Limit per mint event | 1,000 |
| Full-limit mint count | 21,000 |
| Decimal places | none |
| Deploy payload | {"p":"op-drop","op":"deploy","tick":"drop","max":"21000000","lim":"1000"} |
21,000 is the number of full-limit mints needed to exhaust the supply. Smaller mints are valid, so the actual number of mint events can differ. These are protocol terms only. They are not a price, an availability promise, or a claim that the deployment exists on any particular network: a deployment exists only after its exact deploy event confirms and is accepted.
Support matrix
This table lists only what can be verified in Bitcoin Universe's own source. Nothing outside this organisation reads OP_DROP, and no claim is made about any third-party wallet, marketplace, miner, or indexer.
| Surface | Actions | Status | Detail |
|---|---|---|---|
| Inscribe workspace | deploy, mint, transfer | wired | A dedicated op-drop route that builds the strict construction. Ordinary BRC-20 routes cannot produce an OP_DROP payload. Mint batches are capped at five independent inscriptions, which does not change the per-event limit. |
| Core explorer | view, discover, view collection, view activity, view transaction | feature-gated | Deployments, supply, holders, and confirmed event history, read only. Behind the opDropIndex gate, which defaults to off: the protocol is staged independently so index reads, portfolio balances, and the trade desk can be enabled one at a time. |
| Core portfolio | view | wired | Available, reserved, and total balances per address, in a card separate from Ordinals and BRC-20. This surface is not gated. |
| Core wallet | view, send, receive | declared | Declared in the ecosystem registry as a wallet surface for the protocol. |
| Core marketplace | list, update listing, unlist, buy, make offer, accept offer, cancel offer, settle, reconcile | feature-gated | Behind the opDropTrading gate, which also defaults to off, in external-execution mode against a configured OP_DROP marketplace authority. Settlement is recorded only when a finalized-block scanner verifies the exact intent transaction and the custody transition. |
| Core marketplace: sell | sell | unsupported | Recorded in the registry as unsupported: OP_DROP has no executable offer workflow on that surface. |
| Third-party wallets, explorers, marketplaces | any | none | Not currently supported. No external tool recognises an OP_DROP event. |
"Wired" means the surface exists in the organisation's source and is not behind a gate. "Declared" means the ecosystem registry lists the capability. "Feature-gated" means the code exists but the gate defaults to off, so the surface is absent unless a deployment explicitly enables it. None of these are a promise that a given deployment has it switched on today, and the safest assumption for a gated surface is that it is off.
Staying in control
- Never enter a seed phrase or private key into any page, including this one. No OP_DROP tool needs one.
- Read the exact JSON before approving. It is the only place where a mistake is still free.
- Check the network, the destination, the amount, and the total fee in a wallet you trust.
- Treat a signature and a pending transaction as neither ownership nor a balance.
- Confirmed Bitcoin transactions are effectively irreversible.
- Do not read an Ordinals or BRC-20 balance as an OP_DROP balance. They are unrelated records that happen to share ticker conventions.
- For a transfer, verify which output your wallet will place first. Output 0 is the destination.