Chrome token discs and a pink electric supercar under fuchsia city lights

Choose your Bitcoin token model

One Bitcoin.
Different ways to create a token.

You do not need to be technical to understand the important part: a token protocol decides what is written to Bitcoin, how ownership changes, and what a wallet needs to check. This guide puts the choices side by side so you can choose with confidence.

op-drop is built for clear fungible-token launches with a direct Bitcoin proof trail. $DROP, the first token on op-drop, shows how a fixed supply, visible mint rules, and a verified OP_DROP commitment can live together on Bitcoin L1.

Explore op-drop Mint $DROP

Bitcoin confirmation+exact record+independent verification=an asset people can inspect

The simple answer

Pick the experience you want people to have.

All of these protocols create meaning from data confirmed on Bitcoin. They are not interchangeable. Some center on inscription conventions, some direct balances between Bitcoin outputs, and some enable general-purpose programs. op-drop focuses on the middle ground: fixed fungible-token rules that are easy for people to read and easy for compatible software to prove.

Fixed-rule launch

op-drop

For a token with clear deploy, mint, and transfer events, a verified OP_DROP commitment, and an optional image paired with its deploy reveal.

Inscription convention

BRC-20

For projects that want token meaning carried through the established Ordinals inscription-token convention.

Media-aware inscription convention

CBRC-20

For Ordinal projects that want BRC-20-style token operations alongside flexible inscription content.

Bitcoin Stamps model

SRC-20

For the Bitcoin Stamps ecosystem, where a dedicated indexer validates direct-to-Bitcoin token events.

Output-directed assets

Runes

For fungible assets expressed through runestones that direct balances to Bitcoin transaction outputs.

OP_RETURN token model

OP-20

For the OP20 Labs model that records deploy, mint, and transfer operations with OP_RETURN.

Programmable applications

Alkanes

For application-specific WebAssembly logic that goes beyond a fixed token rule set.

JSON output records

Mezcal

For output-directed assets that use readable JSON mezcalstones in OP_RETURN, including priced-mint terms.

Satoshi-backed units

ARC-20

For Atomicals assets where token units are represented by satoshis and followed through Bitcoin outputs.

Extended OrdFi

TAP

For projects using an Ordinals-based protocol with BRC-20-compatible basics and extended token features.

Block-linked inscriptions

Block-20

For JSON inscription events that connect token minting to the protocol's block-hash rules.

Dust-backed outputs

DUST-20

For token events that pair units with dust-sized Bitcoin outputs for a UTXO-aware asset model.

Start with $DROP

See op-drop in action

$DROP, the first token on op-drop, is a simple place to see a Bitcoin-native fungible token before launching your own.

A pearl-and-chrome proof artifact connected by luminous data lines — op-drop makes the token record and its Bitcoin commitment part of the same verification story.

Why op-drop exists

Simple to use. Explicit enough to verify.

People launching a token should not need to explain a maze of hidden rules. An op-drop token is a compact, canonical record for deploy, mint, and transfer. A compatible indexer accepts it only after the matching Bitcoin transaction and Taproot commitment check out.

Immutable by confirmation: a valid record can be rechecked from Bitcoin chain data instead of a changing app database.

OP_DROP native: the token designator is op-drop; OP_DROP is the Bitcoin Script opcode that carries its canonical commitment.

BIP-110 ready: the format uses a compact, strict grammar designed for the BIP-110 OP_DROP compatibility boundary.

Designed for real launches: a deploy can carry its token image in the same reveal, so the asset identity follows the token from day one.

Mint $DROP Read op-drop

The full comparison

Twelve approaches, explained without the fog.

There is no universal winner. The right protocol depends on whether you value an inscription convention, satoshi-backed ownership, the Bitcoin Stamps ecosystem, output-based asset movement, open-ended program logic, or a fixed rule set with an explicit proof path. The table names what each model is made to do, and what you should verify before using it.

