Bitcoin Runes: What They Are, How They Work, and Who’s Building on Them
Runes is a fungible token protocol that lives on Bitcoin’s native UTXO model. It was designed to reduce baggage from earlier token experiments (like BRC-20 inscriptions) and to make token state easier to index and move, without leaving the main chain. This guide explains Runes end-to-end: how the protocol encodes token state, what “etching” and “edicts” mean in practice, what minting and trading flows look like, how fees and liquidity behaved in the wild, and where Runes fits next to Ordinals and BRC-20. We’ll also cover risks, common scams, and a practical tool stack so you can experiment safely.
TL;DR: Runes is a fungible token standard for Bitcoin that encodes token actions directly in regular Bitcoin transactions. A creator etches a rune (defines its name, divisibility, rules, and optionally premine), users mint according to those rules, and future transfers are expressed via edicts that assign token balances to specific transaction outputs. Compared to BRC-20, Runes is more UTXO-native, easier to index, and less dependent on heavy inscription metadata. Compared to Ordinals (NFT-style media inscriptions), Runes focuses on fungible supply, not individual collectibles. Expect fee spikes during popular mints, a fast-moving tool ecosystem, and the usual risk surface of memes, low-effort launches, and spoofed tickers. Start small, verify indexers, and use reputable wallets/markets.
What Are Runes? (Plain-English)
Bitcoin uses a UTXO (unspent transaction output) model: every transaction consumes one or more previous outputs and creates new ones. Runes leans into that model for fungible tokens. Instead of keeping balances in a smart contract account (as on account-based chains), Runes treats which output holds how many units of a rune as the canonical state, described by compact protocol data attached to a normal Bitcoin transaction.
In practice, a rune lifecycle has three phases:
- Etch: The creator defines a new rune, its name/ticker, divisibility (decimals), optional supply or premine, and mint rules. Etching is the “deploy” step.
- Mint: Users (or the creator) mint units under the configured rules: open/closed windows, per-tx caps, schedules, and so on.
- Transfer via Edicts: For any later transaction, the sender specifies how many units of a given rune go to each output. Indexers can then reconstruct balances from the chain history without reading large inscription blobs.
- Cleaner indexing: Runes keeps state closer to UTXOs, which reduces reliance on ad-hoc JSON inscriptions.
- Better fit for wallets: Assigning rune units to outputs maps naturally to Bitcoin’s existing spend/change behavior.
- No external L2 needed: Everything happens on mainnet transactions (with the usual Bitcoin fee market trade-offs).
How Runes Work Under the Hood (UTXO-Native Logic)
1) Etching a Rune
“Etching” is the creation of a new rune definition. The etch transaction carries protocol data (e.g., via OP_RETURN) that encodes the rune’s immutable properties: name, ticker, divisibility, and optional premine or supply constraints. From that point onward, the rune ID is bound to that transaction in Bitcoin history. Think of an etch as a registry entry everyone can independently verify.
2) Minting Supply
A rune can be open-mint (anyone can mint within rules), creator-mint (only the etcher mints), or fixed (premine only). Mint rules typically define:
- Start/end heights (block windows) for valid mints.
- Caps per transaction or per block to slow stampedes.
- Optional allowlists or reserved allocations (if encoded by the etcher).
A mint transaction proves it followed the rules and assigns the newly created units to one or more outputs, setting up balances for later transfers.
3) Transfers via Edicts
Post-mint, transfers are expressed as edicts: instructions embedded in a standard Bitcoin transaction that map “X units of rune R go to output i, and Y units go to output j,” etc. Because the output graph is explicit, indexers can recompute balances deterministically: follow UTXOs, apply the edicts, subtract consumed outputs, and tally what remains.
For each block in order:
For each tx:
- Parse OP_RETURN / protocol field for rune actions
- If "etch", add rune definition to registry
- If "mint", credit outputs with minted units
- If "edict", move units from inputs' rune balances to specified outputs
Balances = Sum of units bound to currently unspent outputs (UTXOs)
This is conceptually simpler than parsing arbitrary JSON inscriptions scattered across transactions (as many BRC-20 flows required).
BRC-20 vs Runes vs Ordinals (Side-by-Side)
| Dimension | Runes (Fungible) | BRC-20 (Fungible via Inscriptions) | Ordinals (Non-Fungible Media) |
|---|---|---|---|
| Data Model | UTXO-native; balances assigned to outputs via edicts | JSON inscriptions & indexer conventions on top of Ordinals | Inscribe media/metadata to satoshis (NFT-like) |
| Primary Use | Fungible tokens (memes, community tokens, utilities) | Fungible tokens (earlier standard) | Collectibles/media (images, text, art) |
| Indexing Complexity | Lower: follow outputs + edicts | Higher: parse inscriptions & conventions; more edge cases | Medium: per-inscription ownership is straightforward |
| Spam/UTXO Bloat Risk | Mitigated by output-bound balances, but still fee-sensitive | Higher during mania; more arbitrary data pushed on-chain | Varies with media size and mint waves |
| Wallet UX Fit | Good for UTXO wallets; matches spend/change intuitions | Dependent on inscription-aware tooling | Good for NFT-style flows; not fungible |
In short: Runes is a fungible token standard built to feel native to Bitcoin’s UTXO graph. BRC-20 pioneered token mania on Bitcoin, but leaned heavily on inscriptions and off-chain conventions. Ordinals remains the go-to for NFT-style collectibles. Each has a place, just pick the tool that matches your design goal.
Minting & Trading Flows (Step-by-Step)
A) Safe Minting Flow
- Get a compatible wallet. Use a Bitcoin wallet that explicitly supports Runes (balance display, edict parsing, and safe send). Keep another wallet for cold storage.
- Fund fees separately. You still pay BTC network fees; keep a small buffer for retries (don’t overfund mint wallets).
- Verify the etch. Check the rune’s etch transaction on a trusted explorer to confirm ticker, divisibility, and mint window. Beware spoofed tickers.
- Mint within the rules. Follow the mint UI or craft the tx to respect per-tx caps and windows. Watch mempool congestion and fee rate before you click.
- Receive outputs. After confirmation, your minted units are assigned to outputs (UTXOs) in your wallet. Good wallets will show per-rune balances.
- Move to safer storage (optional). If you minted a meaningful amount, consider consolidating to a wallet with better security hygiene.
B) Trading Flow (P2P / Marketplace)
- Choose a venue. Use a marketplace or OTC desk that supports Runes, or swap P2P with clear terms. Avoid blind signatures.
- Quote, then construct tx. The seller constructs a transaction with edicts assigning rune units to the buyer’s output and receives BTC in return. Marketplaces abstract this with order books/escrows.
- Check the edict. Verify that the edict assigns the correct rune and amount to your receiving output index before broadcasting.
- Finality. Wait for confirmations; high-value transfers generally wait for multiple blocks (conservative default: 3–6 confirms).
- Post-trade hygiene. Re-scan balances in your wallet; archive the txid; beware dust that might confuse UX later.
Total Cost ≈ (Tx_vbytes × Fee_rate_sat/vB) + (Marketplace fee, if any) Tips: - During hot mints, fee rates spike—set a max you’re okay with and be ready to skip. - Consolidate small UTXOs off-peak; large input counts inflate tx size and cost.
Fees & Liquidity Patterns (What We Observed)
Runes mints and headline launches tend to coincide with Bitcoin fee spikes just like NFT “gas wars” on other chains. When demand clusters around a small time window (e.g., a hyped etch opening), users bid up inclusion to win allocations. That creates three practical realities:
- Lottery dynamics: Popular open-mints resemble a fee auction. Whales willing to pay high sats/vB get in first; late transactions might confirm after caps are reached.
- Liquidity pockets: Immediately after a successful mint, secondary liquidity often concentrates on a handful of markets and OTC channels. Slippage can be steep; spreads normalize later.
- Indexing sync: New runes can take time to propagate across indexers/wallets. Until explorers agree on view, expect inconsistent balances/metadata in some UIs.
If you’re trading, the safest habit is to refuse races you can’t price. Wait for calmer blocks, more confirmations, and better visibility across explorers. For creators, consider rules that reduce stampedes (per-tx caps, longer windows) so retail doesn’t get pushed out by fee sniping.
Risks, Scams & Gotchas (Read Before You Mint)
- Spoofed tickers: Same/similar names; verify the etch txid, not just the name.
- Indexer disagreement: Early indexers may disagree on edge cases; cross-check on multiple explorers.
- Phishing UIs: Fake mint pages craft transactions that misassign edicts; confirm destination outputs in your wallet.
- Dust & change confusion: Small BTC change outputs and rune outputs can confuse wallets that aren’t rune-aware.
- Fee spikes: Bidding wars can cost more than allocations are worth; walk away if sats/vB exceed your threshold.
- Use known wallets/markets that explicitly support Runes.
- Bookmark explorer pages for official etch txids.
- Test with tiny amounts first; treat hype windows with extra skepticism.
- Keep mint/trade funds separate from long-term BTC holdings.
- Never sign transactions you don’t understand, verify edicts and outputs.
Remember: Runes reduce some technical friction relative to BRC-20, but the human layer (memes, hype, spoofing) doesn’t change. If something “can’t lose,” it usually can.
Tool Stack: Wallets, Explorers, Indexers, Markets
The Runes ecosystem evolves quickly. Favor tools that clearly state protocol support (Runes-aware parsing, balance display, edict verification) and that publish security disclosures. A sensible stack looks like this:
- Wallets: A primary wallet with explicit Runes support for mint/trade; a separate cold wallet for BTC and long-term runes storage.
- Explorers: Use at least two independent explorers to cross-check etch metadata, mint rules, and balances.
- Markets: Choose marketplaces that show edict details, trade proofs, and settlement confirmations not just “success” banners.
- Indexers: If you build, run your own indexer to avoid third-party lags; expose a read-only API for your app.
- Alerts: Set fee alerts and indexer lag alerts so you’re not minting blind during congestion.
Notes for Builders (Indexing, UX, Compliance)
Indexing & Data
- Implement a deterministic parser for etch/mint/edict fields and document edge cases (e.g., malformed edicts, out-of-window mints).
- Cache per-block rune deltas; don’t recompute the world from genesis for every request.
- Provide human-readable diffs for transfers so users can audit what changed for their UTXOs.
Wallet UX
- Show which outputs hold which runes; label change outputs clearly.
- Pre-flight checks: warn if a tx would burn or misroute rune balances due to wrong output order.
- Offer easy “consolidate rune UTXOs” off-peak to reduce future fee waste.
Compliance & Operations
- Establish listings criteria (etch validation, supply rules) and keep a takedown process for spoofed tickers.
- Rate-limit hot mints; show fee curve projections so users aren’t surprised by sats/vB during peak windows.
- Publish incident post-mortems when indexers desync; trust is your moat in a racey market.
Due-Diligence Checklist for Runes Buyers
- Etch verification: Confirm the etch txid and parameters on at least two explorers.
- Mint mechanics: Window length, per-tx caps, premine % are these fair and transparent?
- Distribution: How concentrated are early holders? Any creator-controlled supply?
- Liquidity venues: Where will you actually sell? Depth and spreads in the first week?
- Tooling maturity: Does your wallet cleanly handle rune UTXOs? Any known bugs?
- Team signals: Do maintainers publish documentation, changelogs, and incident notes?
- Exit hygiene: Keep a fee buffer and an exit plan; don’t hold what you can’t transfer during congestion.
Frequently Asked Questions
Are Runes “better” than BRC-20?
They’re different. Runes tries to align fungible tokens with Bitcoin’s UTXO graph, which simplifies indexing and wallet logic. BRC-20 used inscriptions and conventions that worked, but carried more parsing edge cases. Both live on mainnet and both pay the same fee market.
Do I need a special wallet?
Yes, use a wallet that explicitly supports Runes (balance display and edict-aware sends). Generic BTC wallets might not manage rune UTXOs safely and can confuse change outputs.
Why do fees spike during launches?
Because Bitcoin blockspace is a public auction. Popular mints cause users to outbid each other for inclusion. If fee rates exceed your tolerance, skip the window or wait for calmer blocks.
Can I lose tokens by sending incorrectly?
Yes. If your transaction misassigns edicts or spends the wrong UTXOs, you can burn or misroute tokens. Use wallets that preview exact outputs and amounts; verify before signing.
What about scams?
Spoofed tickers, phishing UIs, and fake explorers are common. Bookmark official etch pages, avoid blind signatures, and don’t mint with your long-term BTC wallet.
Glossary
- UTXO: Unspent Transaction Output; Bitcoin’s native accounting unit. Transactions consume old outputs and create new ones.
- Etch: The act of creating a new rune definition (name, divisibility, rules).
- Mint: Creating supply under an etch’s rules; assigning units to outputs.
- Edict: A transfer instruction in a transaction specifying how many rune units go to which outputs.
- Fee Rate (sats/vB): Satoshis per virtual byte; higher during congestion.
- Indexer: Software that parses the chain to reconstruct rune balances from UTXOs and edicts.