Drops Protocol documentation

    Neighbouring protocol · summary only

    OP_DROP, in summary

    OP_DROP is the other original Bitcoin Universe protocol built on this carrier shape. It records token events rather than artifacts. This page is a summary for Drops readers. OP_DROP owns its own specification, and that is where the normative rules live.

    OP_DROP repository Marker registry
    A magenta sports car on a wet night street with a neon skyline behind it and faceted token discs floating on thin connecting lines.
    OP_DROP is the token layer. Drops is the artifact and agreement layer. They share a carrier and nothing else.
    Why this page is short on purpose

    Duplicating another protocol's specification is how two documents drift apart and both become wrong. This page covers what a Drops implementer needs in order to keep the two protocols separate, and stops there. For event grammar, ledger rules, statuses and reasons, read the OP_DROP documentation.

    The boundary between the two protocols

    Both protocols use the same five-push OP_DROP leaf shape. The marker is what separates them, and the separation is a hard rule in both directions.

    Drops and OP_DROP compared
    DropsOP_DROP
    Markerdrops, drops-pact6269703131302d6f702d64726f70 (OP_DROP marker hex)
    RecordsMedia artifacts and agreement recordsToken events
    BodyOpaque bytes with a declared content type, at most 256One compact JSON event with a fixed key order
    Unit of stateAn artifact, identified by its reveal inputA balance, per address and ticker
    Identitydrops:<network>:<txid>:d<input>Ticker plus address, with per-event ids
    Feature gatedropsMarketplaceV1opDropTrading
    Cross-acceptance is a bug

    A Drops indexer must reject 6269703131302d6f702d64726f70 (OP_DROP marker hex), and an OP_DROP indexer must reject drops and drops-pact. The Drops list endpoint enforces this at the query layer too: its marker filter accepts only drops and drops-pact, and the specification records that 6269703131302d6f702d64726f70 (OP_DROP marker hex) is deliberately excluded. An artifact never becomes a balance, and a token event never becomes an artifact.

    The three token events

    An OP_DROP event is one compact JSON document. The serialized bytes are part of the event identity: different spacing, key order or values produce a different event.

    deploy    {"p":"op-drop","op":"deploy","tick":"demo","max":"21000000","lim":"1000"}
mint      {"p":"op-drop","op":"mint","tick":"demo","amt":"1000"}
transfer  {"p":"op-drop","op":"transfer","tick":"demo","amt":"250"}
    Event field rules
    FieldRule
    pExactly op-drop.
    opExactly deploy, mint or transfer.
    tickExactly four lowercase ASCII letters or digits, matching ^[a-z0-9]{4}$.
    maxA positive whole-number string with no sign, fraction, exponent or leading zero.
    lim, amtPositive whole-number strings that also fit the deployed terms and the available balance. On deploy, lim may not exceed max.

    All values are JSON strings. The document is UTF-8 with no whitespace outside string values, no duplicate keys and no unknown keys, and each operation has a required key order. Reordered keys, altered whitespace, unknown keys and non-string values are all rejections.

    Token lifecycle

    Supply and balances change only after confirmation and validation. A wallet preview, a draft, or a mempool transaction is not state.

    The OP_DROP token lifecycle A deploy event establishes a ticker's maximum supply and mint limit; only the first valid confirmed deploy for a ticker wins and later ones are invalid duplicates. Mint events credit available balance, with the credited amount being the smaller of the requested amount and the remaining supply. A transfer moves units from available to reserved in stage A, then in stage B either settles to the destination or returns to the sender's available balance. Statuses shown are valid, transfer pending, settled and invalid. DEPLOY Ticker rules fixed First valid confirmed deploy wins Later deploys: invalid duplicate MINT Available balance credited = min(amt, remaining) Over the limit, or no supply: invalid TRANSFER, STAGE A Reserved Leaves available balance transfer_pending settled credited to destination returned back to sender, not burned Stage B resolves when the transfer's settlement anchor is first spent in a confirmed transaction. The destination is the transaction's first addressable destination. If no valid destination can be identified, the reserved units return to the sender. Event statuses: valid, transfer_pending, settled, invalid. An invalid event may be displayed with a reason, but never changes supply, balances or holder counts. Balances are available, reserved, and total, where total is available plus reserved. Ordering is deterministic: block height, then position in the block, then position in the transaction, then a stable event identity.
    Two-stage transfers exist so that a recipient is never credited before the transfer completes, and an incomplete transfer returns rather than burns.

    The $DROP reference terms

    $DROP is the display name for the wire ticker drop. These are protocol terms, not a price, an availability promise, or a claim of external support. They take effect only once the deploy event is confirmed and accepted.

    Maximum supply21000000 whole units
    Mint limit1000 units per valid mint event
    Full-limit mint count21,000 events, if every mint takes the full limit
    Decimal placesNone

    Availability

    The Bitcoin Universe capability registry records op_drop as feature-gated with mode external-execution, behind the gate opDropTrading. Twelve marketplace actions are supported when the gate is on, and one is not: sell, because, quoting the registry, OP_DROP has no executable offer workflow on this marketplace surface.

    Settlement is recorded only when the finalized-block scanner verifies the exact intent transaction and the OP_DROP custody transition, at a minimum of one confirmation for settlement. Reorganisation handling is automatic: rollback removes block-bound settlement evidence, marks the intent reorged, and preserves the recovery and rebroadcast lineage.