DA-05 · LESSON 07

Liquidation Taproot leaf

KEY DEFINITIONS

Terms used in this lesson

Taproot: A Bitcoin output and spending design that can combine a public-key path with privately committed alternative scripts.
Preimage: The original secret data whose hash equals a previously committed value.
Hashlock: A spending condition that requires revealing data matching a committed hash.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.
Schnorr signature: Bitcoin’s Taproot signature scheme, whose algebra supports compact verification and advanced multi-party signing.
CHECKSIG: The Bitcoin Script operation that checks whether a signature is valid for the required public key and transaction message.
Oracle: A system that reports outside information, such as a market price, for use by a protocol.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
Control block: Proof data showing that a revealed script was committed inside a Taproot output.
P2TR: Pay to Taproot, the Bitcoin output type introduced with Taproot.
Hash160: SHA-256 followed by RIPEMD-160, producing the 20-byte hash used by several Bitcoin spending conditions.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
Taptree: The Merkle tree of alternative scripts committed inside a Taproot output.
Tapscript: The version of Bitcoin Script used by a Taproot script-path spend.
OP_HASH160: A Bitcoin Script operation that replaces the top stack item with its Hash160 digest.
OP_EQUALVERIFY: A Bitcoin Script operation that compares two values and immediately fails if they differ.
BTC: The common market ticker for bitcoin.

The revealed preimage satisfies the hashlock and a Guardian Schnorr signature satisfies CHECKSIG, making the oracle outcome consumable by Bitcoin Script.

55 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
REQUESTLiquidation Taproot leaf
The Liquidation Taproot leaf 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, Liquidation Taproot leaf. The Liquidation Taproot leaf 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

The final script-path witness is [guardian signature, oracle preimage, liquidation script, control block]. The script bytes are OP_HASH160 <20-byte liquidation hash> OP_EQUAL…

MECHANISM

Vault construction includes the hashlock and Guardian public key in the taptree before any breach occurs.

AFTER

Bitcoin verifies a committed leaf, a matching preimage, and a valid Guardian signature over the spending transaction. It does not verify the outside process that decided to r…

Text equivalent: Starting from The final script-path witness is [guardian signature, oracle preimage, liquidation script, control block]. The script bytes are OP_HASH160 <20-byte liquidation hash> OP_EQUALVERIFY <32-byte Guardian x-only public key> O… The mechanism begins when Vault construction includes the hashlock and Guardian public key in the taptree before any breach occurs. The resulting lesson is Bitcoin verifies a committed leaf, a matching preimage, and a valid Guardian signature over the spending transaction. It does not verify the outside process that decided to reveal the preimage.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Commit the leaf

Vault construction includes the hashlock and Guardian public key in the taptree before any breach occurs.

Complete path: 1. Commit the leaf: Vault construction includes the hashlock and Guardian public key in the taptree before any breach occurs. 2. Build the witness: A liquidation spend provides the released preimage, Guardian signature, revealed Tapscript, and control block. 3. Prove tree membership: The control block lets every node recompute the Taproot output key and verify this leaf was committed. 4. Execute the predicates: Bitcoin checks Hash160(preimage) and CHECKSIG against the transaction message; both conditions must succeed.

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. Bitcoin checks Hash160(preimage) and CHECKSIG against the transaction message; both conditions must succeed.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin proves only that the preimage matches the committed hash. A constructed transaction and valid Guardian signature are still required.

Important distinction: A valid preimage proves the BTC price and forces Bitcoin to liquidate. Bitcoin proves only that the preimage matches the committed hash. A constructed transaction and valid Guardian signature are still required.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Bitcoin checks Hash160(preimage) and CHECKSIG against the transaction message; both conditions must succeed. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Bitcoin proves only that the preimage matches the committed hash. A constructed transaction and valid Guardian signature are still required.

Loading lesson visuals...

Learn the idea

A Taproot leaf is one hidden spending script committed inside a P2TR output. Ducat's liquidation leaf requires a threshold preimage whose Hash160 matches the committed value and a valid Guardian Schnorr signature.

GUIDED EXPLANATION1/4 ideas inspected

Commit the leaf

Vault construction includes the hashlock and Guardian public key in the taptree before any breach occurs.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A valid preimage proves the BTC price and forces Bitcoin to liquidate.”

Bitcoin proves only that the preimage matches the committed hash. A constructed transaction and valid Guardian signature are still required.

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.