0xRunes
  • Introduction
    • 0xRunes
    • Runes Protocol
    • Runes Vs BRC20, ORC-, Etc.
  • Protocol
    • Technical Implementation
    • Advantages
    • Cross Chain Process
    • Etch, Mint, Transfer
  • Official Links & Info
    • Socials
    • Tokenomics
Powered by GitBook
On this page
  1. Protocol

Etch, Mint, Transfer

Etching

Runes come into existence by being etched. Etching creates a rune and sets its properties. Once set, these properties are immutable, even to its etcher. Mint

A runestone may mint a rune by including the rune's ID in the Mint field.

If the mint is open, the mint amount is added to the unallocated runes in the transaction's inputs. These runes may be transferred using edicts, and will otherwise be transferred to the first non-OP_RETURN output, or the output designated by the Pointer field.

Mints may be made in any transaction after an etching, including in the same block. Transfer Runes are transferred by edict:

struct Edict {  id: RuneId,  amount: u128,  output: u32,}

A runestone may contain any number of edicts, which are processed in sequence.

Before edicts are processed, input runes, as well as minted or premined runes, if any, are unallocated.

Each edict decrements the unallocated balance of rune id and increments the balance allocated to transaction outputs of rune id.

If an edict would allocate more runes than are currently unallocated, the amount is reduced to the number of currently unallocated runes. In other words, the edict allocates all remaining unallocated units of rune id.

Because the ID of an etched rune is not known before it is included in a block, ID 0:0 is used to mean the rune being etched in this transaction, if any.

An edict with amount zero allocates all remaining units of rune id.

An edict with output equal to the number of transaction outputs allocates amount runes to each non-OP_RETURN output.

An edict with amount zero and output equal to the number of transaction outputs divides all unallocated units of rune id between each non-OP_RETURN output. If the number of unallocated runes is not divisible by the number of non-OP_RETURN outputs, 1 additional rune is assigned to the first R non-OP_RETURN outputs, where R is the remainder after dividing the balance of unallocated units of rune id by the number of non-OP_RETURN outputs.

If any edict in a runestone has a rune ID with block zero and tx greater than zero, or output greater than the number of transaction outputs, the runestone is a cenotaph.

Note that edicts in cenotaphs are not processed, and all input runes are burned.

PreviousCross Chain ProcessNextSocials

Last updated 1 year ago