DA-01 · LESSON 03

Actors and responsibilities

KEY DEFINITIONS

Terms used in this lesson

Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
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.
LP: Liquidity provider: a participant supplying capital under a defined risk-and-revenue arrangement.
BTC: The common market ticker for bitcoin.
Nostr: A signed-event messaging protocol; Ducat can use relays to distribute oracle material without making those relays Bitcoin validators.
Collateral: An asset pledged against a debt; it can be used to cover the debt if agreed conditions are breached.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.

Vault owners, Guardians, validators, oracles, relays, liquidators, LPs, and operators have distinct powers, information, and failure modes.

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
REQUESTActors and responsibilities
The Actors and responsibilities 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, Actors and responsibilities. The Actors and responsibilities 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

A borrower wants to remove 0.1 BTC from the current vault while keeping the loan open.

MECHANISM

Clients propose transactions; Guardians independently decide whether a request meets policy before contributing authorization.

AFTER

Every actor has a narrow job. Transport is not truth, reconstruction is not settlement, and authorization is not confirmation.

Text equivalent: Starting from A borrower wants to remove 0.1 BTC from the current vault while keeping the loan open. The mechanism begins when Clients propose transactions; Guardians independently decide whether a request meets policy before contributing authorization. The resulting lesson is Every actor has a narrow job. Transport is not truth, reconstruction is not settlement, and authorization is not confirmation.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Separate construction from approval

Clients propose transactions; Guardians independently decide whether a request meets policy before contributing authorization.

Complete path: 1. Separate construction from approval: Clients propose transactions; Guardians independently decide whether a request meets policy before contributing authorization. 2. Separate reporting from transport: The oracle signs price-linked material; Nostr relays carry events but do not make the price true or the Bitcoin spend valid. 3. Separate settlement from interpretation: Bitcoin nodes enforce transaction and Script rules; validators add Ducat-specific interpretation of confirmed transactions. 4. Separate protocol actors from capital providers: An LP can supply capital and receive an agreed share of eligible revenue, but does not thereby become a Guardian, oracle, validator, or Bitcoin consensus participant. 5. Keep settlement independent: Bitcoin nodes do not ask any application actor to rewrite a spent output. They accept or reject the submitted transaction under Bitcoin rules.

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 nodes do not ask any application actor to rewrite a spent output. They accept or reject the submitted transaction under Bitcoin rules.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Only Bitcoin validation decides Bitcoin validity. Other actors construct, authorize, report, transport, interpret, or operate around that boundary.

Important distinction: Every Ducat actor helps Bitcoin decide whether a transaction is valid. Only Bitcoin validation decides Bitcoin validity. Other actors construct, authorize, report, transport, interpret, or operate around that boundary.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Bitcoin nodes do not ask any application actor to rewrite a spent output. They accept or reject the submitted transaction under Bitcoin rules. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. Only Bitcoin validation decides Bitcoin validity. Other actors construct, authorize, report, transport, interpret, or operate around that boundary.

Loading lesson visuals...

Learn the idea

An actor is a person or program with a defined power. The borrower requests a loan action and controls owner keys. The client constructs transactions. The Guardian is a signing service that checks Ducat policy. The oracle produces signed price material. A relay transports signed messages without deciding whether they are true. A validator reconstructs Ducat state from Bitcoin. A liquidator proposes a permitted closeout. A liquidity provider, or LP, supplies capital under separately defined commercial terms and can bear liquidity, timing, and loss risk. Bitcoin nodes enforce Bitcoin transaction and Script rules. An operator deploys and monitors software.

GUIDED EXPLANATION1/5 ideas inspected

Separate construction from approval

Clients propose transactions; Guardians independently decide whether a request meets policy before contributing authorization.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Every Ducat actor helps Bitcoin decide whether a transaction is valid.”

Only Bitcoin validation decides Bitcoin validity. Other actors construct, authorize, report, transport, interpret, or operate around that boundary.

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.