DA-04 · LESSON 07

Signing policy binding

KEY DEFINITIONS

Terms used in this lesson

Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
PSBT: Partially Signed Bitcoin Transaction: a format for passing an unsigned or partly signed transaction between constructors and signers.
Guardian: A Ducat policy-checking signer that can authorize or reject defined protocol transactions.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.

Request IDs, action types, transaction hashes, signing inputs, group keys, and policy digests prevent replay and cross-round substitution.

55 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
REQUESTSigning policy binding
The Signing policy binding 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, Signing policy binding. The Signing policy binding 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 request deposit-17, transaction hash 1122, input 1, group-nine, and policy 77cc. Required practice uses another replay set.

MECHANISM

Verify the caller or owner authorization and parse the expected action schema.

AFTER

A changed replay-storage epoch fails closed rather than treating the request as fresh. Required practice uses a separate server-executed vector.

Text equivalent: Starting from Use request deposit-17, transaction hash 1122, input 1, group-nine, and policy 77cc. Required practice uses another replay set. The mechanism begins when Verify the caller or owner authorization and parse the expected action schema. The resulting lesson is A changed replay-storage epoch fails closed rather than treating the request as fresh. Required practice uses a separate server-executed vector.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Authenticate the request

Verify the caller or owner authorization and parse the expected action schema.

Complete path: 1. Authenticate the request: Verify the caller or owner authorization and parse the expected action schema. 2. Bind every transaction: Recompute hashes and signing inputs from the supplied PSBTs rather than trusting summary strings. 3. Bind policy and key: Record the group public key, protocol profile, and policy digest under which approval was granted. 4. Reject replay or substitution: A reused request ID, changed action, changed transaction, wrong group key, or stale policy context stops signing.

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. A reused request ID, changed action, changed transaction, wrong group key, or stale policy context stops signing.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Authorization must bind the exact action, transaction data, inputs, group key, and current policy context.

Important distinction: A valid owner signature authorizes any Guardian transaction for that vault. Authorization must bind the exact action, transaction data, inputs, group key, and current policy context.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. A reused request ID, changed action, changed transaction, wrong group key, or stale policy context stops signing. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Authorization must bind the exact action, transaction data, inputs, group key, and current policy context.

Loading lesson visuals...

Learn the idea

Policy binding ties one authenticated owner and caller session to the exact request it covers. A request identifier distinguishes one attempt and helps reject replay. Action, transaction hash, input, group public key, and policy digest then fix the authorized signing context. Matching bytes from an unauthenticated caller are still rejected.

GUIDED EXPLANATION1/4 ideas inspected

Authenticate the request

Verify the caller or owner authorization and parse the expected action schema.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A valid owner signature authorizes any Guardian transaction for that vault.”

Authorization must bind the exact action, transaction data, inputs, group key, and current policy context.

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.