DA-07 · LESSON 01

Validator reconstruction

KEY DEFINITIONS

Terms used in this lesson

Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.
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.
API: Application programming interface: a defined way for one program to request data or actions from another.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
Outpoint: A transaction ID plus output number that identifies one exact prior output.

Validators scan Bitcoin blocks, maintain UTXOs and protocol objects, validate UNIT transfers against vault differentials, and serve query APIs.

35 min Difficulty 5/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
REQUESTValidator reconstruction
The Validator reconstruction 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, Validator reconstruction. The Validator reconstruction 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

Before block 500, account A is unspent with 5,000 UNIT of issuance capacity and vault V is unspent with 40,000 UNIT of debt. Block 500 contains issue parent P and dependent b…

MECHANISM

Read blocks in order and identify protocol transactions, inputs, outputs, action tags, and runestones.

AFTER

The validator's database follows selected Bitcoin history. It can be rebuilt because each successor comes from consumed outpoints and confirmed transaction bytes, not from an…

Text equivalent: Starting from Before block 500, account A is unspent with 5,000 UNIT of issuance capacity and vault V is unspent with 40,000 UNIT of debt. Block 500 contains issue parent P and dependent borrow child C. The mechanism begins when Read blocks in order and identify protocol transactions, inputs, outputs, action tags, and runestones. The resulting lesson is The validator's database follows selected Bitcoin history. It can be rebuilt because each successor comes from consumed outpoints and confirmed transaction bytes, not from an untracked balance edit.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Follow the active chain

Read blocks in order and identify protocol transactions, inputs, outputs, action tags, and runestones.

Complete path: 1. Follow the active chain: Read blocks in order and identify protocol transactions, inputs, outputs, action tags, and runestones. 2. Resolve prior state: Look up consumed vault, account, reserve, and token objects needed to validate the transition. 3. Apply Ducat rules: Check action shape, UNIT allocations, vault differentials, signatures or commitments represented in the protocol view, and successor relationships. 4. Serve and reverse state: Expose confirmed objects to clients and undo derived effects if Bitcoin disconnects a block.

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. Expose confirmed objects to clients and undo derived effects if Bitcoin disconnects a block.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin outputs are authoritative for spends. The validator reconstructs additional Ducat meaning and can be independently compared or rebuilt.

Important distinction: The validator database is the authoritative owner of Ducat funds. Bitcoin outputs are authoritative for spends. The validator reconstructs additional Ducat meaning and can be independently compared or rebuilt.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Expose confirmed objects to clients and undo derived effects if Bitcoin disconnects a block. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin outputs are authoritative for spends. The validator reconstructs additional Ducat meaning and can be independently compared or rebuilt.

Loading lesson visuals...

Learn the idea

A Ducat validator is an indexer and rule engine. An indexer reads Bitcoin blocks in selected-chain order and derives application state from their transactions. Derived state means the current vaults, accounts, reserves, and UNIT allocations calculated from Bitcoin history. A reorganization, or reorg, replaces previously selected blocks, so the validator must undo their derived effects before applying the replacement branch. It does not create Bitcoin consensus or hold the Guardian signing key.

GUIDED EXPLANATION1/4 ideas inspected

Follow the active chain

Read blocks in order and identify protocol transactions, inputs, outputs, action tags, and runestones.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“The validator database is the authoritative owner of Ducat funds.”

Bitcoin outputs are authoritative for spends. The validator reconstructs additional Ducat meaning and can be independently compared or rebuilt.

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.