Metarunes protocol May 2, 2024 Bitcoin is fungible. But if we squint our eyes and try really hard we can trace each satoshi to the block where it was created. When a transfer is made we just enumerate each input and each output and we pretend that the UTXO on my wallet is composed of enumerated satoshis. This is Ordinal Theory. So we made Bitcoin non-fungible. Last year, ordinal creators came up with Runes. That’s a protocol for creating fungible tokens on top of Bitcoin. You create runes by structuring your transaction according to Runes non-spec. So each rune is created at a certain block. When runes are transferred, you can define how those runes are going to be split among UTXOs. If we are so inclined, we can also enumerate each rune and assign a number to them. That’s the Metarunes Proto. We can create fungible tokens on top of Runes protocol. Here’s how we can do it: Overview Metarune balances are managed by UTXOs, each capable of holding various amounts and types of Metarunes. A transaction that carries a Metarune protocol message must have its output’s script pubkey begin with an OP_RETURN followed by a data push of the ASCII uppercase letter ‘M’. The protocol message is composed of all subsequent data pushes. Metarunes input to a transaction with a faulty protocol message are forfeited, enabling future protocol upgrades and modifications without creating discrepancies in Metarune assignments by older clients. Integers are encoded using prefix varints, where the length of the integer is determined by the number of leading ones in the varint. Transfer The first data push in a Metarune protocol message is decoded into a series of integers. These integers form a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of integers does not divide evenly by three, the protocol message is deemed invalid. ID is the numeric identifier for the specific Metarune. OUTPUT specifies which output receives the Metarune. AMOUNT denotes the quantity of Metarunes to be assigned. ID values are delta-encoded to streamline multiple assignments of the same Metarune, minimizing redundancy. For instance, the tuples: [(200, 0, 50), (0, 1, 30), (10, 0, 10)] Translate to the following assignments: ID 200, output 0, 50 Metarunes ID 200, output 1, 30 Metarunes ID 210, output 0, 10 Metarunes The use of AMOUNT 0 implies the transfer of “all remaining Metarunes.” Following all tuple-based assignments, any Metarunes not explicitly assigned are automatically allocated to the first non-OP_RETURN output available. Excessive assignments beyond the available balance are disregarded. Metarunes can be deliberately burned by directing them to the OP_RETURN output that contains the protocol message. Issuance A Metarune issuance transaction must have as its first input a single Rune, which serves as the basis for creating new Metarunes. From this single Rune, it is possible to issue tens of thousands of Metarunes, up to the maximum limit of 2**128−1. If the protocol message includes a second data push, this push is decoded into two integers, SYMBOL and DECIMALS. Any additional integers after these result in an invalid protocol message. SYMBOL is a base 26-encoded identifier, readable and confined to the characters A-Z. DECIMALS represents the number of decimal places for Metarune display precision. If SYMBOL is not previously assigned, it is linked to the newly issued Metarune, which is then allocated the next available numeric ID, starting from one. Should SYMBOL be already in use, or be reserved names like BITCOIN, BTC, or XBT, the issuance transaction does not create a new Metarune. However, other assignments within the transaction are still processed.