Exact body, MIME type, creator key, and Taproot proof.
Supported carriers
Every Bitcoin artifact deserves one clear meaning.
The Drops carrier registry keeps formats distinct, strict, and verifiable. That means an app can support compact artifacts, BIP-110-compatible records, token events, and Pacts without confusing one for another.
A separate strict decoding path preserves its registered meaning.
Immutable Seeds and transition commitments follow their own verification route.
Interoperable by being exact
Compatibility works best when no parser has to guess.
For you, this means the name of a record tells a wallet how to read it. A Drops artifact, an op-drop event like $DROP, the first token on op-drop, and a Pact record stay distinct instead of blending into one confusing data type.
| Carrier | What it carries | What stays clear |
|---|---|---|
drops | Compact generic artifact | Exact body, MIME type, creator key, and Taproot proof. |
bip110-op-drop | Registered compatibility carrier | Its own strict decoding path, separate from native Drops meaning. |
drops-pact | Immutable Pact Seed | Agreement identity, ruleset, policy, and initial-state commitment. |
DPC1 | Pact transition commitment | Compact pointer to a verified Cell state change and Proof Pack. |
Generic artifacts do not create balances without op-drop validation.
Token rules stay separate from Pact actions and generic records.
Strict carrier boundaries let products evolve without rewriting an existing Bitcoin record.
BIP-110 ready
Support compatible records without dissolving their boundaries.
The registered bip110-op-drop carrier is available to products that need it. Drops keeps that compatibility explicit: a generic record is not automatically a token, and a token event is not automatically a Pact action.
Clear formats create better experiences
Create a richer Bitcoin record without giving up unambiguous proof.
See how the canonical Drops carrier works, then explore the Pacts and Studio experiences that grow from it.