Bitcoin-native fungible token protocol that uses the UTXO model and OP_RETURN runestones to etch, mint, and transfer fungible assets. Activated at the April 2024 halving.
- 01Bitcoin-native fungible tokens
- 02UTXO-based supply mechanics
- 03etching new runes
- 04Runes wallets and explorers
- 05DEX listings for Runes
- # Build/install the ord indexer + wallet (Rust)
- cargo install ord
- # Or use the JS helpers
- pnpm add runelib
| Variable | Scope | Description |
|---|---|---|
| BITCOIN_RPC_URL | Server | Bitcoin Core RPC URL (e.g. http://user:pass@127.0.0.1:8332). |
| ORD_INDEX_PATH | Server | Path to the ord index database used for Runes lookups. |
Use the Runes protocol for Bitcoin-native fungibles. Run `ord` (linked to Bitcoin Core via `BITCOIN_RPC_URL`) to index Runes; `ord wallet etch --rune NAME --divisibility 8 --premine 0 --supply 21000000 --symbol R` etches a new rune. Mint with `ord wallet mint --rune NAME --fee-rate 5`. Transfer with `ord wallet send --fee-rate 5 <addr> 100:NAME`. In-app, build runestones programmatically with `runelib` (`Runestone`, `Edict`, encode into `OP_RETURN`) and append to a PSBT before user signing in Xverse/Leather/Unisat.
- ⚑Runes are UTXO-based: a single output carries a balance, and 'change' must be split correctly — losing a runestone in fees burns supply permanently.
- ⚑OP_RETURN size limits and runestone encoding rules are strict; a malformed runestone is treated as a cenotaph and burns the affected runes.
- ⚑Bitcoin finality is probabilistic — wait at least 1-3 confirmations before crediting balances, more for high-value transfers.
- ⚑There is no 'approve' primitive: every transfer is an explicit signed transaction by the holder; design UX around per-action signing, not allowances.
- ⚑Runes supply, divisibility, and symbol are fixed at etch time and immutable — there is no governance or upgrade path.
- ⚑Mempool fee spikes can strand mints; expose dynamic fee selection (sat/vB) to users.