Full comparison of common Bitcoin token protocol approaches
Protocol	What gets written	How state is read	Good fit	What to check
op-drop	Canonical JSON token events inside a verified `OP_DROP` Taproot leaf. A deploy may also include its image in the same reveal.	A compatible verifier checks the exact leaf, body hash, Taproot commitment, and confirmed transaction before it updates supply or balances.	Clear fungible-token launches, inscriptions with a token identity, and readable Bitcoin L1 agreements.	The compatible Drops verifier or indexer, the canonical event, and the Bitcoin confirmation.
OP-20	Deploy, mint, and transfer operation data carried through `OP_RETURN` by OP20 Labs.	The OP-20 rules aggregate events and use UTXO ownership for transfer receipts.	OP_RETURN token activity following the OP20 Labs model.	The exact OP-20 rules and project identity. The same name is also used by unrelated projects.
BRC-20	JSON operations inscribed through the Ordinals inscription convention.	Compatible indexers interpret deploy, mint, and transfer inscriptions to calculate token state.	Projects that want the established BRC-20 inscription-token model.	The indexer policy and transfer-inscription lifecycle your wallet or marketplace uses.
CBRC-20	Ordinals `metaprotocol` operations, with CBOR metadata for deployment and content still available for other media.	Its convention follows the BRC-20-style deploy, mint, and transfer model while using Ordinals envelope fields.	Ordinal projects that want token operations paired with flexible inscription content.	The CBRC-20 convention, the Ordinals client behavior it expects, and indexer support.
SRC-20	Direct-to-Bitcoin SRC-20 JSON token events in the Stamps format. Current OLGA-era construction uses P2WSH framing; bare-multisig public-key data belongs to historical carrier paths.	A Bitcoin Stamps-compatible indexer validates the event, source and destination rules, then calculates indexed balances.	Projects that want a fungible token in the Stamps, SRC-20 and SRC-101 ecosystem.	The target SRC-20 specification, its applicable carrier era, and the wallet or indexer that supports it.
Runes	A runestone in a Bitcoin transaction output, using `OP_RETURN` followed by `OP_13` and encoded data pushes.	Runestones direct rune balances from transaction inputs to outputs, including etching, minting, and edicts.	Output-directed fungible assets built around the Runes model.	The `ord` rules and malformed-runestone, or cenotaph, behavior.
Alkanes	WebAssembly smart-contract programs and calls through the Protorunes-based Alkanes metaprotocol.	The Alkanes runtime and indexing infrastructure process application-specific execution and state.	Apps that need custom logic such as AMMs, lending, governance, or programmable token behavior.	The contract code, runtime behavior, and indexer or node you rely on.
Mezcal	UTF-8 JSON mezcalstones pushed directly after `OP_RETURN`, with etching, mint, and output edict data.	A compatible Mezcal indexer strictly decodes the JSON record and follows its etching, mint, and output-routing rules.	Readable OP_RETURN token records, output-directed balances, and launches that use priced mints.	The active Mezcal rules, strict JSON validation, output edicts, and the indexer or wallet your users use.
ARC-20	Atomicals records and satoshi-backed token outputs. Each token unit is represented by a satoshi in the ARC-20 model.	UTXO ownership follows the satoshi-backed units, using the Atomicals rules for direct or decentralized minting.	Assets whose units remain tied to Bitcoin satoshis and move with compatible UTXO-aware wallets.	The Atomicals rules, UTXO selection support, ticker claim, and whether the asset uses direct or decentralized minting.
TAP	TAP operations built on the Ordinals model, with BRC-20-compatible basics and extended protocol functions.	A TAP-compatible indexer follows the Ordinals record lifecycle and TAP's additional token, authority, and transfer rules.	OrdFi assets that need extended capabilities such as mass-send, peer-to-peer trading, or TAP's authority features.	The current TAP specification, the exact function being used, and compatible wallet, indexer, and marketplace support.
Block-20	JSON deploy, mint, and transfer inscriptions. Mint records can include the block hash required by the Block-20 rule set.	A compatible Block-20 indexer checks the inscription event order and block-linked mint rules before calculating balances.	Block-linked token launches and mints using the Block-20 inscription convention.	The block-anchor rules, canonical JSON fields, and the indexer and wallet you choose.
DUST-20	JSON deploy, mint, and transfer inscriptions with satoshi values that define its dust-backed token units.	A compatible DUST-20 indexer follows the event data and the associated dust-sized output values to calculate balances.	Assets that want a token event model paired with UTXO-aware, dust-backed output units.	The unit-satoshi and limit-satoshi rules, inscription data, output values, and indexer support.

This is a design and user-experience comparison, not an investment recommendation or a security ranking. Always inspect the specific wallet, indexer, marketplace, and protocol rules you choose.

At a glance

See the design choice before you choose a ticker.

Here is the practical view. It tells you where each protocol puts its token instruction, how the token story is followed, and whether the protocol is meant for fixed rules or open-ended applications.

