# 1. Introduction Casey Rodarmor's Ordinal Theory provided a special lens through which to view Bitcoin. It revealed individual satoshis (the smallest units of BTC) as unique digital objects. This made these satoshi-objects immutable collectors items, giving them similar properties and values to that of NFTs (Non-Fungible Tokens). The community stretched Casey’s notion further, and quickly rendered entire token ecosystems from the Ordinals' breakthrough. One such member, domo, even invented a way to create fungible “BRC-20” tokens, a token standard similar to Ethereum’s ERC-20. While BRC-20s were an ingenious Ordinal-based fungible token prototype, they were created as an experiment and face significant limitations compared to their ERC-20 counterparts. This is where Runes come in. Also created by Casey, the **Runes Protocol** is an attempt to introduce a native, optimized implementation of a fungible token standard for Bitcoin.
# Segregated Witness (SegWit) Upgrade Bitcoin transactions were originally comprised of two primary data elements: outputs and inputs. Outputs create new coins and set the conditions that must be met to spend those coins, such as specifying a public key that must sign the spending transaction. Inputs reference previous outputs and provide data satisfying their spending requirements, like a signature matching the specified public key. To prevent coins from being created out of thin air, the total value of all inputs must be greater than or equal to the total value of all outputs. However, in 2017, the [Segregated Witness (SegWit) protocol upgrade](https://bitcoincore.org/en/2016/01/26/segwit-benefits/) introduced a third data element, the "witness." SegWit restructured Bitcoin transactions by separating them into two distinct components: the transaction data (input and output) and the witness data. This change introduced the concept of [block weight](https://bitcoinwiki.org/wiki/block-weight#:~:text=non%2DSegWit%20addresses.-,Definition%20of%20block%20weight,1%20byte%20of%20block%20weight.), which altered the way block size is measured. Under this system, the weight of the witness data is only 25% of the weight of the transaction data. This means Bitcoin's effective block size increased thanks to SegWit, making it more efficient and cost-effective to store data in the witness portion of the transaction. In essence, SegWit allowed Bitcoin's maximum block size to grow from 1MB to 4MB, comprising 1MB of transaction data and 3MB of witness data. This improvement enabled more transactions to be processed within each block, enhancing Bitcoin's overall scalability and transaction throughput. # Taproot Upgrade Another upgrade in 2021, called [Taproot](https://bitcoin.org/en/releases/0.21.1/) or SegWit v1, enabled numerous enhancements to witness data usage. This soft fork upgrade encompassed three distinct Bitcoin Improvement Proposals (BIPs): BIP 340, BIP 341, and BIP 342, and aimed to enhance privacy, scalability, and composability within the Bitcoin blockchain. One of the most significant impacts of Taproot was the introduction of advanced scripting capabilities in the Witness section of a block. Taproot removed the data limits between the two sections of a block, effectively enabling up to 4MB of data to be stored in the Witness section. This change further increased Bitcoin's scalability by allowing more transactions to be included in each block, improving the network's overall transaction throughput. By combining advanced scripting capabilities with increased data capacity in the Witness section, Taproot paved the way for greater privacy, scalability, and functionality within the Bitcoin ecosystem, while maintaining backward compatibility with existing Bitcoin nodes and wallets. This block section increase enabled a technique dubbed "inscriptions," allowing arbitrary data storage within a transaction's witness section. Though ignored by Bitcoin itself, this arbitrary data can be extracted and parsed by inscription-aware software, allowing for the storage of images and rich media on the blockchain. # Inscriptions [Ord](https://github.com/ordinals/ord)—open-source software that can run on top of any Bitcoin full node—was the technology originally used for such functionality. It allowed individual Satoshis (the smallest units of BTC) to be tracked, giving rise to the concept of “Ordinal Theory,” which ascribes a unique identifier to every single Satoshi on the Bitcoin network. Ordinal Theory is what allows users to "inscribe" arbitrary content onto individual Satoshis, transforming them into digital artifacts that can represent text, images, videos, and more. These Inscriptions came to be known simply as “Ordinals.” They are the epitome of Bitcoin-native digital assets and are thought of as Bitcoin’s version of NFTs (Non-Fungible Tokens). # Ordinal Theory (Ordinals) [Ordinal Theory](https://docs.ordinals.com/) is the numbering scheme that assigns unique identifiers to individual satoshis - the smallest units of Bitcoin. These ordinal numbers track satoshis in the order they're mined and transferred between transaction inputs and outputs on a first-in-first-out basis. Both the numbering and transfer mechanisms rely inherently on order - the numbering on the mining order, and transfers on the input/output order. Hence the name, ordinals. Ordinals require no separate tokens, auxiliary blockchains, or Bitcoin protocol changes. It works natively with Bitcoin's existing architecture. Ordinal numbers have multiple representations: * Integer Notation: 2143094100742059 (The ordinal assigned by mining order) * Decimal Notation: 3911144.10337 (Block height + offset within block) * Degree Notation: 3°254094′314″10497‴ (More on this shortly) * Percentile Notation: 99.99980712060024% (Satoshi's position in total supply) * Name: satoshi (An alphabetic encoding of the ordinal number) Arbitrary assets like NFTs, security tokens, accounts, or stablecoins can utilize ordinal numbers as immutable identifiers attached to individual satoshis. \
# Rarity A natural progression of this numbering system is that people have begun to seek rare and desirable satoshis now that they can be individually tracked and transferred. Ordinal theorists can decide for themselves which sats are most prized, but certain periodic Bitcoin events lend themselves to a rarity hierarchy: * Blocks: A new one roughly every 10 minutes * Difficulty Adjustments: Every 2016 blocks (\~2 weeks) * Halvings: Every 210,000 blocks (\~4 years) * Cycles: Every 6 halvings (\~24 years), with halving and difficulty adjusting aligning This yields the following rarity tiers: * Common: Any non-first satoshi of a block * Uncommon: First satoshi of each block * Rare: First satoshi of each difficulty period * Epic: First satoshi of each halving epoch * Legendary: First satoshi of each cycle * Mythic: First satoshi of the genesis block The degree notation visually denotes an ordinal's rarity: ``` A°B′C″D‴ │ │ │ ╰─ Index of sat in the block │ │ ╰─── Index of block in difficulty adjustment period │ ╰───── Index of block in halving epoch ╰─────── Cycle, numbered starting from 0 ``` Some examples: 1°1′1″1‴ - Common 1°1′1″0‴ - Uncommon 1°1′0″0‴ - Rare 1°0′1″0‴ - Epic 1°0′0″0‴ - Legendary 0°0′0″0‴ - Mythic # Supply of Rare Satoshis **Total Supply:** * `common`: 2.1 quadrillion * `uncommon`: 6,929,999 * `rare`: 3437 * `epic`: 32 * `legendary`: 5 * `mythic`: 1 **Current Supply:** * `common`: 1.9 quadrillion * `uncommon`: 808,262 * `rare`: 369 * `epic`: 3 * `legendary`: 0 * `mythic`: 1 Even uncommon sats are quite scarce currently, with only one mined per 25.6 bitcoin in circulation. \
# Names Each satoshi has an alphabetic name that gets shorter the later it is mined, with the final satoshi being "a." This prevents prized short names from being trapped in the unspendable genesis coins. # BRC-20 In the wake of the “[Non-fungible](https://en.wikipedia.org/wiki/Non-fungible_token)” Ordinals, a natural question arose: "What about [fungible](https://en.wikipedia.org/wiki/Fungibility) tokens on Bitcoin?" In March, a pseudonymous user named [Domo](https://twitter.com/domodata) from Crypto X proposed a theoretical method called BRC-20 that could create a fungible token standard on top of the Ordinals Protocol. The idea behind BRC-20 was to inscribe JSON data onto individual sats via Ordinals, allowing for the deployment, minting, and transfer of fungible tokens. Since JSON is a text-based data format, the BRC-20 method essentially involved inscribing text onto sats to create fungible tokens. In the months following Domo’s proposal, BRC-20 tokens, or text-based Inscriptions, became the dominant type of Inscription and the default fungible token standard on Bitcoin. \
# Why Runes? So if fungible tokens already exist on Bitcoin in the form of BRC-20 tokens, then why were Runes created? The BRC-20 token standard created a protocol for fungible tokens on top of a protocol for non-fungible tokens (Ordinals). Since Ordinals themselves are a meta-protocol built on top of Bitcoin, BRC-20s essentially became a meta-protocol on top of another meta-protocol. While this approach was a clever solution, BRC-20s are relatively complicated and inefficient and were really only intended as an experimental proof-of-concept. Unlike BRC-20s, the Runes Protocol is entirely unrelated to Ordinals or Inscriptions and thus does not inherit any of their complexities. Instead, it is a simple conceptualization that focuses solely on enabling fungible tokens on the Bitcoin network without any additional layers or protocols. By stripping away the complexities inherited from Ordinals and Inscriptions, the Runes Protocol aims to provide a more streamlined and efficient approach to creating and managing [fungible](https://en.wikipedia.org/wiki/Fungibility) tokens on the Bitcoin blockchain. # Bitcoin’s UTXO Model The process of creating and using Bitcoin Runes is closely tied to how Bitcoin transactions are processed on the network. To understand Runes, it's essential to grasp the concept of Unspent Transaction Outputs (UTXOs). A UTXO can be thought of as a banknote. When you make a payment on the network, you essentially send an entire UTXO to the recipient's address and receive a new UTXO in return, much like paying with a $20 banknote and receiving $10 in change. Bitcoin's UTXO model means that instead of having a flat balance in your wallet, you have piles of sats (the smallest unit of Bitcoin) distributed across various UTXOs. Your wallet can spend one or more of these UTXOs, and you will receive a new UTXO as change. The Bitcoin Runes protocol leverages this transaction process to create fungible tokens. Just as the process of creating a Bitcoin ordinal is called "inscribing," the process of creating a Bitcoin rune is called "etching." This process involves creating a "genesis" UTXO that includes the details of the rune's name, symbol, decimals, and total supply. This information is assigned to a single UTXO. When sending out transactions, the protocol creates fractionalized, fungible pieces of the original UTXO, and these new pieces are called Runes. By utilizing Bitcoin’s UTXO model and transaction process, the Runes protocol provides a native and efficient way to create and manage fungible tokens on the Bitcoin network, without the need for additional layers or protocols.

