Walkthrough

Guide

Every runestone in this guide is a real byte string you can paste into the decoder. The hex shown is the complete output script: 6a for OP_RETURN, 5d for OP_13, one length byte, then the payload.

These are constructed examples, encoded and verified against the ord 0.29.0 decoding rules. They are teaching material, not transactions that exist on chain.

The mental model

Forget account balances. A rune balance is a property of a transaction output, exactly like a satoshi amount. If you spend the output, you spend the runes on it. The runestone in a transaction is a note attached to the spend saying where the runes should land.

Transfer, worked

You hold 1,500 units of rune 840000:3 on one output, and you want to send 1,000 to a friend and keep the rest. Your transaction spends that output and creates two spendable outputs plus the runestone.

6a 5d 08 00 c0 a2 33 03 e8 07 01

Read it byte by byte:

The edict allocates 1,000 to output 1. The remaining 500 are unallocated, and with no pointer they go to the first non-OP_RETURN output, which is output 0. Your change arrives without you asking for it. Put the runestone last and your own address at output 0, and the default does the right thing.

Two runes in one transaction

Delta encoding pays off when you move several runes at once. Here, 1,000 of 840000:3 to output 1 and 500 of 840000:28 to output 0:

6a 5d 0d 00 c0 a2 33 03 e8 07 01 00 19 f4 03 00

The second edict starts 00 19: a block delta of 0 means stay in block 840,000, and 25 is added to the running transaction index of 3, giving 840000:28. Edicts must be sorted by rune ID for this to encode correctly. Getting the order wrong does not produce an error, it produces edicts pointing at different runes than you meant.

Splitting and sweeping

Two shorthands save bytes and mistakes:

• Amount 0 means the entire remaining balance of that rune. 6a 5d 07 00 c0 a2 33 03 00 01 sweeps everything to output 1.
• Output equal to the output count means split. In a transaction with 3 outputs, output index 3 does not exist, so it is read as an instruction: divide across all non-OP_RETURN outputs. With amount 0 the balance is divided evenly, earlier outputs taking the remainder. With a nonzero amount, that amount goes to each non-OP_RETURN output in turn until the balance runs out. 6a 5d 07 00 c0 a2 33 03 00 03 is an even split across a 3-output transaction.

The line between "split" and "cenotaph" is one integer wide. An output index of 3 in a 3-output transaction splits; an output index of 4 makes the transaction a cenotaph and burns everything.

Mint, worked

Minting rune 840000:3 needs nothing but the Mint tag, given twice: once for the block, once for the transaction index.

6a 5d 06 14 c0 a2 33 14 03

14 is tag 20 with value 840000, then tag 20 again with value 3. The minted amount joins the transaction's unallocated runes and, with no edicts and no pointer, lands on the first non-OP_RETURN output. Adding a pointer sends it somewhere else:

6a 5d 08 14 c0 a2 33 14 03 16 01

16 01 is tag 22 (Pointer) with value 1, so the mint lands on output 1 instead.

If the mint's terms are not satisfied (the cap is reached, or the height window has closed), the mint quietly does nothing. You pay the fee and receive no runes. It is not an error and not a cenotaph. Check the rune's current mint count and window before broadcasting.

Etch, worked

Etching is the only operation with a prerequisite outside the runestone. To claim a name, the transaction must commit to it: an input must spend a pay-to-taproot output whose witness tapscript contains the name's value as little-endian bytes with trailing zeros trimmed, and that output must have been confirmed at least 6 blocks earlier. That is why etching is a two-transaction dance: a commit transaction, a six-block wait, then the reveal transaction carrying the runestone.

Here is a full etching of BITCOIN•UNIVERSE, divisibility 2, symbol ⚒, premine 1,000,000, and an open mint of 1,000 per mint capped at 21,000 mints, closing 12,960 blocks (about 90 days) after the etching block:

6a 5d 22 02 07 04 c2 e1 d8 f3 d9 a4 f5 89 cf 10
      01 02 03 40 05 92 4d 06 c0 84 3d 0a e8 07
      08 88 a4 01 12 a0 65

Maximum supply is premine + cap × amount = 1,000,000 + 21,000 × 1,000 = 22,000,000 atomic units, which displays as 220,000.00 ⚒. That sum must fit in a 128-bit integer; if it overflows the transaction becomes a cenotaph.

Note what is not in the runestone: the premine has no destination. Like a mint, it joins the unallocated pool and follows the edicts, then the pointer, then the first non-OP_RETURN output. An edict with rune ID 0:0 refers to the rune being etched right here, which is how you distribute a premine in the same transaction.

Ways an etching quietly fails

These do not make a cenotaph. They make the etching disappear while your fee is spent:

• The name is already etched by someone else. Names are unique ignoring spacers: if BITCOINUNIVERSE exists, BIT•COIN•UNIVERSE cannot be etched.
• The name is still locked. At activation only names of 13 letters and up were available; the minimum shrinks by one letter every 17,500 blocks until all names, down to single letters, unlock at block 1,050,000.
• The commitment is missing, malformed, in a non-taproot input, or younger than 6 confirmations.

Burning

Runes are burned by sending them to an OP_RETURN output, either with an edict naming that output or with a pointer aimed at it. Burning is deliberate and explicit. The accidental way to burn runes is a cenotaph, which burns every rune in the transaction's inputs at once. The decoder tells you which of the two you have built before you sign.

What to check before you sign

1. The runestone decodes as you intended. Paste the OP_RETURN script into the decoder and read the edict table. It is the only part of the transaction your wallet's summary may render loosely.
2. Output 0 is yours. Unless a pointer says otherwise, everything unallocated lands on the first non-OP_RETURN output. If that is somebody else's address, your change goes with it.
3. Every rune-bearing output stays above the dust limit. A rune balance rides on a spendable output; if that output is uneconomical to spend, the balance is stranded in practice.
4. Your inputs are the ones you think they are. Spending a rune-bearing output as ordinary fee input pushes those runes into the unallocated pool, where they follow the default rule. Wallets that do not track rune outpoints will do this without warning.
5. The mint is actually open. A closed mint returns nothing and refunds nothing.

Support in Bitcoin Universe products

Runes originated outside this organization: the protocol and its reference implementation, ord, are the work of Casey Rodarmor and the Ordinals project. Bitcoin Universe indexes and displays runes. The table below reflects what is wired in the org's own code today, not what is planned.

The registry also carries a separate protocol id, runes_native ("Runes (Native)"), under the same read-only policy. Rune amounts are asset-defined: divisibility comes from the etching, not from a protocol-wide constant.