Drops Protocol documentation

    Bitcoin L1 · original Bitcoin Universe protocol

    A record that is dropped once and meant to last.

    Drops is an application protocol for two kinds of permanent Bitcoin record: media-first artifacts, and Drop Pacts, agreements whose terms are committed on chain so every party can check them later. Both travel in an OP_DROP Taproot leaf, and both are only counted after the commitment verifies against confirmed chain data.

    Read the specification Decode a payload
    A faceted glass cube holding pearl spheres floats above a mirrored magenta runway, with two people in iridescent couture and a night skyline behind them.
    Drops keeps the identity it was given in 2026: a faceted magenta droplet, a high-contrast serif wordmark, and a fine spectrum rule.
    256 bytesMaximum artifact body carried in the leaf
    5 pushesFixed field order in every Drops leaf
    0xc0The only accepted Tapleaf version
    2 markersdrops for artifacts, drops-pact for pacts

    Availability today: implemented, and switched off by default

    The Bitcoin Universe capability registry records both drops and op_drop as feature-gated with mode external-execution. The code exists and is wired into Core, but every marketplace action stays off unless an operator enables the gate for that deployment: dropsMarketplaceV1 for Drops, opDropTrading for OP_DROP.

    The registry also records one action as unsupported for both protocols. Quoted from the registry: DROPS has no executable offer workflow on this marketplace surface. The sell action is therefore not available, on any deployment, gate or no gate.

    Drop Pacts go further. The reference indexer answers GET /drops/pacts/capabilities with mode: reference, and every execution, custody, authorization, signature, broadcast, live-Cell and value-bearing field in that response is false. Pacts records are readable; there is no Pact settlement authority. See the full capability contract.

    What Drops is

    One carrier, two application layers, no hidden interpretation

    Drops does not scan Bitcoin for text that resembles an artifact. It requires an exact script structure inside a Taproot script-path spend, checks that the revealed leaf is the leaf the spent output committed to, and only then records the artifact.

    Artifacts

    A compact media body with a declared MIME type, a SHA-256 body hash, and a creator key. The body is at most 256 bytes, so an artifact is a small legible thing, not a file dump. Larger material belongs behind an explicit content-addressed reference.

    Artifact model and lifecycle

    Drop Pacts

    An agreement recorded as a Drop under the drops-pact marker. A Pact Seed fixes the agreement identity and the hashes of its ruleset, ABI, genesis state, policy, and data-availability policy. Its enforcementFloor states plainly how much of the agreement Bitcoin itself enforces.

    Pact lifecycle and outcomes

    The OP_DROP carrier

    The transaction-level carrier that both layers ride on: a single Tapscript leaf whose data pushes are consumed by OP_DROP before a final OP_CHECKSIG. OP_DROP is its own protocol with its own documentation site and its own token model.

    OP_DROP summary and links

    How a Drop is proved

    Commit, reveal, verify, record

    Every rule below is checked by the indexer before an artifact exists in its view. Failing any one of them means the transaction is simply not a Drop.

    The Drops commit, reveal, verify and record flow A commit transaction pays to a Taproot output that commits to one Tapscript leaf. A reveal transaction spends that output on the script path, exposing the leaf script and a 33-byte control block. The indexer recomputes the tapleaf hash and output key, compares the SHA-256 body hash, and only then records the artifact under the identity drops network txid d input index. STEP 01 Commit Pay to P2TR output key Q OP_1 <32-byte Q> STEP 02 Reveal Script-path spend exposes signature, leaf, control block STEP 03 Verify Control block commits to leaf, SHA-256 matches the body STEP 04 Record At the configured confirmation depth Portable identity, emitted by the indexer for every recorded artifact: drops:<network>:<reveal-txid>:d<reveal-input-index> The identity names the reveal input, so it survives explorers, wallets and indexers without a naming service.
    The proof path is the whole protocol. An indexer that only pattern-matches the transaction text has not verified a Drop.
    PUSH <marker>            OP_DROP     drops | drops-pact