Launch and verification lens across all twelve protocols
Protocol	Primary carrier	How balances or state are followed	Media and identity	Logic model
op-drop	A canonical token record in a Taproot leaf using `OP_DROP`.	A compatible verifier proves the leaf and confirmed transaction, then follows deploy, mint, and transfer events.	An optional token image can be inscribed with the deploy reveal, so the launch identity starts on Bitcoin with the token.	Fixed fungible-token rules. Custom game or agreement logic belongs in an app or Drops Pact.
OP-20	Operation data in `OP_RETURN`.	Its rules aggregate events and use UTXO ownership for transfer receipts.	Media is not a required part of the token operation format.	Fixed deploy, mint, and transfer operations in the OP20 Labs model.
BRC-20	JSON operation inscriptions in the Ordinals convention.	Indexers interpret the token inscription lifecycle to calculate balances.	The token operation is an inscription record. Any richer media experience depends on the surrounding Ordinals tooling.	Fixed token operations interpreted by compatible indexers.
CBRC-20	Ordinals `metaprotocol` fields with CBOR metadata.	Indexers follow BRC-20-style operations using the CBRC-20 convention.	Designed to pair token metadata with flexible inscription content.	Fixed token operations within the Ordinals ecosystem.
SRC-20	Bitcoin Stamps-formatted SRC-20 data carried directly in Bitcoin transactions.	Bitcoin Stamps-compatible indexers validate operations and address rules to calculate balances.	Part of the Bitcoin Stamps ecosystem, which has its own artifact and token conventions.	Fixed SRC-20 deploy, mint, and transfer operations.
Runes	A runestone using `OP_RETURN` with encoded data.	Balances are routed from inputs to outputs by etching, minting, and edict rules.	Media is separate from the runestone token instruction.	Fixed runestone semantics for fungible assets.
Alkanes	WebAssembly programs and calls in the Alkanes metaprotocol.	Its runtime executes application-defined code and state transitions.	Application-defined.	Open-ended application logic for contracts, games, and other programmable systems.
Mezcal	A JSON mezcalstone pushed directly after `OP_RETURN`.	Its indexer decodes strict JSON records and routes balances through etch, mint, and edict rules.	Token names and terms are readable in the mezcalstone. Media is a separate choice.	Fixed output-directed rules with optional priced-mint terms.
ARC-20	Atomicals records paired with satoshi-backed token outputs.	Compatible tools follow the UTXO that holds the satoshi-backed units.	Metadata can carry an image and asset details alongside the Atomicals identity.	Direct and decentralized mint models with satoshi-backed units.
TAP	Ordinals-based TAP records and protocol operations.	A TAP indexer follows basic operations plus the protocol's extended transfer and authority rules.	Supports OrdFi extensions including Digital Matter Theory and Bitmap integrations.	Extended token functionality, including authority features and TAP smart-contract tooling.
Block-20	JSON token inscriptions with a block-linked mint field.	A compatible indexer reads the event sequence and validates the matching block-hash rules.	Media is separate from the JSON token event.	Fixed deploy, mint, and transfer rules with block-linked mints.
DUST-20	JSON token inscriptions paired with satoshi-valued dust outputs.	A compatible indexer reads event data and the dust-backed output values for the token state.	Media is separate from the token event and output-unit record.	Fixed deploy, mint, and transfer rules with dust-backed units.

The categories are intentionally simple. A protocol can be useful outside its typical fit, but every launch should be checked against the exact rules and services people will rely on.

How the models differ

One Bitcoin block. Six ways to give it meaning.

A protocol is the shared reading rule that turns a confirmed Bitcoin transaction into a token event. The transaction is the same. What changes is where the instruction lives, how compatible software follows state, and what each verifier must prove before it treats that instruction as meaningful.

01 Read the inscription
Inscription-first

Compatible indexers read the token instruction from an inscription convention and follow that convention's lifecycle.
BRC-20 · CBRC-20 · TAP · Block-20 · DUST-20
02 Follow the UTXO
Output ownership

Each unit is tied to a satoshi-backed output, so compatible tools follow UTXO ownership rather than an inscription event history.
ARC-20
03 Decode the carrier
Bitcoin Stamps

A Stamps-compatible indexer validates the applicable SRC-20 transaction format and then applies its source and destination rules.
SRC-20
04 Parse output data
OP_RETURN grammars

Token instructions live in transaction output data. Each protocol supplies its own strict grammar and state transition rules.
OP-20 · Runes · Mezcal
05 Run the program
Programmable state

An application runtime executes contract-defined logic, so state depends on the program and the runtime behavior it declares.
Alkanes
06 Prove the commitment
Taproot proof

A canonical token record is checked against its exact OP_DROP commitment and confirmed Bitcoin proof before it updates state.
op-drop

A better starting point for fixed-rule tokens

Launch a token people can understand at a glance.

op-drop keeps the launch story visible: a token name, supply terms, mint limit, optional image, confirmed Bitcoin record, and a proof a compatible verifier can repeat. Start by minting $DROP, the first token on op-drop, then bring the same simple experience to your own launch.

Mint $DROP Explore op-drop and $DROP

Read every protocol in its own words

Useful source material before you choose.

This page summarizes the published documentation for each model. Before a launch, read the original rules and check the exact wallet and services you plan to use.

op-drop and $DROPCanonical token events, OP_DROP commitments, and the $DROP launch experience. OP20 Labs OP-20Its OP_RETURN fungibility and UTXO transfer model. Domo's BRC-20 originThe original BRC-20 inscription-token convention. CBRC-20 conventionCBOR metadata and metaprotocol fields in Ordinals inscriptions. SRC-20 and Bitcoin StampsDirect-to-Bitcoin SRC-20 token events, transaction rules, and indexer validation. Runes handbookRunestones, etching, minting, and output-directed transfers. Alkanes documentationWASM-based smart contracts and the Alkanes execution model. MezcalJSON mezcalstones, output-directed balances, and priced-mint terms. ARC-20 and AtomicalsSatoshi-backed ARC-20 units, direct minting, and decentralized minting. TAP ProtocolOrdFi functions, extended token features, and TAP smart-contract tooling. Block-20 and DUST-20Check compatible tools and the exact indexer rules before you launch or trade.