DA-01 · LESSON 02

The end-to-end system lifecycle

KEY DEFINITIONS

Terms used in this lesson

Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.
Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
Oracle: A system that reports outside information, such as a market price, for use by a protocol.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
UNIT: Ducat’s dollar-pegged stablecoin, the asset a borrower can create against bitcoin collateral.
Outpoint: A transaction ID plus output number that identifies one exact prior output.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
BTC: The common market ticker for bitcoin.

A user action moves through client construction, Bitcoin transactions, Guardian authorization, confirmation, validator reconstruction, and, when required, an oracle-triggered liquidation path.

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
REQUESTThe end-to-end system lifecycle
The The end-to-end system lifecycle 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, The end-to-end system lifecycle. The The end-to-end system lifecycle 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 illustrative trace follows named objects so every change is visible. It uses a different vector from required practice and does not claim current protocol limits.

MECHANISM

The client begins with confirmed outpoints. An outpoint is a transaction ID plus an output number. It reads the current vault, current issuance account, active profile, and o…

AFTER

A request is not complete when it is signed. Its inputs must still be unspent, its transactions must confirm in dependency order, and the confirmed bytes must reconstruct to…

Text equivalent: Starting from This illustrative trace follows named objects so every change is visible. It uses a different vector from required practice and does not claim current protocol limits. The mechanism begins when The client begins with confirmed outpoints. An outpoint is a transaction ID plus an output number. It reads the current vault, current issuance account, active profile, and oracle snapshot before calculating anything. The resulting lesson is A request is not complete when it is signed. Its inputs must still be unspent, its transactions must confirm in dependency order, and the confirmed bytes must reconstruct to the expected successors.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Read exact current outputs

The client begins with confirmed outpoints. An outpoint is a transaction ID plus an output number. It reads the current vault, current issuance account, active profile, and oracle snapshot before calculating anything.

Complete path: 1. Read exact current outputs: The client begins with confirmed outpoints. An outpoint is a transaction ID plus an output number. It reads the current vault, current issuance account, active profile, and oracle snapshot before calculating anything. 2. Build the parent when needed: A borrow first spends the current account in an issue transaction. That transaction creates a UNIT allocation and a successor account so that the old account cannot be reused. 3. Build the vault successor: A dependent child transaction spends the current vault and creates the successor vault. The successor contains the same loan with the requested debt change and its required Bitcoin spending conditions. 4. Authorize and confirm: The owner signs wallet-controlled inputs. The Guardian signs protocol-controlled inputs only after checking policy. Bitcoin nodes validate inputs, values, and scripts. A miner can then include the issue parent before the dependent vault child. 5. Reconstruct the result: After the configured confirmations, a validator parses the issue and child transactions. It marks the old vault and account spent, exposes their successors, and assigns the issued UNIT to its new output.

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. After the configured confirmations, a validator parses the issue and child transactions. It marks the old vault and account spent, exposes their successors, and assigns the issued UN…

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. A signature only authorizes the transaction. Broadcast, Bitcoin validation, confirmation, and validator reconstruction still have to occur.

Important distinction: A Guardian signature completes a Ducat action. A signature only authorizes the transaction. Broadcast, Bitcoin validation, confirmation, and validator reconstruction still have to occur.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. After the configured confirmations, a validator parses the issue and child transactions. It marks the old vault and account spent, exposes their successors, and assigns the issued UNIT to its new output. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. A signature only authorizes the transaction. Broadcast, Bitcoin validation, confirmation, and validator reconstruction still have to occur.

Loading lesson visuals...

Learn the idea

A lifecycle is the ordered path from a request to a confirmed result. A vault is a Bitcoin output that represents one loan. An account is a Guardian-controlled Bitcoin output that can release UNIT for borrowing. A protocol profile supplies the network, keys, asset identity, and policy values. An oracle snapshot supplies signed price information. A client reads these current objects, builds transactions, collects signatures, broadcasts them, and later reads the result reconstructed from Bitcoin.

GUIDED EXPLANATION1/5 ideas inspected

Read exact current outputs

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A Guardian signature completes a Ducat action.”

A signature only authorizes the transaction. Broadcast, Bitcoin validation, confirmation, and validator reconstruction still have to occur.

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.