Розроблення Runes-токена (Bitcoin)
До Runes була путаниця: BRC-20 працював поверху Ordinals, створював inscription для кожного transfer, засорював mempool "junk" транзакціями. Casey Rodarmor, створювач Ordinals, розробив Runes як clean-room рішення для fungible токенів на Bitcoin — без зайвих даних, з використанням існуючих біткоін-примітивів ефективно. Runes запустилися в блоці 840,000 (halving 2024).
Як працює протокол Runes
Runes не потребує змін в Bitcoin консенсусі. Протокол живе в OP_RETURN outputs — дані в них не зберігаються в UTXO set, блокчейн не засорюється (на відміну від BRC-20, який зберігав стан у satoshi).
Ключові концепції:
Runestone — повідомлення протоколу, закодоване в OP_RETURN output транзакції. Містить інструкції: etching (створення), mint, transfer, edict (переміщення балансів між outputs).
UTXO як носій балансу — балансі Runes не в глобальному маппінгу (як ERC-20), а в конкретних UTXO. Якщо ви тримаєте 1000 RUNE, значить у вас є UTXO з attached balance 1000 RUNE. Це фундаментальне відхилення від EVM токенів.
Rune ID — {block_height}:{tx_index} транзакції etching. Наприклад, перший Rune etched у блоці 840,000 має ID 840000:3.
Spacers — візуальні розділювачі в імені (точки), UNCOMMON•GOODS — стандартний перший Rune від Casey.
Створення Rune (Etching)
Etching — транзакція з Runestone в OP_RETURN, об'являючи новий Rune:
Параметри etching:
- divisibility: 0–38 (аналог decimals в ERC-20, але для сатоші-субодиниць)
- symbol: Unicode символ для відображення
- premine: кількість токенів для etcher'а одразу
- terms: умови open mint (якщо дозволений)
- amount: скільки за одну mint транзакцію
- cap: максимальне кількість mint'ів
- height: [start_block, end_block] для open mint
- offset: [start_offset, end_offset] відносно etching блока
- turbo: флаг сумісності з майбутніми версіями протоколу
Дані Runestone кодуються через varint encoding (LEB128) — компактне представлення чисел змінної довжини. Кожен тег — пара (tag, value).
Практична реалізація через ord CLI
# Встановлення ord (офіційний клієнт)
cargo install ord
# Синхронізація з Bitcoin нодою (або через RPC до зовнішної)
ord --bitcoin-rpc-url http://user:pass@localhost:8332 index
# Створення wallet
ord wallet create
# Etching нового Rune
ord wallet etch \
--rune "MYTOKEN•NAME" \
--divisibility 8 \
--symbol "M" \
--supply 21000000 \
--premine 21000000 \
--fee-rate 20
# Mint (якщо включений open mint)
ord wallet mint \
--rune "MYTOKEN•NAME" \
--fee-rate 20
Через бібліотеку (JavaScript/TypeScript)
Для інтеграції в додаток використовуйте runestone npm пакет або прямо bitcoinjs-lib:
import { Runestone, Etching, Terms, RuneId } from "runestone-lib";
import * as bitcoin from "bitcoinjs-lib";
function buildEtchingTransaction(
utxo: UTXO,
runeName: string,
divisibility: number,
supply: bigint,
feeRate: number
): bitcoin.Transaction {
const runestone = new Runestone({
etching: new Etching({
rune: Rune.fromString(runeName),
divisibility,
symbol: "T",
premine: supply,
turbo: true,
}),
// Edicts визначають розподіл premine по outputs
edicts: [{
id: new RuneId(0n, 0n), // 0:0 = сам себе при etching
amount: supply,
output: 1n, // output index для premine
}],
});
const psbt = new bitcoin.Psbt({ network: bitcoin.networks.bitcoin });
// Input: funded UTXO для оплати fee
psbt.addInput({
hash: utxo.txid,
index: utxo.vout,
witnessUtxo: { script: utxo.scriptPubKey, value: utxo.value },
});
// Output 0: OP_RETURN з Runestone
psbt.addOutput({
script: bitcoin.script.compile([
bitcoin.opcodes.OP_RETURN,
Buffer.from("52554e45", "hex"), // RUNE magic bytes
runestone.encipher(),
]),
value: 0,
});
// Output 1: одержувач premine (не повинен бути dust)
psbt.addOutput({
address: recipientAddress,
value: 546, // dust limit для P2WPKH
});
// Output 2: сдача
psbt.addOutput({ address: changeAddress, value: changeAmount });
return psbt;
}
Логіка передачи: edicts
Передача Runes — транзакція з Runestone, що містять edicts. Кожен edict задає: який Rune, скільки, в який output.
Важливе правило протоколу: якщо Rune баланс вхідного UTXO не повністю охоплений edicts — остаток автоматично йде в перший non-OP_RETURN output (це називається "pointer"). Жодної явної вказівки = перший output. Це відхилення від EVM, де "невказані" кошти залишаються у відправника.
Приклад: у вас UTXO з 1000 RUNE
Транзакція з edict: send 300 RUNE → output 2
Автоматично: 700 RUNE → output 1 (default pointer)
Якщо output 1 = burn address — ви нечаяно спалили 700 RUNE.
Це — головна причина втрати токенів — непорозуміння pointer логіки. При розробці гаманця для Runes потрібно явно конфігурувати pointer output на адресу change користувача.
Індексування Runes балансів
Runes не мають стандартного RPC API в Bitcoin Core — потрібен окремий індексер. Варіанти:
ord indexer — офіційний, написаний на Rust. Потребує повної Bitcoin ноди + SSD для індексу (~50–100GB). Надає JSON API:
# Запуск з API сервером
ord --bitcoin-rpc-url http://localhost:8332 server --http-port 8080
# Баланс адреси
curl http://localhost:8080/runes/balance/bc1q...
# Інформація про Rune
curl http://localhost:8080/rune/MYTOKEN•NAME
Hiro Ordinals API — hosted, платний, без необхідності поднімати свою ноду. Підходить для MVP.
Unisat API — аналогічно, REST API з підтримкою Runes. Rate limited на free tier.
Для production додатка з високою нагрузкою — власний ord індексер обов'язковий. Залежність від зовнішнього API створює single point of failure.
Типові кейси
Governance токен Bitcoin-native додатка — проект хоче тримати управління токен "native" на Bitcoin без кастодіальних ризиків ERC-20 wrapped BTC. Runes підходить якщо governance механіка проста (по суті off-chain snapshot voting, Rune як weight).
In-game currency / reward token — гра з Bitcoin-centric аудиторією хоче нагороджувати користувачів токенами на Bitcoin. Runes з open mint механікою.
Мем-токени — найпоширеніший use case у 2024 році. Простий etching, открытий mint, листинг на Magic Eden / UniSat.
Обмеження, які потрібно розуміти
Runes — не смарт-контракти. Жодних conditional transfers, жодного staking, жодного DEX без окремого рішення. Вся логіка, яку ви звикли робити в Solidity, тут неможлива on-chain. Можливі тільки: створення, transfer, burn.
Для DeFi логіки поверх Runes потрібен або offchain matching (централізований orderbook), або окремий L2/sidechain з перевіркою Runes UTXO через Bitcoin SPV.
Строк розроблення: etching та базовий гаманець — 1–2 тижні. Повна інтеграція з індексером, функціональністю маркетплейсу та custody рішенням — 6–10 тижнів.