What a transaction actually looks like.

The mental model

Every transaction on this carrier has the same three parts, and confusing them is where almost all mistakes come from.

1. The intent lives in the OP_RETURN payload. It says what you want to happen.
2. The result holder is a different, spendable output. For OP Names it is called the receipt; for OP-20 it is the recipient address or the transfer UTXO.
3. The interpretation happens later, in an indexer that replays blocks. Bitcoin confirms your bytes. An indexer decides what they mean.

A transaction can confirm perfectly and still change nothing at the protocol layer, because step three rejected it. That is not a failure of Bitcoin, and there is no refund.

Worked example: an OP-20 mint

Minting 1000 units of the token whose ticker is written PIPE.

The payload

{"p":"op-20","op":"mint","tick":"PIPE","amt":"1000"}

52 bytes of UTF-8. The tick is written in uppercase but the reader normalises it to the reference pipe, which is what identity is compared on. The stable asset identity becomes op_return:op20:b64.cGlwZQ.

The script

scriptPubKey, 54 bytes: 6a347b2270223a226f702d3230222c226f70223a226d696e74222c227469636b223a2250495045222c22616d74223a2231303030227d

The transaction

The whole scriptPubKey is 54 bytes, well inside the 83 byte default relay limit, so this propagates everywhere. A ticker long enough to push the script past 83 bytes will still be valid but may not relay on older default policy.

Worked example: an OP Names registration

Registering satoshi.btc. Two encodings are accepted and they behave differently.

Legacy plain text, 11 bytes

satoshi.btc

scriptPubKey, 13 bytes: 6a0b7361746f7368692e627463

No protocol tag at all. The reader accepts it because the trimmed text has exactly one literal dot. Ownership comes from the receipt output.

Explicit JSON with an address

{"p":"opns","op":"reg","name":"satoshi.btc","add":"bc1q..."}

Here the owner is stated in the payload, so the name enters address custody with that address and the receipt output does not decide the owner.

Which output is the receipt

This is the rule people get wrong. Without add, the receipt is output 0 when the OP_RETURN sits at any index above 0, and output 1 otherwise.

Moving a name later

A name in address custody moves only by an explicit transfer payload whose input 0 spends an output belonging to the exact current owner. That authorised transfer places the name into UTXO custody at the receipt outpoint. From then on the name follows spends of that exact outpoint to output 0, which is what makes a name behave like a physical object rather than a balance.

Worked example: OP Inscriptions content

Content written directly into the carrier, with an explicit protocol tag.

{"p":"op-inscriptions","op":"inscribe","add":"bc1q..."}

The record identity is the outpoint, txid:vout. Anything larger than a single carrier is written as several OP_RETURN records that share a group identifier and a declared total; the indexer assembles them only when every part is present exactly once. A group missing one part is never rendered and never partially shown.

Support matrix

Generated from the Core capability snapshot, which is generated in turn from the marketplace protocol registry in bitcoinuniverseio/core. Only claims backed by that snapshot appear here.

Bitcoin Universe surfaces

OP-20 is the only one of the three with a recorded Inscribe surface. OP Names and OP Inscriptions have no creation surface recorded in the registry, so this site does not claim one.

Marketplace actions and the recorded reason for each refusal

This is the useful contrast between three protocols on the same carrier: sharing an output type buys them nothing in common at the product layer. What decides tradeability is whether a settlement authority exists that can prove a fill from chain data. OP Inscriptions has one. OP-20 and OP Names do not.

Before you sign

1. Check the network. Every rule here is mainnet.
2. Read the payload, not the interface. Decode the actual scriptPubKey with the decoder and confirm the ticker, amount and recipient are what you expect.
3. Count the OP_RETURN outputs. One. Always one.
4. Check the value on the data output is zero. Anything else is destroyed.
5. Identify the receipt output. For an OP Names registration without add, know which output will own the name.
6. Check your coin selection. If your wallet does not know about pending OP-20 transfer UTXOs, name custody outpoints and listed assets, it can spend one as fee change and destroy it.
7. Accept the fee. A rejected payload still costs the fee. There is no reversal.