DA-07 · LESSON 08

Threat-model review

KEY DEFINITIONS

Terms used in this lesson

Oracle: A system that reports outside information, such as a market price, for use by a protocol.
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.
Spread: The gap between executable buy and sell prices in a market.
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.
BTC: The common market ticker for bitcoin.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
Preimage: The original secret data whose hash equals a previously committed value.
Control block: Proof data showing that a revealed script was committed inside a Taproot output.
USD: United States dollar, the reference currency in a BTC/USD price.
Collateral: An asset pledged against a debt; it can be used to cover the debt if agreed conditions are breached.

Oracle compromise, Guardian collusion, liveness loss, validator divergence, signing-policy bugs, fee spikes, reorgs, and economic attacks each need explicit mitigations.

65 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
REQUESTThreat-model review
The Threat-model review 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, Threat-model review. The Threat-model review 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

Vault V holds 1 BTC and owes 40,000 UNIT. The true BTC price is $100,000, but an attacker controls oracle key O and enough Guardian shares to meet the signing threshold. The…

MECHANISM

Specify vault bitcoin, Guardian shares, oracle key, UNIT integrity, validator state, reserve capacity, or user availability.

AFTER

Cryptographic validity can coexist with false outside data and dishonest policy authorization. Bitcoin enforces the committed hash and signature, not the truth of the reporte…

Text equivalent: Starting from Vault V holds 1 BTC and owes 40,000 UNIT. The true BTC price is $100,000, but an attacker controls oracle key O and enough Guardian shares to meet the signing threshold. The attacker publishes a false $40,000 breach and… The mechanism begins when Specify vault bitcoin, Guardian shares, oracle key, UNIT integrity, validator state, reserve capacity, or user availability. The resulting lesson is Cryptographic validity can coexist with false outside data and dishonest policy authorization. Bitcoin enforces the committed hash and signature, not the truth of the reported market price.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Choose one protected asset

Specify vault bitcoin, Guardian shares, oracle key, UNIT integrity, validator state, reserve capacity, or user availability.

Complete path: 1. Choose one protected asset: Specify vault bitcoin, Guardian shares, oracle key, UNIT integrity, validator state, reserve capacity, or user availability. 2. Construct the attack path: Order the preconditions and component boundaries an attacker must cross rather than listing a vague risk. 3. Map preventive and detective controls: Tie Script, threshold, signature, parser, policy, monitoring, rate, and operational controls to exact attack steps. 4. Test residual loss and recovery: State what the controls do not prevent, how operators detect failure, and whether recovery is possible without missing authority.

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. State what the controls do not prevent, how operators detect failure, and whether recovery is possible without missing authority.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Detection, prevention, containment, and recovery are different properties and may occur after different damage.

Important distinction: A control that detects an attack prevents the loss. Detection, prevention, containment, and recovery are different properties and may occur after different damage.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. State what the controls do not prevent, how operators detect failure, and whether recovery is possible without missing authority. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Detection, prevention, containment, and recovery are different properties and may occur after different damage.

Loading lesson visuals...

Learn the idea

A threat model is an ordered explanation of how an attacker could harm a protected asset. It names the asset, attacker capability, required preconditions, trust assumptions, preventive controls, detectable signals, residual loss, and recovery. Prevention stops a step, detection reveals it, containment limits spread, and recovery restores a supported state. Those are separate claims.

GUIDED EXPLANATION1/4 ideas inspected

Choose one protected asset

Specify vault bitcoin, Guardian shares, oracle key, UNIT integrity, validator state, reserve capacity, or user availability.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A control that detects an attack prevents the loss.”

Detection, prevention, containment, and recovery are different properties and may occur after different damage.

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.