DA-02 · LESSON 03

Runestones and edicts

KEY DEFINITIONS

Terms used in this lesson

Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
Runes: A Bitcoin metaprotocol that assigns fungible-token meaning to transaction outputs through off-chain interpretation.
UNIT: Ducat’s dollar-pegged stablecoin, the asset a borrower can create against bitcoin collateral.
OP_RETURN: A Bitcoin Script operation commonly used to create an unspendable output carrying a small amount of data.
OP_13: A Bitcoin Script operation that pushes the small integer 13 onto the stack; Runes uses it as part of a runestone marker.
LEB128: Little Endian Base 128: a variable-length integer encoding used for integers inside a Runes message.
Cenotaph: A malformed or intentionally unrecognized Runes message whose affected token balances are burned under the protocol’s rules.

Rune-compatible transaction data describes token allocations between outputs while Bitcoin consensus continues to validate only the underlying transaction.

55 min Difficulty 4/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · ducat vaultA Ducat action moves one Bitcoin-anchored vault state to a successorSelect any state to inspect its exact role.

RELATIONSHIP MAPInputs, rule, and outputs

01
PREDECESSORCurrent vault outpoint
The current Bitcoin output anchors collateral and identifies the state being spent.
02
REQUESTRunestones and edicts
The Runestones and edicts workflow proposes one exact action and successor state.
03
POLICYProfile, oracle, signatures
Applicable policy, price evidence, authorization, and transaction shape are checked.
04
BITCOIN SPENDScript-valid transaction
Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules.
05
SUCCESSORNew outpoint and state
Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

Rule shown: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state.

STAGE 1 OF 5PREDECESSOR: Current vault outpoint

The current Bitcoin output anchors collateral and identifies the state being spent.

Governing relationship: Bitcoin checks the spend; Ducat components independently reconstruct and validate the additional protocol state. Complete path: 1. PREDECESSOR, Current vault outpoint. The current Bitcoin output anchors collateral and identifies the state being spent. 2. REQUEST, Runestones and edicts. The Runestones and edicts workflow proposes one exact action and successor state. 3. POLICY, Profile, oracle, signatures. Applicable policy, price evidence, authorization, and transaction shape are checked. 4. BITCOIN SPEND, Script-valid transaction. Bitcoin miners and nodes can include only a transaction that satisfies Bitcoin rules. 5. SUCCESSOR, New outpoint and state. Ducat validators reconstruct debt, collateral, token, and account changes from the confirmed transaction.

1. State transitionWhat exists, what changes, and what results

BEFORE

This trace follows the captured AccountsIssueBuilder with three account outputs so the positions remain easy to inspect.

MECHANISM

The Bitcoin transaction consumes outputs that the Runes indexer associates with UNIT balances.

AFTER

Output order is part of the token meaning. The runestone does not place UNIT inside the satoshi value, and Bitcoin consensus does not calculate the external allocation.

Text equivalent: Starting from This trace follows the captured AccountsIssueBuilder with three account outputs so the positions remain easy to inspect. The mechanism begins when The Bitcoin transaction consumes outputs that the Runes indexer associates with UNIT balances. The resulting lesson is Output order is part of the token meaning. The runestone does not place UNIT inside the satoshi value, and Bitcoin consensus does not calculate the external allocation.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Spend token-bearing inputs

The Bitcoin transaction consumes outputs that the Runes indexer associates with UNIT balances.

Complete path: 1. Spend token-bearing inputs: The Bitcoin transaction consumes outputs that the Runes indexer associates with UNIT balances. 2. Encode allocation instructions: Each edict specifies which asset amount is assigned to which output index. 3. Separate direct and special selectors: A direct output selector with amount zero assigns all remaining units to that one output. In the captured account builder, the selector instead equals the transaction output count, which distributes across eligible non-OP_RETURN outputs. Amount zero with this special selector splits all remaining units across those eligible outputs. 4. Create ordinary Bitcoin outputs: The referenced outputs hold satoshis under Bitcoin scripts. Their UNIT amounts exist in the external Runes state reconstructed from the runestone. 5. Parse deterministically: Compatible indexers read the same bytes, output order, and rules to derive the same allocation.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The worked case executes the named inputs and checks in the displayed order. Compatible indexers read the same bytes, output order, and rules to derive the same allocation.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Satoshis and UNIT are separate asset views. The runestone assigns UNIT meaning to an output index.

Important distinction: The output's satoshi value contains its UNIT quantity. Satoshis and UNIT are separate asset views. The runestone assigns UNIT meaning to an output index.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Compatible indexers read the same bytes, output order, and rules to derive the same allocation. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Satoshis and UNIT are separate asset views. The runestone assigns UNIT meaning to an output index.

Loading lesson visuals...

Learn the idea

OP_RETURN is a Bitcoin output script used to carry data and is not a normal spendable payment output. A production runestone starts with OP_RETURN OP_13 (hex 6a5d), concatenates supported data pushes, and decodes their bytes as unsigned LEB128 integers. LEB128 is a variable-length little-endian base-128 integer encoding. Before Body tag 0, even tags carry recognized fields, odd unknown tags may be ignored, and flags select structures such as etching and terms. After Body, each four-integer edict uses Rune block delta, transaction delta, amount, and output selector. A direct selector names one ordinary output; amount zero sends all remaining units there. A selector equal to output count instead distributes across eligible non-OP_RETURN outputs. A pointer receives the remainder left after edicts. Bitcoin validates the transaction bytes; compatible indexers assign the external UNIT meaning.

GUIDED EXPLANATION1/5 ideas inspected

Spend token-bearing inputs

The Bitcoin transaction consumes outputs that the Runes indexer associates with UNIT balances.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“The output's satoshi value contains its UNIT quantity.”

Satoshis and UNIT are separate asset views. The runestone assigns UNIT meaning to an output index.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.