Source: Binance

# The Runes Protocol The Runes Protocol allows Bitcoin UTXOs to hold balances of arbitrary [fungible](https://en.wikipedia.org/wiki/Fungibility) tokens, known as Runes, alongside their satoshis (sats). [Ord](https://github.com/ordinals/ord), the software responsible for enabling the tracking of sats for Ordinals, also provides an implementation of the Runes Protocol. Ord functions as both a [wallet](https://bitcoin.org/en/choose-your-wallet) and a [block explorer](https://mempool.space/). Running Ord alongside a Bitcoin core node allows users to identify which UTXOs contain Runes in addition to their satoshi balances. Neither Ordinals nor Runes require any changes to Bitcoin's software or [consensus rules](https://bitcoin.org/en/how-it-works). The creation of these tokens is made possible by viewing regular Bitcoin transactions through a specialized lens. The [Ord](https://github.com/ordinals/ord) software serves as this lens, giving additional meaning to ordinary Bitcoin transactions. All the information required to reconstruct Ordinals, Inscriptions, and Runes exists within the Bitcoin blockchain itself. One of the strengths of these tokens is the absence of third-party dependencies or off-chain components. Even if everyone were to stop running their [Ord](https://github.com/ordinals/ord) software for a month and then restart it, everything would be updated seamlessly. The entire Ordinals and Runes universe is Bitcoin backward-compatible, with no external dependencies. In essence, the Runes Protocol leverages the existing Bitcoin infrastructure and extends its capabilities to facilitate the creation and management of fungible tokens, without modifying the core Bitcoin protocol or introducing external dependencies. In fact, as the Runes protocol is a meta-protocol built on top of Bitcoin, Bitcoin itself is unaware of and does not need to acknowledge its existence. Users and [validators](https://bitcoin.org/en/bitcoin-core/features/validation) interested in this additional universe can choose to run the [Ord](https://github.com/ordinals/ord) software alongside their nodes, while those uninterested can simply ignore it. # OP\_Return The data representing Runes is stored within the OP\_RETURN field of a Bitcoin transaction. OP\_RETURN is an operation code (opcode) from Bitcoin’s scripting language that enables users to embed arbitrary data onto the blockchain. The official limit for data stored in an OP\_RETURN field is 80 bytes, providing a dedicated space for storing information related to Runes. The [official Runes documentation](https://docs.ordinals.com/runes.html) provides detailed explanations and guidelines on the specific usage and formatting of OP\_RETURN outputs for representing Runes data. This documentation serves as a valuable resource for developers and users interested in understanding and implementing the Runes Protocol within the Bitcoin ecosystem. By utilizing the OP\_RETURN field, the Runes Protocol can seamlessly integrate [fungible](https://en.wikipedia.org/wiki/Fungibility) token data into regular Bitcoin transactions, without modifying the core Bitcoin protocol or introducing external dependencies. This approach aligns with the ethos of Bitcoin's decentralized and open-source nature, allowing for innovative applications and use cases to be built on top of the existing infrastructure. # Motivation for Runes One of the primary motivations behind Runes is to create a dedicated, [fungible](https://en.wikipedia.org/wiki/Fungibility) token standard for Bitcoin without inheriting the complexity of Ordinals. However, this is not the sole reason for its development. [Casey Rodarmor](https://twitter.com/rodarmor) noted that memecoins and speculation continue to gain traction across the crypto world, but largely outside of Bitcoin. It was observed that after users speculated on other [Layer 1 (L1) blockchains](https://www.alchemy.com/best/layer-1-blockchains-l1s) like [Ethereum](https://ethereum.org/en/), [Solana](https://solana.com/), or [BNB Chain](https://www.bnbchain.org/en), they would often use a portion of their profits to buy the base L1 token. For example, if a user made gains within the Solana ecosystem, they might be more inclined to purchase some [$SOL](https://coinmarketcap.com/currencies/solana/) with those funds. Casey aims to see this cycle take place within the Bitcoin ecosystem and is extremely honest and direct about the purpose of Runes: "Runes are a form of degenerate gambling… Runes are not the future of finance… Runes are a fungible token protocol, so that people can meme…" This is a crucial point because some Runes issuers might promise a certain level of utility and value from buying their Runes. While this might hold true in the medium term, and utility may start to develop over time, we should not lose sight of the fact that part of the initial motivation for Runes was to facilitate speculation on top of Bitcoin. # Bitcoin Runes vs BRC-20 To reiterate, Runes are completely unrelated to Ordinals, Inscriptions, and BRC-20 tokens, and are, in fact, direct competitors to BRC-20s. Bitcoin Runes rely on a separate protocol from BRC-20 tokens, resulting in some key technical and practical differences: 1. Runes do not require a [Taproot-enabled wallet](https://learn.uxuy.com/en/list-of-wallets-compatible-with-taproot/): Unlike BRC-20 which needs a Taproot-enabled wallet or access to Bitcoin Layer 2 networks, Runes are completely native to the Bitcoin mainnet. 2. Runes are [Lightning Network](https://lightning.network/)-compatible. You can bridge Runes to and from the Lightning Network and spend them on the network in the same way as BTC. 3. Runes use block space far more efficiently than BRC-20 tokens: BRC-20 token transfers require two on-chain transactions, while Runes only require one. This means we can expect less blockchain bloat from Runes, leading to a less crowded [mempool](https://www.blocknative.com/blog/mempool-intro) and a lower likelihood of spiking fees. Runes are transferred across UTXOs: Runes are transferred in the usual way Bitcoin transfers happen. This means that any protocol that works with Bitcoin, whether it's a wallet, a bridge, the [Lightning Network](https://lightning.network/), or other Layer 2 solutions, should (in most likelihood) work with Runes. This is not necessarily the case with BRC-20 tokens, which require additional infrastructure to support Ordinals before they can support BRC-20s.
FeatureBRC-20sRunes
DesignBRC-20 is a meta-protocol on top of Ordinals. This adds complexity.Runes are specifically tailored for fungible tokens and designed to be very simple. They do not inherit the complexities of Ordinals.
TechBRC-20 was released as an experimental specification. Implementation was done by the community.Runes has been released with a detailed specification and a reference implementation.
Data StorageUse of witness data (up to 4MB) leads to a higher on-chain storage.Use of the OP_RETURN field (80 bytes) is more efficient.
EfficiencyRequires two on-chain transactions for every transfer.Users can transfer Runes via normal Bitcoin transactions - just one transaction per transfer needed.
DistributionOpen Mint: Once created, anyone can mint.Greater flexibility as it supports various forms of distribution, incl. open-mints, pre-mining, delayed mints etc.
CompatibilityOrdinals-supported wallets only.UTXO support gives Runes greater compatibility with wallets, L2s, bridges and DeFi apps.
# Launch The Bitcoin Runes protocol was announced in September 2023 and officially launched alongside the Bitcoin halving on April 20th, 2024. The first-ever Rune, Rune #0, was etched by [Casey Rodarmor](https://twitter.com/rodarmor), the founder of the Runes Protocol. This inaugural Rune is called [UNCOMMON•GOODS](https://luminex.io/rune/UNCOMMON%E2%80%A2GOODS). Regarding the minting process for UNCOMMON•GOODS: * Minting started on the Halving block and is set to continue until the next Bitcoin halving in 2028. * Users can mint the Rune as many times as they desire, but each individual mint can only claim one UNCOMMON•GOODS Rune at a time. * The divisibility of UNCOMMON•GOODS is 0, meaning it cannot be subdivided any further into smaller units. This initial Rune serves as the pioneering example of the Runes Protocol's capabilities. It sets the stage for the future adoption and development of Bitcoin-based fungible tokens through the Runes ecosystem. # The First Runes Here is a list of the first runes that were etched at [block height 840,000](https://mempool.space/block/0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5).

