Version history
Changelog
Two things are versioned here: the specification, and the documents that describe it. The wire format has not changed since it was first published; version 1.0.0 is the first time it was written down as a numbered specification.
What has never changed
Every one of these has held since the first public document in July 2026, and any change to them would be a new major specification version.
- The carrier marker
bip110-op-dropand the content typeapplication/json. - The ten-element leaf grammar, and the four
OP_DROPpositions. - The protocol identifier
"p":"op-drop"and the three operations. - Four-character tickers, positive integer strings, and no decimals.
- Output 0 as the anchor and as the only settlement destination.
- First valid deploy wins, the partial final mint, and the two-stage transfer.
Specification 1.0.0
2026-09-01
First numbered publication of the specification, and a rebuild of this repository into an independent documentation site.
Added
- A normative specification with numbered rules
OD-1.1throughOD-14.4, replacing prose that described the same behaviour without rule identifiers. - The transaction anatomy: witness item count, control block constraints, previous output requirements, and the anchor convention, none of which had been documented publicly before.
- The exact leaf script grammar, including the minimal push encoding requirement and the byte-for-byte rebuild check.
- The Taproot commitment proof steps.
- Identifier formats for reveal events, settlement events, and anchors.
- The deterministic ordering rule, including the operation index and the settlement-before-reveal phase ordering.
- The complete set of invalid reason codes with the exact condition that produces each.
- The optional
drops-mediaimage attachment format. - The seven reduced-data construction limits and how the carrier stays inside each.
- A carrier comparison against OP_RETURN, witness envelopes, and Stamps, including where OP_DROP is the worse choice.
- A test vectors page with real leaf scripts, digests, commit addresses, control blocks, ledger sequences, and invalid cases.
- A client-side builder and decoder that reproduces the reference encoder byte for byte.
- An API reference for the indexer read contract.
- Fee and size figures measured from the reference encoder, and standardness and relay considerations.
- An implementation checklist for encoders, decoders, and indexers.
Clarified
- The carrier layer and the ledger layer are now specified separately, because a leaf can be a valid carrier and still change no balance. The
self_mintcase is documented as the worked example of that split. - "Reserved" in the interfaces is the same value as
transferablein the API. - Mempool handling: the ledger never includes it; provisional tracking exists and never affects balances.
- Reorg handling: automatic recovery is bounded, and deeper divergence requires operator action.
- Support claims are limited to surfaces that can be verified in Bitcoin Universe source, with marketplace trading marked as feature-gated and selling marked as unsupported.
Unchanged
- No wire format change. Every leaf and payload that was valid before this version is still valid, and produces the same result.
Documentation history
Before version 1.0.0 the rules lived in unversioned markdown under docs/. Those documents are preserved in the repository and remain accurate; the pages on this site supersede them for detail.
| Date | Change |
|---|---|
| 2026-09-01 | Documentation manifest added, so the central docs platform can ingest this repository. |
| 2026-08-29 | Prose brought in line with the workspace text policy. |
| 2026-08-19 | The resilient confirmed read path documented: one scanner, API-only replicas, and finalized-hash agreement between two independently operated Bitcoin nodes. |
| 2026-07-30 | Public experience streamlined across the guides. |
| 2026-07-16 | Integration checklist, contribution guidance, and repeatable documentation validation added. |
| 2026-07-16 | First public documentation of OP_DROP: event format, indexing rules, design rationale, and the BIP-110 scope note. |
Versioning policy
- Major. Any change that makes a previously valid leaf invalid, or a previously invalid leaf valid, or that changes a resulting balance.
- Minor. A new optional capability that older implementations can ignore without diverging.
- Patch. Clarification, corrections, and new examples, with no behaviour change.
- Lifecycle is experimental, so a major change is possible. Any such change will appear here, with its rationale, before it is deployed.
- There is no version field in the payload. The grammar itself is the version, which means a major change would need a new marker rather than a new field.