Version history

What changed, and why

Two things are versioned here: the protocol rules themselves, and this document's description of them. They move at different speeds, so they are listed separately.

Versioning policy

CH-1
A confirmed Drop keeps the meaning it had at its confirmation height. No revision of this document retroactively invalidates a record that was valid under the rules in force when it confirmed.
CH-2
The leaf grammar has no version field. A change to the grammar would take a new marker, not a version byte inside the existing one.
CH-3
Document revisions are dated. Every page footer states the revision it belongs to and the commit at which it was last verified against the implementation.
CH-4
A correction that changes what an implementation should do is listed as a rule change. A correction that changes only how a rule is described is listed as a document change.

Protocol rules

Drops leaf grammar, current

The five-push leaf, the 256-byte body limit, Tapleaf version 0xc0, the two markers, and the full Taproot commitment requirement. No change has been made to the grammar since it was first implemented, and none is planned. Rule CH-2 explains why a change would arrive as a new marker rather than as a revision.

Custody profile `drops-custody-v1`, projection version 1

Custody follows output 0, with the P2WPKH and P2TR positive-value test, and three statuses. Activation heights for the projection are deployment configuration rather than a protocol constant, so two operators may differ and should each publish the heights they use.

Mainnet confirmation floor raised to six

Rule change. The mainnet confirmation depth now has an enforced floor of six, and the reference indexer refuses to start with a shallower mainnet value. Earlier one-confirmation behaviour is not compatible with the current consumer readiness contract, and a legacy runtime at one confirmation is treated as transition input rather than as authority to weaken the floor. A depth change that intersects already-indexed history is an audited replay, never a silent reinterpretation of existing rows.

Pacts capability contract, schema version 1

The Pacts surface publishes a machine-readable boundary with mode: reference, five supported capabilities and twelve authority fields fixed at false. Any method other than GET on a Pacts path returns 405 with PACTS_REFERENCE_READ_ONLY. This contract is what a client should check rather than inferring capability from the presence of an endpoint.

Document revisions

Revision 2026-09-01

A full rebuild of this site as an independent protocol documentation set, verified line by line against the reference indexer, the service interface definition and the Bitcoin Universe capability registry.

Added

A normative specification with 49 numbered rules covering the leaf grammar, field constraints, the Taproot commitment, identity, operations, custody transitions and every invalid condition with its reference message.
Carrier and transaction anatomy: commit and reveal structure, witness layout, the marker registry, minimal push encoding, and a worked leaf byte by byte.
Drop Pacts: the 184-byte Seed layout, pact identity derivation, the three enforcement floors, the Cell descriptor, the 245-byte transition preimage, and outcome rules P-1 through P-9.
Validation and indexing: the ten-step verification order, confirmation policy, mempool behaviour, reorganisation budgets and the operator-required codes.
An API reference grounded in the service's own OpenAPI 3.1 definition, with exact parameter constraints, enum values and pagination defaults.
Test vectors: four valid leaves and ten invalid ones with real bytes, ten Taproot commitment cases, and twelve Pact record cases.
A payload decoder and a Pact outcome verifier, both entirely client-side, both stating what they do not check.
A conformance specification with three implementation classes and a Pacts annex.
A creation guide, an integration guide with the verified support matrix, terminology and sizing, security and safety, and a protocol comparison.
Local search, a site map, llms.txt, sitemap.xml and robots.txt.

Corrected

Control block. Earlier material implied a single-leaf tree. A Drops leaf may sit anywhere in a Taproot script tree and the control block may carry up to 128 merkle path hashes.
Confirmation depth. Earlier material referred to records existing at three or more confirmations. The enforced mainnet floor is six.
Networks. Earlier material described mainnet only. The protocol defines four networks, and identities are network-scoped.
Availability. Marketplace support is now stated as feature-gated and off by default, with the gate names and the one unsupported action quoted from the capability registry rather than described in general terms.
Pacts. The reference-only boundary is now given as the full capability contract, field by field, rather than as a paragraph of prose.

Changed

The site's visual identity is kept and sharpened rather than replaced: the faceted magenta droplet, the high-contrast serif wordmark and the spectrum rule remain, now expressed as a documented design system with a seal motif, a restrained palette and WCAG 2.2 AA contrast in both themes.
Every raster image was replaced with an optimized derivative under 200KB, with descriptive alt text.
Page furniture now states the owning repository, source path, specification revision, lifecycle, chain and networks, last-verified commit and an edit link on every page.

Removed

Duplicate narrative pages that restated the same material in several places, folded into the pages above.
Claims of product support that could not be verified in the organization's own code.

Earlier revisions

Before this revision the repository held an illustrated introduction to Drops, OP_DROP and Pacts with a protocol summary in Markdown. The accurate facts from that material are preserved in the pages above; the presentation and the completeness are what changed. The full history is in the repository commit log.