DA-02 · LESSON 02

Rune identity and issuance

KEY DEFINITIONS

Terms used in this lesson

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.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.

Rune identifiers and issuance rules establish which on-chain token is UNIT and how compatible indexers recognize its supply events.

45 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
REQUESTRune identity and issuance
The Rune identity and issuance 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, Rune identity and issuance. The Rune identity and issuance 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

Use illustrative IDs 900000:3 and 900000:4. They differ from required practice and are not claimed to be the active UNIT ID.

MECHANISM

The etching transaction carries a runestone that creates the Rune under indexer rules. Its confirmed block height and position in that block give the token a Rune ID that lat…

AFTER

Asset identity comes from the exact Rune ID in the active profile. A ticker is useful for display but is not sufficient for validation.

Text equivalent: Starting from Use illustrative IDs 900000:3 and 900000:4. They differ from required practice and are not claimed to be the active UNIT ID. The mechanism begins when The etching transaction carries a runestone that creates the Rune under indexer rules. Its confirmed block height and position in that block give the token a Rune ID that later edicts can reference. The resulting lesson is Asset identity comes from the exact Rune ID in the active profile. A ticker is useful for display but is not sufficient for validation.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Establish the asset identity

The etching transaction carries a runestone that creates the Rune under indexer rules. Its confirmed block height and position in that block give the token a Rune ID that later edicts can reference.

Complete path: 1. Establish the asset identity: The etching transaction carries a runestone that creates the Rune under indexer rules. Its confirmed block height and position in that block give the token a Rune ID that later edicts can reference. 2. Bind identity into Ducat: The active protocol profile and transaction builders carry the UNIT Rune ID when constructing allocations. 3. Issue from controlled capacity: Account issue and vault issue builders consume protocol-controlled UNIT inputs and create explicitly allocated outputs. 4. Verify exact identity: Validators reject or quarantine a transaction whose runestone refers to the wrong Rune ID even if the Bitcoin transaction itself is valid. 5. Pin production semantics: Conformance vectors must execute the selected ord revision's activation, etching, inclusive start, exclusive end, mint cap, optional Turbo opt-in, and invalid-message effects. A versioned profile may require one Turbo choice, but ord does not require every valid etching to opt in. A teaching fixture must disclose omitted name-unlock and commitment-aging rules rather than imply full deployment coverage.

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. Conformance vectors must execute the selected ord revision's activation, etching, inclusive start, exclusive end, mint cap, optional Turbo opt-in, and invalid-message effects. A vers…

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Indexers identify a Rune by its protocol identity. Names and tickers can be copied or presented incorrectly.

Important distinction: The ticker or displayed name proves a token is UNIT. Indexers identify a Rune by its protocol identity. Names and tickers can be copied or presented incorrectly.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Conformance vectors must execute the selected ord revision's activation, etching, inclusive start, exclusive end, mint cap, optional Turbo opt-in, and invalid-message effects. A versioned profile may require one Turbo choice, but ord does not require every valid etching to opt in. A teaching fixture must disclose omitted name-unlock and commitment-aging rules rather than imply full deployment coverage. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Indexers identify a Rune by its protocol identity. Names and tickers can be copied or presented incorrectly.

Loading lesson visuals...

Learn the idea

A Rune is created in an etching transaction. Under the production Runes specification implemented by ord, runestones begin to have Runes meaning at Bitcoin block 840,000 on mainnet; pre-activation messages are ignored. An etching runestone can define a Rune, premine, and mint terms. A later mint names that Rune ID and is accepted only within its terms and cap. Mint start heights and offsets are inclusive; mint end heights and offsets are exclusive, so a mint at the end boundary is already closed. Its Rune ID is the etching's block height and transaction index, written block:transaction. A ticker is only a display name. Ducat components must pin the exact Rune ID, network, activation boundary, and ord parser revision rather than trusting the word UNIT on screen.

GUIDED EXPLANATION1/5 ideas inspected

Establish the asset identity

The etching transaction carries a runestone that creates the Rune under indexer rules. Its confirmed block height and position in that block give the token a Rune ID that later edicts can reference.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“The ticker or displayed name proves a token is UNIT.”

Indexers identify a Rune by its protocol identity. Names and tickers can be copied or presented incorrectly.

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.