Introduction

Nanas is an improvement protocol to Runes adding a turing complete programmable layer natively to an indexer with the ability to manipulate unallocated runes.

-> Before reading these docs, we recommend researching and familiarizing yourself with the existing Runes protocol non-spec ( https://docs.ordinals.com/runes.html ) and how Bitcoin's UTXO model works ( https://community.magiceden.io/learn/utxo-guide ). These docs assume extensive knowledge in both these topics.

Created by: Jorge Lara (https://x.com/mork1e)

X: https://x.com/nanasprotocol

Discord: https://discord.gg/nanas

Telegram: https://t.me/nanasprotocol

Pitchdeck: https://docsend.com/view/vc3c22mux4c6892w

Email: [e-mail]

Lets talk Runes.

The year is 2024. The halving block just got mined with a whopping 40+ BTC (>2M USD ATT) paid to miners in a single transaction. The reason? A new protocol for fungible assets was set to kickstart in this block, codenamed runes.

Hold up. Runes? Tf?

"Runes", which I actually agree is a pretty obscure name, specifically refers to the protocol dictating the behavior of the indexing and processing "runestones", JSON-based protocol messages encoded as integers in a transaction with an output including an OP_RETURN script.

Unlike EVM chains where balances live directly in a smart contracts state, Runes live in the collective delusion of anyone running a Rune indexer. Balances are stored inside unspent transaction outputs, with "account balances" being calculated by aggregating the total Rune balance of all unspent transaction outputs held by an account. Once a UTXO is spent, the runes once held by that specific UTXO are marked as unallocated and allocated to the transactions' new outputs, a behavior which is dictated by a transaction's Runestone. Since everyone is running the same indexer and a Runestone decoder (that which is able to build the Runestone from raw OP_RETURN buffer data), indexers are able to unanimously agree on Rune balances for each account after processing every runestone in every transaction since Rune genesis (840,000).

Example lifecycle of a Runes Transaction:

Runes is smart because at a first glance it solves 2 big issues present in other protocols that attempt to add fungibile assets to Bitcoin:

1. BRC-20 required witness data to build protocol messages, adding a layer of complexity to anyone wishing to do anything on the protocol. Since Runes live directly on transaction outputs, this "inscription" step can be skipped. This makes runes more accessible.

2. Runes are efficient. OP_RETURN scripts are limited to 80 bytes, anything over this is considered non-standard and not indexed by Bitcoin nodes. Rather than storing the json string in an inscription, only essential bytes required to build this JSON are stored on the output script, allowing the protocol messages to well fit in this 80 byte limit. The anatomy of a Runestone also makes Runes efficient - for example, rather than providing a raw string address for transfers in a runestone (which would use a large chunk of the bytes available in an OP_RETURN script), Runes use vout indices (a u32 which only uses 4 bytes) - and its up to the indexer to check and store the address owning the vout index. This is one of many examples in the Runes non-spec aiming at only including absolutely unavoidably necessary data in a runestone. Which:

   1. Reduces the load the protocol imposes on the network by not bombarding nodes with useless inscription data

   2. Anyone, including non-segwit* btc nodes, can index Runes since indexers don't require a BTC full node with a segregated witness layer (*except for etchings which require witness data for checking commitments. Small exception, however, because another node could just lend this data to an indexer everytime an etch runestone is encountered. Actual balances live directly on UTXOs.)

Runes as great as it is, however, has one very big problem. The ecosystem is way too complicated for the average user. While transferring runes is easy, usually - people want to do more than just transfer fungible assets. Selling on Magic Eden is way too complicated for the average user and not nearly as simple or as good of a user experience as a swap on EVM chains - something which could only be achieved with a stateful protocol implementing an AMM. Native rune raises either require raising on another chain and bridging to bitcoin (defeating the purpose of an asset native to bitcoin altogether), or are a centralized premine and airdrop which bombard the network with thousands of UTXOs. Vesting runes natively could be done by sending the rune to a time locked UTXO, however, there is no tool currently that lets you do this.

TLDR: Runes is simple and efficient, but its complexity and high entry level does not allow it to scale to the masses or leverage its fungibility for anything useful.

We want to make Runes better.

Our solution: Nanas