Protocol Atlas

What the Atlas will not do

No prices. No market data. No rankings. No claim that any protocol is superior. Every cell is an evidence object with a status and a pinned revision: where evidence is missing, the cell says unknown instead of guessing.

The Protocol Atlas compares Atomicals, ARC-20, AVM, Ordinals, Runes, BRC-20, Bitcoin Stamps and SRC-20, TAP, Alkanes and Protorunes, Counterparty, and RGB. The dataset behind every view is machine-readable and validated against a published JSON Schema, so the page, the exports, and the MCP resources all describe the same evidence.

Four views cover one dataset:

1. Matrix. Column selection, search, status filters, compact or detailed cells, comparison of up to four protocols side by side, and CSV or JSON export. The state is shareable through the URL.
2. Relationship map. Which shared Bitcoin primitive each protocol builds on, with a table equivalent. Edges never imply lineage that a pinned source does not support.
3. Timeline. Activation points the sources support. The AVM marker is a pinned beta interpreter, deliberately not drawn as a deployment.
4. Decision explorer. Concrete neutral questions about your requirements, answered with a transparent match and miss list per protocol. It compares; it does not recommend.

Matrix Relationship map Timeline Decision explorer

Export CSV Export JSON

Search

Choose columns

Chain Unit or object model Fungible support Non-fungible support Mutability model State location Data placement Transfer model UTXO coupling Validation authority Indexer requirement Naming support Collection support Programmability Content permanence Confirmation and reorg considerations Principal UTXO safety risk Activation or deployment status Specification or implementation source Pinned source revision

Protocol comparison. Every cell carries a status and a source revision.

Protocol	Unit or object model	Fungible support	Non-fungible support	State location	UTXO coupling	Programmability
Atomicals	Atomical objects; ARC-20 makes one unit equal to one coloured satoshi verified	ARC-20 fungible tokens with satoshi-denominated units verified	NFTs assigned to specific outputs, with Realm, Subrealm, Container, and Payname objects verified	Indexer-computed from complete transaction history; nothing consensus-level carries the state verified	Total. Owning the object is owning the carrying UTXO verified	None in the base protocol; the AVM is a separate beta layer verified
ARC-20	One unit is one coloured satoshi; balances emerge from which UTXOs a wallet holds verified	Yes. Fixed and perpetual supply modes, decentralized and direct deployment verified	No. NFTs belong to the wider Atomicals model, not to ARC-20 itself verified	Indexer-computed holdings over UTXOs; no account ledger verified	Total. Units are indivisible from their satoshis verified	No programmability verified
AVM	Program state over stacks with opcode-defined transitions experimental	Token semantics exist in interpreter research material but are not a deployed fact experimental	Object semantics exist in interpreter research material but are not a deployed fact experimental	Interpreter state; no live indexer state model is claimed by this documentation experimental	Deposit and withdrawal concepts exist in the interpreter; live UTXO coupling is not established experimental	Yes, that is the point of the interpreter: opcode-level programs over stack state experimental
Ordinals	Inscriptions bound to satoshis by satpoint verified	None natively; BRC-20 layers fungibility on top of inscriptions verified	Yes. Inscription content is the object verified	Indexer-computed sat inventory and inscription history verified	Strong at sat granularity; individual satoshis carry the objects verified	None at the protocol level verified
Runes	Rune balances carried per UTXO with per-output amounts verified	Yes. Etching defines supply and divisibility; mints follow etch rules verified	No verified	Indexer-computed ledger over UTXOs verified	Strong. Balances live on specific outputs verified	None in the base ledger verified
BRC-20	Ticker-keyed balance entries derived from deploy, mint, and transfer inscriptions implementation-specific	Yes, through indexer interpretation of inscriptions implementation-specific	No; the model targets fungible balances implementation-specific	Indexer-side ledger keyed by addresses; the chain carries only the inscriptions implementation-specific	Weak. Balances are index-side while inscriptions travel on sats, which is the model's known operational risk implementation-specific	Programmable module extensions exist as proposals and partial indexer support proposal
Bitcoin Stamps and SRC-20	Stamps as dust-anchored images; SRC-20 as ticker-keyed balances from OP_RETURN JSON implementation-specific	SRC-20 fungible tokens verified	BTC stamps carry image content per key verified	Indexer-computed ledger; stamps additionally bind to dust outputs implementation-specific	Stamps couple to dust UTXOs; SRC-20 coupling is weaker and ledger-style implementation-specific	None at the protocol level implementation-specific
TAP	Unknown unknown	Unknown unknown	Unknown unknown	Unknown unknown	Unknown unknown	Unknown unknown
Alkanes and Protorunes	Alkane contract state with Protorunes as fungible token units implementation-specific	Yes, through Protorunes token contracts implementation-specific	Contract-defined object patterns exist implementation-specific	Indexer-executed contract state over the inscription message chain verified	Indirect. Messages flow through inscription spends while balances live in executed state implementation-specific	Yes. WASM smart contracts are the core of the metaprotocol verified
Counterparty	Named and numeric assets in a Counterparty ledger keyed to Bitcoin addresses verified	Yes. Divisible and non-divisible assets verified	Yes, as non-divisible assets verified	Ledger state computed from Bitcoin transactions by a Counterparty node verified	Weak. Address-level ownership without output binding verified	None at layer 1 verified
RGB	RGB20 fungible and RGB25 collectible contract state implementation-specific	Yes through RGB20 schemas implementation-specific	Yes through RGB25 collectible schemas implementation-specific	Client-side stashes and consignments; only cryptographic anchors live on chain verified	Strong. Single-use seals bind state transitions to specific outputs verified	Contract logic runs on the AluVM runtime verified

Select a protocol name to compare up to four side by side. Unknown and conflicting facts are shown as recorded; they are never inferred. Verified 2026-09-02, dataset version 1.0.0.

How evidence works here

Every fact in the dataset carries value, status, sourceId, sourceRevision, verifiedAt, and optional notes. Statuses are verified, implementation-specific, proposal, experimental, unknown, and conflicting. Cell rendering shows unknown and conflicting exactly as recorded. The source manifest holds the pinned repositories and revisions.

Where this page and a protocol’s own documentation disagree, the disagreement is recorded as a status rather than resolved by an editor.