DA-02 · LESSON 05

Cenotaphs and invalid messages

KEY DEFINITIONS

Terms used in this lesson

Cenotaph: A malformed or intentionally unrecognized Runes message whose affected token balances are burned under the protocol’s rules.
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.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
LEB128: Little Endian Base 128: a variable-length integer encoding used for integers inside a Runes message.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
OP_RETURN: A Bitcoin Script operation commonly used to create an unspendable output carrying a small amount of data.

Malformed or deliberately unrecognized Rune messages can burn affected token balances, making parser compatibility and transaction construction safety essential.

35 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
REQUESTCenotaphs and invalid messages
The Cenotaphs and invalid messages 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, Cenotaphs and invalid messages. The Cenotaphs and invalid messages 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

The captured parser test decodes the integer payload [Body, 1, 1, 2, 2]. This is a decoded test payload, not the complete serialized Bitcoin transaction.

MECHANISM

The indexer deciphers OP_RETURN data under the supported Runes version and field rules.

AFTER

A malformed token message does not restore the spent input. Bitcoin can confirm the transaction while the compatible Runes parser classifies the message as a cenotaph and bur…

Text equivalent: Starting from The captured parser test decodes the integer payload [Body, 1, 1, 2, 2]. This is a decoded test payload, not the complete serialized Bitcoin transaction. The mechanism begins when The indexer deciphers OP_RETURN data under the supported Runes version and field rules. The resulting lesson is A malformed token message does not restore the spent input. Bitcoin can confirm the transaction while the compatible Runes parser classifies the message as a cenotaph and burns the affected Rune balance.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Parse the payload

The indexer deciphers OP_RETURN data under the supported Runes version and field rules.

Complete path: 1. Parse the payload: The indexer deciphers OP_RETURN data under the supported Runes version and field rules. 2. Detect invalid meaning: Malformed integers, invalid fields, unsupported semantics, or bad allocation references can classify the message as a cenotaph. 3. Apply the burn rule: Affected token inputs do not become normal successor allocations, so their UNIT value is lost at the token layer. 4. Keep Bitcoin status separate: The underlying Bitcoin transaction can remain consensus-valid and confirmed despite the token-layer burn.

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. The underlying Bitcoin transaction can remain consensus-valid and confirmed despite the token-layer burn.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin may confirm the spend. Runes interpretation can burn the token balance because the original output was still consumed.

Important distinction: If a runestone is invalid, Bitcoin rejects the entire transaction and the UNIT remains in its old output. Bitcoin may confirm the spend. Runes interpretation can burn the token balance because the original output was still consumed.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. The underlying Bitcoin transaction can remain consensus-valid and confirmed despite the token-layer burn. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin may confirm the spend. Runes interpretation can burn the token balance because the original output was still consumed.

Loading lesson visuals...

Learn the idea

A cenotaph is a runestone that the Runes rules classify as malformed or unrecognized. Its affected input balances are burned even though the Bitcoin transaction may confirm; a cenotaph's etched Rune is unmintable and a referenced mint is counted but creates no allocation. Unsigned LEB128 is the variable-length little-endian base-128 encoding used for runestone integers. Body is numeric tag 0 and marks the start of edicts. Each four-integer edict is Rune block delta, transaction delta, amount, and output selector. Flaw::EdictOutput is the named parser failure for a selector greater than the transaction output count. Truncated LEB128, malformed edict groups, unrecognized even tags, unknown flags, invalid Rune IDs, and out-of-range selectors are deterministic cenotaph causes under the pinned grammar.

GUIDED EXPLANATION1/4 ideas inspected

Parse the payload

The indexer deciphers OP_RETURN data under the supported Runes version and field rules.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“If a runestone is invalid, Bitcoin rejects the entire transaction and the UNIT remains in its old output.”

Bitcoin may confirm the spend. Runes interpretation can burn the token balance because the original output was still consumed.

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.