PUSH <content type>      OP_DROP     declared MIME type of the body
PUSH SHA256(body)        OP_DROP     32 bytes
PUSH <body>              OP_DROP     1 to 256 bytes
PUSH <x-only pubkey>     OP_CHECKSIG 32 bytes

    Five pushes, fixed order, minimal push encoding, Tapleaf version 0xc0. The Drops leaf may sit anywhere in a Taproot script tree, so the control block carries a merkle path of up to 128 hashes. The full carrier and transaction anatomy covers the witness layout, the control block, and how the leaf is committed.

    Drop Pacts

    An agreement you can read before you sign, and check after

    A Pact Seed records the agreement's identity together with the hashes that pin its rules: rulesetHash, abiHash, genesisStateRoot, policyRoot, and dataAvailabilityPolicyHash. It also records an enforcementFloor, one of recorded, co-signed, or template-enforced.

    That floor is the honest part. It says how much of the agreement Bitcoin enforces by itself and how much depends on the parties or on a template. The pact verifier on this site checks a recorded outcome against the stated terms entirely in your browser.

    Read the Drop Pacts specification

    Three people in iridescent evening wear standing around a lit glass table, examining a chrome padlock and a translucent panel of linked nodes above a night city.
    Pacts are about parties, terms, and a record that outlives the interface that produced it.

    Everything on this site

    Where to go next

    Every page states its own source path, specification revision, and last-verified commit in the footer.

    Specification

    Drops specificationNumbered normative rules, encoding, identifiers, operations, validity and invalid conditions. Carrier and transaction anatomyThe OP_DROP leaf, the witness, the control block, the marker registry, and payload encoding. Artifacts and lifecycleThe media model, MIME handling, custody states, and how an artifact moves between owners. Drop PactsPact Seed fields, enforcement floors, pact lifecycle, outcomes, and the reference-only capability contract. OP_DROP carrier and tokensSummary of the carrier protocol and its token lifecycle, with links to its own documentation site. Validation and indexingVerification order, confirmation policy, mempool and reorg behaviour, rejection reasons.

    Build and verify

    Create a DropA walkthrough from body bytes to a confirmed record, with a worked transaction. Integration guideFor wallets, explorers and indexers: what to implement, in what order, and what to avoid. Payload decoderPaste a leaf script or payload and see every field explained. Runs entirely in your browser. Pact verifierCheck whether a pact's recorded outcome matches its stated terms. Also client-side only. Test vectorsValid and invalid cases with expected outcomes, derived from the indexer's own rules. ConformanceWhat an implementation must do to call itself Drops-compatible, as a checklist.

    Reference

    API referencePublic read endpoints, parameters, response fields, error shapes, rate limits and pagination. Terminology and limitsGlossary, fee and size considerations, known limitations, implementation checklist. Security and safetyWhat a Drop proves and does not prove, threat notes, and how to report a vulnerability. Compared with adjacent protocolsHow Drops differs from ordinal inscriptions, BRC-20, Runes, SRC-20 and others. Version historyDocument and specification revisions, with what changed and why. Bitcoin Universe docs platformThe portal that indexes this repository and every other Universe protocol.

    Honest boundaries

    What a confirmed Drop proves

    It does prove
    • These exact body bytes were committed in a Tapscript leaf.
    • That leaf is the leaf the spent Taproot output committed to.
    • The declared SHA-256 matches the body that was revealed.
    • The spend is in a block on the chain the indexer follows.
    It does not prove
    • Who authored the content, or that they had the right to.
    • Legal ownership, transfer of rights, or market value.
    • That a Pact's off-chain terms were performed.
    • That any other indexer or wallet reads it the same way.

    Bitcoin transactions are difficult to reverse. Review the body, the network, the destination and the fee in a wallet you trust before signing. No Drops or Pacts interface ever needs a seed phrase or a private key.