DA-07 · LESSON 07

Governance powers

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.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
Vault: A set of Bitcoin outputs and spending rules that holds collateral and represents the current loan state.

Experts enumerate who can change configurations, rotate keys, deploy oracle workflows, update clients, pause operations, or migrate funds.

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
REQUESTGovernance powers
The Governance powers 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, Governance powers. The Governance powers 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

Profile seven names the old oracle key. A proposal introduces a new oracle key. The supplied evidence identifies source commits but does not name the approver, deployment ope…

MECHANISM

Include repositories, build pipelines, profiles, Guardian and oracle keys, workflow IDs, endpoints, monitoring, and user-facing defaults.

AFTER

Technical change surfaces can be identified from code. Human ownership, approval thresholds, emergency authority, and a live rotation procedure remain unknown until dated gov…

Text equivalent: Starting from Profile seven names the old oracle key. A proposal introduces a new oracle key. The supplied evidence identifies source commits but does not name the approver, deployment operator, secret custodian, profile signer, clie… The mechanism begins when Include repositories, build pipelines, profiles, Guardian and oracle keys, workflow IDs, endpoints, monitoring, and user-facing defaults. The resulting lesson is Technical change surfaces can be identified from code. Human ownership, approval thresholds, emergency authority, and a live rotation procedure remain unknown until dated governance and deployment evidence names them.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

List change surfaces

Include repositories, build pipelines, profiles, Guardian and oracle keys, workflow IDs, endpoints, monitoring, and user-facing defaults.

Complete path: 1. List change surfaces: Include repositories, build pipelines, profiles, Guardian and oracle keys, workflow IDs, endpoints, monitoring, and user-facing defaults. 2. List approvers and executors: The person approving a change may differ from the operator able to deploy or sign it. 3. List on-chain limits: Existing scripts and key commitments constrain some governance actions, while client defaults and external services may remain centrally changeable. 4. List emergency and recovery powers: Document pauses, rollback limits, key rotation, migration, incident disclosure, and what happens if the authority is unavailable or malicious.

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. Document pauses, rollback limits, key rotation, migration, incident disclosure, and what happens if the authority is unavailable or malicious.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It may still control required signers, oracle availability, defaults, deployments, migrations, and access to protocol services.

Important distinction: If governance cannot violate Bitcoin consensus, it has no custody or censorship power. It may still control required signers, oracle availability, defaults, deployments, migrations, and access to protocol services.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Document pauses, rollback limits, key rotation, migration, incident disclosure, and what happens if the authority is unavailable or malicious. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It may still control required signers, oracle availability, defaults, deployments, migrations, and access to protocol services.

Loading lesson visuals...

Learn the idea

Governance power is the practical ability to approve or execute a change to code, configuration, keys, deployments, or funds. An approver authorizes a change; an executor has the credentials or signing power to perform it. An on-chain limit is a Bitcoin commitment that neither role can bypass. Ducat analysis must map these powers without assuming repository maintainers, service operators, and key holders are the same people.

GUIDED EXPLANATION1/4 ideas inspected

List change surfaces

Include repositories, build pipelines, profiles, Guardian and oracle keys, workflow IDs, endpoints, monitoring, and user-facing defaults.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“If governance cannot violate Bitcoin consensus, it has no custody or censorship power.”

It may still control required signers, oracle availability, defaults, deployments, migrations, and access to protocol services.

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.