DA-07 · LESSON 04

Observability and watchtowers

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.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.
Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
Outpoint: A transaction ID plus output number that identifies one exact prior output.

Health checks cover chain tip, oracle freshness, ladder coverage, commitments, Guardian readiness, vault state, and transaction outcomes.

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
REQUESTObservability and watchtowers
The Observability and watchtowers 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, Observability and watchtowers. The Observability and watchtowers 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 Bitcoin node tip is block 802, the validator tip is 800, and the client is about to request a withdrawal from vault V. The displayed runbook threshold is any nonzero lag…

MECHANISM

Track node tip, validator tip, lag, reorgs, mempool status, and transaction confirmations.

AFTER

A lag alert prevents new work from using stale state. Recovery requires cause identification and agreement checks, not merely turning the alert green.

Text equivalent: Starting from The Bitcoin node tip is block 802, the validator tip is 800, and the client is about to request a withdrawal from vault V. The displayed runbook threshold is any nonzero lag for state-dependent signing. The mechanism begins when Track node tip, validator tip, lag, reorgs, mempool status, and transaction confirmations. The resulting lesson is A lag alert prevents new work from using stale state. Recovery requires cause identification and agreement checks, not merely turning the alert green.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Measure chain agreement

Track node tip, validator tip, lag, reorgs, mempool status, and transaction confirmations.

Complete path: 1. Measure chain agreement: Track node tip, validator tip, lag, reorgs, mempool status, and transaction confirmations. 2. Measure oracle coherence: Track report and snapshot freshness, ladder completion, commitment coverage, relay retrieval, and breach publication. 3. Measure signing readiness: Track Guardian quorum, request failures, nonce rounds, policy versions, attestations, and key expiry or rotation state. 4. Tie alerts to runbooks: Each alert needs severity, owner, first checks, safe retries, escalation, and a rule preventing unsafe automatic recovery.

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. Each alert needs severity, owner, first checks, safe retries, escalation, and a rule preventing unsafe automatic recovery.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. One endpoint covers one process. End-to-end safety needs cross-component freshness, agreement, key, transaction, and economic signals plus tested resp…

Important distinction: A green health endpoint proves the full Ducat protocol is safe. One endpoint covers one process. End-to-end safety needs cross-component freshness, agreement, key, transaction, and economic signals plus tested responses.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Each alert needs severity, owner, first checks, safe retries, escalation, and a rule preventing unsafe automatic recovery. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. One endpoint covers one process. End-to-end safety needs cross-component freshness, agreement, key, transaction, and economic signals plus tested responses.

Loading lesson visuals...

Learn the idea

Observability means collecting signals that reveal whether components agree and are timely. A watchtower is monitoring logic that checks chain state and time-sensitive protocol conditions so an operator can act. A runbook is a prewritten incident procedure naming the owner, checks, safe actions, and escalation. Monitoring detects and alerts; it does not create signatures, change Bitcoin history, or make an unsafe repair valid.

GUIDED EXPLANATION1/4 ideas inspected

Measure chain agreement

Track node tip, validator tip, lag, reorgs, mempool status, and transaction confirmations.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A green health endpoint proves the full Ducat protocol is safe.”

One endpoint covers one process. End-to-end safety needs cross-component freshness, agreement, key, transaction, and economic signals plus tested responses.

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.