DA-02 · LESSON 09

Compatibility and failure boundaries

KEY DEFINITIONS

Terms used in this lesson

UNIT: Ducat’s dollar-pegged stablecoin, the asset a borrower can create against bitcoin collateral.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
Runes: A Bitcoin metaprotocol that assigns fungible-token meaning to transaction outputs through off-chain interpretation.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
Cenotaph: A malformed or intentionally unrecognized Runes message whose affected token balances are burned under the protocol’s rules.
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.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.

Wallet construction, indexer rules, network configuration, confirmation handling, and version compatibility determine whether every participant reconstructs the same UNIT state.

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
REQUESTCompatibility and failure boundaries
The Compatibility and failure boundaries 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, Compatibility and failure boundaries. The Compatibility and failure boundaries 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

Manifests one and two are illustrative component manifests. A manifest records the exact parser, action, profile, and network versions a component uses.

MECHANISM

Wallet, validator, and protocol tests must agree on runestone and cenotaph behavior.

AFTER

Matching txids do not guarantee matching metaprotocol state. Release only when every component passes the same versioned conformance vectors and agrees on reorg behavior.

Text equivalent: Starting from Manifests one and two are illustrative component manifests. A manifest records the exact parser, action, profile, and network versions a component uses. The mechanism begins when Wallet, validator, and protocol tests must agree on runestone and cenotaph behavior. The resulting lesson is Matching txids do not guarantee matching metaprotocol state. Release only when every component passes the same versioned conformance vectors and agrees on reorg behavior.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Pin parser versions

Wallet, validator, and protocol tests must agree on runestone and cenotaph behavior.

Complete path: 1. Pin parser versions: Wallet, validator, and protocol tests must agree on runestone and cenotaph behavior. 2. Pin transaction versions: Sequence metadata and action parsers identify the expected layout and supported transition. 3. Pin network identities: Rune ID, protocol anchor, keys, and chain must come from one compatible profile. 4. Test disagreement: Conformance vectors should cover valid allocations, malformed messages, issue and burn pairs, and reorgs across implementations.

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 should cover valid allocations, malformed messages, issue and burn pairs, and reorgs across implementations.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Components can agree on transaction bytes and still interpret external Runes or Ducat rules differently.

Important distinction: Agreement on the Bitcoin txid guarantees agreement on UNIT state. Components can agree on transaction bytes and still interpret external Runes or Ducat rules differently.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Conformance vectors should cover valid allocations, malformed messages, issue and burn pairs, and reorgs across implementations. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Components can agree on transaction bytes and still interpret external Runes or Ducat rules differently.

Loading lesson visuals...

Learn the idea

Compatibility means every component derives the same result from the same bytes and chain history. Metaprotocol state is application state, such as UNIT allocations and vault records, reconstructed by external Ducat and Runes rules from Bitcoin transactions rather than stored as native Bitcoin balances. A parser turns runestone bytes into Rune meaning. The production mainnet Runes activation boundary is block 840,000 inclusive under the ord specification; a deployment must also pin its exact ord revision. An action version selects the expected Ducat transaction layout. A profile supplies network, keys, and asset identity. A protocol anchor is a profile-identified on-chain reference whose committed content names the configuration and signer identities components accept. A confirmation policy says how many blocks must cover a transaction before derived state is treated as settled. A version boundary is a declared activation height or full reindex point at which every component changes rules together. A conformance vector is one shared input plus its expected parsed output.

GUIDED EXPLANATION1/4 ideas inspected

Pin parser versions

Wallet, validator, and protocol tests must agree on runestone and cenotaph behavior.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Agreement on the Bitcoin txid guarantees agreement on UNIT state.”

Components can agree on transaction bytes and still interpret external Runes or Ducat rules differently.

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.