OP_RETURN

    Bitcoin mainnet / data carrier output

    One carrier. Three protocols.

    OP_RETURN is a Bitcoin output that can never be spent. Nodes are allowed to forget it exists, yet the bytes stay in the block forever. Three separate protocols write into that channel, and they behave differently once they land.

    How the carrier works Read the specification Decode a script

    What this site documents

    Everything below is one Bitcoin output type and three independent protocols that share it. They are documented separately on purpose. Blurring them together is the most common source of wrong expectations about what an OP_RETURN token or name actually guarantees.

    One OP_RETURN carrier feeding three independent protocol readers A single OP_RETURN output holding a UTF-8 payload is read by three separate indexers. The OP-20 reader accepts payloads tagged p equals op-20. The OP Names reader accepts payloads tagged p equals opns or a bare dotted name. The OP Inscriptions reader accepts payloads tagged p equals op-inscriptions plus a narrow historical envelope. Each reader keeps its own state and none of them can bless the others. OP_RETURN output 6a <push> payload bytes value 0, provably unspendable OP-20 reader, registry id op_return accepts {"p":"op-20", ...} deploy, mint, transfer Core: read only, viewable, not tradeable OP Names reader, registry id op_names accepts {"p":"opns", ...} or a bare label.namespace Core: read only, viewable, not tradeable OP Inscriptions reader, id op_inscriptions accepts {"p":"op-inscriptions", ...} and media payloads Core: in app execution, list, buy, settle
    The carrier is neutral. Meaning is assigned entirely by whichever reader claims the payload, and each reader keeps its own state.
    carrier

    OP_RETURN

    A Bitcoin output whose script starts with OP_RETURN (0x6a). Script execution fails immediately, so the output can never be spent. Because it can never be spent, a node may drop it from the UTXO set entirely.

    Mechanism, pruning and relay limits

    protocol / op_return

    OP-20

    A fungible token protocol written as a JSON object tagged "p":"op-20". Three operations: deploy, mint and transfer. Balances are an indexer interpretation, not a Bitcoin consensus fact.

    OP-20 rules

    protocol / op_names

    OP Names

    Singleton name ownership. A name is label.namespace with exactly one literal dot. First valid registration wins permanently, and ownership moves between address custody and UTXO custody.

    OP Names rules

    protocol / op_inscriptions

    OP Inscriptions

    Content written directly into OP_RETURN outputs, including media split across several outputs and reassembled. This is the only one of the three that Bitcoin Universe Core can actually trade.

    OP Inscriptions rules

    What Bitcoin Universe products actually do

    These rows come from the Core capability snapshot generated from the marketplace protocol registry. Support recorded there is what the product code implements. It is not a promise that a protocol is enabled in production, which the status pages report separately.

    Core marketplace surface, generated from bitcoinuniverseio/core at commit 15dd03b5
    ActionOP-20 (op_return)OP Names (op_names)OP Inscriptions (op_inscriptions)
    Availabilityread-onlyread-onlyenabled
    Moderead-onlyread-onlyin-app-execution
    viewyesyesyes
    view-collectionyesyesyes
    view-activityyesyesyes
    listnonoyes
    unlistnonoyes
    update-listingnonono
    buynonoyes
    settlenonoyes
    reconcilenonoyes
    make-offer, accept-offer, cancel-offer, sellnonono

    Every unsupported action has a recorded reason. The guide lists them in full, including why an OP-20 buy is not declared supported even though the current interface can reach a broadcast step.

    Status at a glance

    Lifecycle

    Experimental. The OP Names raw block authority in the organisation's code is complete but deliberately not production enabled, and OP-20 marketplace mutations are retired.

    Chain and network

    Bitcoin mainnet. All rules and vectors on this site describe mainnet behaviour.

    Document version

    1.0.0, published 2026-09-01. See the changelog for what changed and why.

    Pending activity

    Reported as unavailable for OP-20 and OP Names. There is no exhaustive mempool activity feed behind either reader.

    Where to start

    • New to the carrier: read the carrier page for what OP_RETURN does to the UTXO set and how it differs from witness envelopes and unprunable outputs.
    • Building an indexer: the specification gives numbered rules per protocol, and the test vectors were produced by running the organisation's own parsers.
    • Holding or moving assets: the guide walks through a transaction and states exactly which actions are supported.
    • Debugging a transaction: paste a scriptPubKey into the decoder.

    Links