Source: luminex.io

# What are Bitcoin Runes For? Much like ERC-20 tokens on the Ethereum network, you can use Runes to launch any fungible token project you like. The only difference is that your runes project cannot rely on a complex [smart contract](https://en.wikipedia.org/wiki/Smart_contract). If you plan to create token-gated apps or decentralized governance platforms, Bitcoin Runes aren’t the asset type you want. However, they do show a lot of potential for the following uses: # Memecoins [Memecoins](https://coinmarketcap.com/view/memes/) will likely always play a part in the crypto market. NFT memes have sold for millions of dollars. Some of the most popular coins in existence are purely built on memes. As the most popular network, many Bitcoin memecoins using the BRC-20 protocols have seen huge successes. In preparation for the Runes launch, some leading Bitcoin memecoins, such as [WZRD](https://unisat.io/market/brc20?tick=wzrd) and [PUPS](https://unisat.io/market/brc20?tick=pups) announced they would migrate their existing BRC-20 tokens to the new Runes protocol. We are likely to see a lot more Bitcoin memecoins launching as Runes into the future.
# DeFi Bitcoin runes also open up the possibility of [DeFi](https://chain.link/education/defi#:~:text=DeFi%20Definition,%2C%20smart%20contracts%2C%20and%20oracles.) on the Bitcoin network. Their [fungibility](https://en.wikipedia.org/wiki/Fungibility) means they are easy to split into pieces and put back together again. Since Runes are compatible with both the Bitcoin mainnet and Lightning network, they can be integrated into borrowing and lending platforms. This could mark the beginning of a new era for the Bitcoin network. While Bitcoin fungible tokens (and therefore DeFi) were possible previously, the cheaper and more efficient Runes protocol will allow for more innovative and user-friendly DeFi solutions on Bitcoin.
# Etching (Creating a Rune) Much like the process of creating a Bitcoin ordinal is called inscribing, the process of creating a Bitcoin rune is called “etching.” This involves creating a “genesis” UTXO, which includes the details of the rune’s name, symbol, decimals, and total supply. This information is assigned to a single UTXO. Sending out transactions creates fractionalized, fungible pieces of the original UTXO, and those new pieces are called Runes. Etching creates new runes with immutable properties set by the etcher:
# Name * Unique and can consist of any combination of uppercase letters A-Z * Between 13-26 characters long at launch (will change across Seasons) * Can contain a "spacer" (bullet) for readability, e.g. UNCOMMON•GOODS * Uniqueness is independent of spacers * Spacers can only be between two letters and don't count toward the character limit # Symbol * Single Unicode point to represent the "currency" (can be an emoji) * Does not need to be unique # Divisibility Defines how many sub-units a Rune can be divided into (e.g. divisibility of 1 means each Rune can be divided into ten sub-units; a rune with divisibility 2 may be divided into a hundred, and so on) # Premine Issuer/etcher can pre-allocate themselves units of a new Rune # Terms * Open mint allows any user to mint and allocate Rune units by paying fees * Can have a cap on number of mints * Can set amount minted per mint * Can set start/end block heights for minting window # Minting The process of acquiring a new Rune is called minting, similar to how you mint an NFT. # Transfering The final stage of the process is transferring Runes. When Bitcoin UTXOs contain Runes they are transferred to the transaction outputs when you transfer that UTXO. Specifically, if you transfer multiple UTXOs with different amounts of various Runes, all of those Runes will be sent to the first non-OP\_RETURN output of that transaction. The user can utilize a Runestone (discussed in detail in the next section) to customize and manage how and which input Runes get transferred to which outputs. These Runestones allow users to control the distribution of Runes across different outputs during a transaction, providing flexibility and granular control over the transfer process. In essence, a creator etches a Rune, setting its properties, and then users can mint and transfer it — an intentionally simple system.
# Runestone A Runestone is a set of encoded directives stored within the OP\_RETURN field of a Bitcoin transaction. It serves as a blueprint for specifying the desired actions to be performed with Runes during that transaction. For instance, a Runestone can contain instructions such as "Mint this particular Rune," "Etch a brand-new Rune," or "Transfer these specific Runes." Without a Runestone, the default behavior is that all Runes present in the input UTXOs will be automatically transferred to the first non-OP\_RETURN output of the transaction. To deviate from this default and exercise more control, users can incorporate a Runestone and include an [Edict](https://x.com/rodarmor/status/1782551238116356567), which provides explicit instructions on which Runes should be routed to which outputs. Bitcoin currently imposes a limit of 80 bytes for data stored in the OP\_RETURN field. While typical Runestones comfortably fit within this constraint, more complex transactions involving the arbitrary distribution of multiple Runes across numerous outputs (such as [airdrops](https://www.investopedia.com/terms/a/airdrop-cryptocurrency.asp)) may necessitate a larger Runestone. Should Runes attain widespread popularity, the discussion around increasing Bitcoin's 80-byte OP\_RETURN size limit could gain traction, as it would allow for more intricate Runestone instructions to be accommodated. It's worth noting that most users are unlikely to interact directly with Runestones. Front-end providers are expected to abstract and streamline this process, offering a more user-friendly experience. # Rune Seasons One of the fascinating aspects of Runes is their naming system. A Rune's name must be unique and composed entirely of uppercase letters from A to Z. At launch, these names could range from 13 to 26 characters in length. However, over time, users will gain the ability to etch Runes with progressively shorter names. This will occur through a structured rollout, where every four months following the launch, a new, shorter character limit for Rune names will be unlocked. For instance, by August 2024, four months after Runes' debut, all 12-character Rune names will become available for etching. Four months later, the 11-character Rune names will unlock, and so on. This process is scheduled to continue until the next Bitcoin Halving in 2028, with the final four-month period allowing for the etching of single-character Rune names. These unlocks will happen gradually, on a block-by-block basis. Each new block will unveil additional available Rune names, ensuring that all possible names within a given character count are unlocked by the end of the respective four-month period. This rolling release mechanism creates an inherent hype cycle for Runes over the next four years, effectively dividing their evolution into distinct "seasons." Moreover, it presents intriguing implications from a market perspective. For example, if the unlocking of 3-6 character Rune names coincides with a bear market, users might seize the opportunity to etch and mint highly coveted, shorter Rune names at a time when Bitcoin prices and transaction fees are relatively low. # Ecosystem

