New Bitcoin, in full color
Bitcoin gets useful
when it gets expressive.
The original orange Bitcoin story made scarce digital cash legible. Drops adds a bolder chapter: compact artifacts, strict token events, and readable agreement records, all verified against the same Bitcoin L1.
Built to last: a confirmed commitment becomes part of Bitcoin history. Any compatible indexer can independently verify the exact artifact it records, without trusting a changing product database.
Canonical leaf+Taproot proof+Confirmed block=Verified Drop
PaymentsProofArtifactsTokensAgreementsBitcoin L1Full color
A bigger Bitcoin canvas
Payments were the beginning. Coordination is the next act.
Drops does not replace Bitcoin's original job. Sending value remains the foundation. The opportunity is to make that value useful in more situations: a compact identity, a token event with strict rules, or a visible agreement that parties can review before they sign.
Orange, iconic, and essential: send value from one person to another with final settlement on Bitcoin.
Pink on purpose: portable artifacts, strict token state, and bounded agreement records that people can inspect, verify, and build around.
The visual is playful. The verification standard is not. Drops stays deliberately small: every valid record has a canonical grammar, an explicit Taproot proof path, and a confirmed Bitcoin anchor.
Bitcoin L1, all the way down
One immutable foundation for Bitcoin that can do more.
Think of Drops as a clear way to give a record a permanent place on Bitcoin. Once Bitcoin confirms it, people can find the same record again without trusting a changing app database, a sidechain, or a private index.
bip110-op-drop carrier while keeping each parser's meaning strict and separate. This does not promise relay, mining, or third-party support.Bitcoin L1Confirmed blocks, UTXOs, Taproot
OP_DROPCompact canonical commitment
DropsBody, hash, key, and proof
The Drops stack
One Bitcoin foundation. More ways to make it useful.
Drops gives immutable artifacts a clear proof path. OP-DROP and Drop Pacts build on that same Bitcoin L1 foundation with strict token events and readable agreement records.
Different by design
Simple enough to verify. Useful enough to build on.
You do not need to understand the code below to benefit from Drops. It lets you share a Bitcoin record that wallets, explorers, and independent services can recognize and check for themselves.
One carrier, one reading
The marker, MIME type, body hash, body, and creator key have a fixed order. Your app does not need to guess what a payload means.
Proof before display
A verified indexer checks the leaf script and BIP341 control block against the P2TR output that was spent. Seeing a transaction is not enough.
IDs that travel
drops:mainnet:<txid>:d<input> comes from the reveal transaction. It stays meaningful across wallets, explorers, and indexers.
Small on purpose
Drops carries compact, legible artifacts. Larger material belongs behind explicit content-addressed references, never hidden conventions.
A proof anyone can follow
Publish. Confirm. Verify.
For you, the process is simple: publish a small record, wait for Bitcoin to confirm it, then let anyone check the same proof. No separate account or private database is required.
Publish a clear body
Your wallet prepares the canonical leaf with a MIME type, body hash, body, and public key. The body is compact and exact.
Anchor it in Taproot
The reveal spends the Taproot output that committed to that exact leaf. The outpoint is part of the verification story, not an implementation detail.
Verify independently
An indexer recomputes the commitment, checks the body hash, and records the Drop only after the proof succeeds on the confirmed chain.
The Drops proof path
Every verified Drop has a trail you can inspect.
In simple terms, Drops lets you see that a record is really on Bitcoin and has not been quietly changed. The artifact bytes, Taproot commitment, and confirmed Bitcoin transaction must all agree.
Exact bytes and canonical MIME type.
SHA256 commits the displayed content.
Control block proves the committed leaf.
Confirmed on Bitcoin and independently checkable.
A clear choice of tradeoffs
Designed for apps that value explicit proof.
If you want an inscription-style record or token event that is simple for anyone to check, Drops gives that record a direct Bitcoin proof. It makes a different tradeoff from ordinal conventions: less hidden interpretation and more explicit proof.
| Question | Drops | Ordinal inscription conventions |
|---|---|---|
| What identifies the artifact? | Reveal txid plus input index | Inscription identity and satoshi tracking conventions |
| What does an indexer verify? | Exact carrier, body hash, and P2TR commitment | Protocol-specific envelope and ordinal state rules |
| How much content is native? | At most 256 bytes | Varies by implementation and inscription form |
| Where is the anchor? | Explicit spent P2TR outpoint | Sat-level assignment model |
This is a design comparison, not a security ranking. Choose the model that matches your application and verify the implementation you rely on.
Pacts on Bitcoin
Bitcoin L1 agreements, made readable.
Think of a Pact as a promise people can read before they sign. Its terms and important changes stay visible on Bitcoin, instead of being hidden in an app. Behind that simple experience is a compact identity, committed state, and proof package that parties can inspect.
Seed fixes the agreement identity.
Cell commits the current state.
Proof records the verified transition.
Explore Drops Pacts
Built for clear commitments
Make the agreement easy to see before you sign.
You can use the same approach for an op-drop token such as $DROP, shared funds, release schedules, and simple agreements. People see what is agreed before they act. Pacts is a design and verification layer, so its enforcement boundary remains explicit rather than hidden behind a promise.
Drops wire format
Five values. Four drops. One clear artifact.
You do not need to write this code to use Drops. It is here to show that every compatible wallet and verifier receives the same clear record, with no hidden interpretation.
PUSH "drops" OP_DROP
PUSH <canonical MIME> OP_DROP
PUSH SHA256(body) OP_DROP
PUSH <body, max 256B> OP_DROP
PUSH <x-only pubkey> OP_CHECKSIGEach Drop follows one exact compact layout. A compatible verifier compares its content, Taproot commitment, and confirmed Bitcoin transaction before presenting it as verified. That keeps the proof attached to the artifact instead of asking people to trust a database label.
Your next Bitcoin record
Start with something worth remembering.
Explore confirmed Drops, discover $DROP, or turn a reviewed agreement into a durable Bitcoin record. Every path begins with clear intent and ends with proof anyone can inspect.
Discover DropsSee why immutable Bitcoin proof changes the experience
Explore op-drop and $DROPSee strict fungible tokens with Bitcoin-native proof
Compare Bitcoin token protocolsSee how op-drop, OP-20, BRC-20, CBRC-20, SRC-20, Runes, Alkanes, Mezcal, ARC-20, TAP, Block-20, and DUST-20 take different paths on Bitcoin
Verify a DropFollow the artifact, body hash, and Taproot proof
Read the protocolSee the canonical OP_DROP proof format
Publish an agreementGive reviewed Pact terms an immutable Bitcoin record
Use PactsExplore smart agreements on Bitcoin L1
Use Pacts StudioDesign, review, and publish a Pact artifact
Record a Pact artifactCommit a completed plan and blueprint hash pair
See supported carriersChoose the exact verified artifact format