Datacarrier protocols

Every OP_RETURN a block carries is classified here — decoded locally in your browser, straight from the raw block bytes, with no external indexer trusted. This is the legend for the badges you see on each block, and a reference for what's actually filling Bitcoin's datacarrier outputs.

How it works

Classification is per output — a transaction with several OP_RETURNs gets each one labelled independently.
The labels are mutually exclusive; each output matches the first class below that fits.
The coinbase witness commitment (6a24aa21a9ed…) is protocol overhead — counted separately, never as datacarrier.
This is orthogonal to the health metric (outputs over the historical 80-byte data / 83-byte script standard): a block can be "bloated" and this tells you what the bloat is.

The classes

◈ OP_NETmarker opnet.org ↗

6a 58 — OP_RETURN OP_8

OP_NET epoch challenge submissions — SHA-1 proof-of-work solutions for its smart-contract layer. The payload carries the solver's account key and the solution preimage.

Example: 658b32af…251834

⚗ Alkanesmarker alkanes-rs ↗

6a 5d runestone · Protocol tag 16383 · protocol id 1

An Alkanes metaprotocol message packed into a runestone's 16383 Protocol fields (15 payload bytes per u128). Invisible to Runes indexers — they ignore the odd tag — but decoded here.

Example: 8bfd8d36…bd9f

⬡ protostonemarker

6a 5d runestone · Protocol tag 16383 · protocol id ≠ 1

A protorunes protostone for a protocol other than Alkanes. Detected as a protostone; the specific protocol isn't decoded.

ᚱ Runesmarker runes spec ↗

6a 5d — OP_RETURN OP_13, no 16383 field

A plain runestone: a Runes etch, mint, or transfer with no metaprotocol payload riding along.

⛏ ProofOfWork.Memarker proofofwork.me ↗

payload starts pwt1: / pwm1: / pwid1: / pwr1:

A social / token / mail system on legacy Bitcoin, using 546-sat "proof" payments. pwt1: credits, pwm1: mail & bonds, pwid1: identities, pwr1: registry.

Example: bb4a05ad…f648 (Inception Bond + credit transfer)

⇄ bridgeheuristic

printable ASCII · 0x<hex> address and/or depositor= field

A custodial / bridge deposit memo — e.g. 0x<hex>|depositor=bc1q…|: an EVM-style destination plus a refund address. This is a heuristic, not a magic byte, so it may miss uncommon formats and it names no specific operator.

Example: d2819802…56d0

⌀ paddingmarker

non-marker OP_RETURN, payload ≥ 8 bytes, entirely 0x00

A zero-filled reservation output that carries no information (Alkanes transactions often emit one). Split out so it doesn't inflate the data count; the block detail reports total bytes spent on padding.

Example: 90f47c99…7ea0 (1,000 bytes of zeros)

· plain data

anything else

Genuinely uncategorised bytes: timestamps, raw commitments, and protocols we don't yet recognise.

Known limits

bridge is the only heuristic; the rest key on unambiguous markers. It's recall-limited and attributes no operator.
Ordinals / inscriptions are out of scope — they live in the taproot witness, not OP_RETURN, so this datacarrier scan doesn't see them.
The full write-up with detection details lives in issue #1.