Source: https://transak.com/

# Launchpads These are specialized platforms that enable developers to launch new Runes projects: [@runespad](https://twitter.com/runespad) [@ordinalsbot](https://twitter.com/ordinalsbot) [@luminexio](https://twitter.com/luminexio) [@trygamma](https://twitter.com/trygamma) [@ordzaar](https://twitter.com/ordzaar) [@SatsXio](https://twitter.com/SatsXio) [@ALEXLabBTC](https://twitter.com/ALEXLabBTC) [@ord\_bit](https://twitter.com/ord_bit) [@Magic\_Runes](https://twitter.com/Magic_Runes) [@btctoolpro](https://twitter.com/btctoolpro) # Marketplaces These are platforms where users can trade and collect Runes (generally using BTC as the currency): [@MagicEden](https://twitter.com/MagicEden) [@meonbtc](https://twitter.com/MEonBTC) [@ordinalswallet](https://twitter.com/ordinalswallet) [@unisat\_wallet](https://twitter.com/unisat_wallet) [@runealpha\_btc](https://twitter.com/runealpha_btc) [@whalesmarket](https://twitter.com/WhalesMarket) [@satsxio](https://twitter.com/SatsXio) [@rune\_pro](https://twitter.com/Rune_Pro) [@saturn\_btc](https://twitter.com/Saturn_btc) [@alexlabbtc](https://twitter.com/ALEXLabBTC) # Wallets These are cryptocurrency wallets that are Runes-compatible. Can be used to store, send, and receive Runes: [@XverseApp](https://twitter.com/XverseApp) [@unisat\_wallet](https://twitter.com/unisat_wallet) [@meonbtc](https://twitter.com/MEonBTC) [@okx](https://twitter.com/okx) [@leatherbtc](https://twitter.com/LeatherBTC) [@ordinalswallet](https://twitter.com/ordinalswallet) # Data / Analysis Sites with in-depth Bitcoin Runes data and analysis with real-time updates: [@runes\_legacy](https://twitter.com/runes_legacy) [@GeniiData](https://twitter.com/GeniiData) [@ordiscan\_com](https://twitter.com/ordiscan_com) [@bestinslotxyz](https://twitter.com/bestinslotxyz) [@RunesMarketCap](https://twitter.com/RunesMarketCap) [@rune\_mine](https://twitter.com/rune_mine) [@ninjalerts](https://twitter.com/ninjalerts) # Explorers These are websites where you can explore and view all Runes on the Bitcoin network. [@ord\_io](https://twitter.com/ord_io) [@luminexio](https://twitter.com/luminexio) [@geniidata](https://twitter.com/GeniiData) [@runealpha\_btc](https://twitter.com/runealpha_btc) [@okx](https://twitter.com/okx) [@ordiscan\_com](https://twitter.com/ordiscan_com) [@rune\_mine](https://twitter.com/rune_mine) # Storing Bitcoin Runes Runes are still highly experimental assets, if you want to get involved, proceed with caution. If you want to interact with Bitcoin Runes, it’s always best to stick to the most intuitive and secure methods. An offline wallet is essential to protect you from online threats, but you’ll also need a wallet compatible with these experimental assets. To get the best of both worlds, connect a runes-compatible wallet to your Ledger device. Currently, you can’t visualize your runes in Ledger Live, but using your Ledger device alongside a third-party wallet will keep your private keys secure while exploring Runes. # 5. Terminology Rune mints can be open (allowing anyone to mint) or closed, subject to terms: **Cap**: Total mintable supply Amount: Units created per mint. **Start/End Height:** Blocks between which minting is allowed Start/End Offset: Blocks from etching between which minting is allowed **Minting:** When a mint is open per its terms, anyone can mint that rune by creating new units up to the cap. **Transferring:** Input runes transfer to outputs, modulated by Runestone edicts (rune ID, amount, output) and pointers specifying a default output. Remaining unallocated runes follow the runestone pointer or first non-OP\_RETURN output. **Burning:** Runes can "burn" (destroy) by transferring to OP\_RETURN outputs via edicts/pointers. **Cenotaphs:** Invalid Runestones with malformed data are "cenotaphs". Input runes are burned, etched runes are unmintable, and minted runes burn - though counting against the cap. Cenotaphs allow introducing new runestone semantics in the future, while appearing to legacy clients as simply burning runes instead of relocating them unpredictably.