706 / 736RUNE

Runes

Über Bitcoin-UTXOs verfolgte fungible Token

Runes ist ein Anwendungsprotokoll zum Erzeugen, Minten und Übertragen fungibler Einheiten über Bitcoin; Anweisungen stehen in OP_RETURN-Runestones und ein Indexer rekonstruiert den Zustand nach dem ord-Referenzcode.

Der Bitcoin-Konsens validiert normale Transaktion und Scripts, kennt aber keine Rune-Salden; mit ord kompatible Software interpretiert Etchings, Mint Terms, Edicts, Allocations, Burns und Cenotaphs.

Runes verfolgt fungible Einheiten über Bitcoin-UTXOs als Anwendungszustand. Das Protokoll aktivierte in Block 840 000 und ignoriert frühere Runestones; es ist weder neuer Bitcoin-Assettyp noch Konsensänderung. [4]

Der erste Ausgang mit OP_RETURN OP_13 trägt den Runestone-Payload. Der Indexer verbindet Data Pushes, decodiert 128-Bit-LEB128-Integer und liest Etching, Mint, Pointer und Edicts; spätere passende Ausgänge werden nach dem ersten nicht versucht. [1]

Ein Etching erzeugt eine BLOCK:TX Rune ID und kann Name, Divisibility, Symbol, Premine und offene Mint Terms mit Amount, Cap und Height- oder Offset-Fenster setzen. Name oder Symbol belegen keine knappe Menge; entscheidend sind vollständige Etching Transaction und Terms. [1]

Input Runes sowie Mint und Premine sind zunächst unallocated. Edicts weisen sie Outputs zu; der Rest geht an den Pointer oder ersten Non-OP_RETURN-Ausgang. Eine falsche Konstruktion kann Einheiten fehlleiten oder verbrennen. [1]

Der ord-Code ist die normative Runes-Spezifikation; bei Abweichung gilt laut Dokumentation sein Verhalten. Bitcoin Full Nodes prüfen die Transaktion, nicht Rune-Namen, Supply, Mint Cap oder Salden; Indexer müssen denselben Zustand berechnen. [2]

Ein fehlerhafter Runestone ist ein Cenotaph. Unbekannte gerade Tags oder Flags, falsche Varints, ungültige Output-Indizes oder Pointer und andere Parsefehler können alle Input Runes verbrennen; Etching wird unmintable mit Supply null und ein ungültiger Mint kann Cap verbrauchen. [1]

Namen werden nach Aktivierung in Perioden von 17 500 Blöcken freigeschaltet. Nicht reservierte Namen brauchen ein Commitment in einem Input Witness Tapscript aus einem Output mit mindestens sechs Bestätigungen; Turbo akzeptiert künftige Protokolländerungen mit möglichen höheren Light-Client-Kosten. [1]

Zu prüfen sind Rune ID, Etching Transaction, genaue ord-Version, Premine, Divisibility, Mint Terms, Mint-Zahl, Edicts, Pointer, Cenotaph und aktuelle UTXO Allocations. Börsenticker oder einzelner Wallet-Saldo beweisen weder Supply noch Eigentum. [3]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Ordinals Inscriptions, OP_RETURN, UTXO, Bitcoin Script, Fee Rate, RGB Protocol. Auf diesen Eintrag verweisen außerdem BRC-20.

01Validieren Bitcoin Full Nodes Runes?

Nein. Sie prüfen Bitcoin-Transaktion und OP_RETURN-Daten, berechnen aber keine Rune-Salden und wenden Etching-, Mint- oder Edict-Regeln nicht an. Das übernimmt ord oder ein kompatibler Indexer.

02Ist eine Rune dasselbe wie eine Inscription oder ein BRC-20-Token?

Nein. Runes nutzt binäre Runestone-Nachrichten und UTXO Allocations. Inscriptions bindet Inhalt an einen Sat; BRC-20 ist ein separates Metaprotocol mit eigenen Indexregeln.

DOC · 001Ordinal Theory Handbook — Runes SpecificationSpezifikation DOC · 002ord — Runes reference implementationPrimärquelle DOC · 003Ordinal Theory Handbook — Wallet GuideDokumentation DOC · 004ord — READMEPrimärquelle
Überarbeitet: Quellenbasiert · Keine Anlageberatung