DA-03 · LESSON 09

Confirmations and lifecycle state

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.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.

Validator and client behavior must read environment-specific confirmation and state rules instead of teaching a timeless hard-coded number.

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
REQUESTConfirmations and lifecycle state
The Confirmations and lifecycle state 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, Confirmations and lifecycle state. The Confirmations and lifecycle state 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 a displayed two-confirmation readiness rule and blocks 300 and 301. Required practice uses another depth and block identity.

MECHANISM

A signed action may enter the mempool while its previous confirmed state remains vulnerable to conflicts or replacement policy.

AFTER

A Guardian signature remains authorization evidence and never substitutes for active-chain depth. Required practice uses a separate server-executed vector.

Text equivalent: Starting from Use a displayed two-confirmation readiness rule and blocks 300 and 301. Required practice uses another depth and block identity. The mechanism begins when A signed action may enter the mempool while its previous confirmed state remains vulnerable to conflicts or replacement policy. The resulting lesson is A Guardian signature remains authorization evidence and never substitutes for active-chain depth. Required practice uses a separate server-executed vector.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Broadcast as pending

A signed action may enter the mempool while its previous confirmed state remains vulnerable to conflicts or replacement policy.

Complete path: 1. Broadcast as pending: A signed action may enter the mempool while its previous confirmed state remains vulnerable to conflicts or replacement policy. 2. Observe first inclusion: The transaction gains one confirmation and its outputs enter the active chain's UTXO history. 3. Apply configured readiness: Clients and validators wait for the profile or environment's required depth before enabling dependent operations. 4. Handle reorgs: If the block disconnects, lifecycle state rolls back and dependent transactions may return to pending, conflict, or disappear.

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. If the block disconnects, lifecycle state rolls back and dependent transactions may return to pending, conflict, or disappear.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Confirmation policy is an environment and risk configuration. Bitcoin provides accumulated work, not a universal Ducat readiness number.

Important distinction: Ducat requires a permanent fixed number of confirmations for every action and network. Confirmation policy is an environment and risk configuration. Bitcoin provides accumulated work, not a universal Ducat readiness number.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. If the block disconnects, lifecycle state rolls back and dependent transactions may return to pending, conflict, or disappear. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Confirmation policy is an environment and risk configuration. Bitcoin provides accumulated work, not a universal Ducat readiness number.

Loading lesson visuals...

Learn the idea

A confirmation means a transaction is included in a block; further confirmations add blocks on top. Ducat clients and validators may label an action pending, confirmed, or spendable according to environment-specific rules, which must not be replaced by one universal number.

GUIDED EXPLANATION1/4 ideas inspected

Broadcast as pending

A signed action may enter the mempool while its previous confirmed state remains vulnerable to conflicts or replacement policy.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Ducat requires a permanent fixed number of confirmations for every action and network.”

Confirmation policy is an environment and risk configuration. Bitcoin provides accumulated work, not a universal Ducat readiness number.

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.