DA-01 · LESSON 09

Current versus target architecture

KEY DEFINITIONS

Terms used in this lesson

Proof-of-work target: The maximum header-hash value accepted for a block; lowering it makes valid hashes harder to find.
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.

Repository code, deployed environments, security roadmaps, and public descriptions can differ; every claim must carry a date and status.

35 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
REQUESTCurrent versus target architecture
The Current versus target architecture 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, Current versus target architecture. The Current versus target architecture 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

Status words answer different questions. Code existence, integration, testing, and live deployment must be evidenced separately.

MECHANISM

Record repository, commit, file or test, capture date, network, and configuration for every technical statement.

AFTER

Never promote a repository artifact into a live deployment claim. Preserve dates and contradictions so a later update changes only the status that new evidence supports.

Text equivalent: Starting from Status words answer different questions. Code existence, integration, testing, and live deployment must be evidenced separately. The mechanism begins when Record repository, commit, file or test, capture date, network, and configuration for every technical statement. The resulting lesson is Never promote a repository artifact into a live deployment claim. Preserve dates and contradictions so a later update changes only the status that new evidence supports.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Pin the claim

Record repository, commit, file or test, capture date, network, and configuration for every technical statement.

Complete path: 1. Pin the claim: Record repository, commit, file or test, capture date, network, and configuration for every technical statement. 2. Rank the evidence: Executable code and tests establish different claims from repository documentation, internal sessions, deployment observations, or public marketing. 3. Check conflicts: When code, documentation, and public descriptions disagree, keep the claim quarantined until the authoritative behavior and date are resolved. 4. State what remains unknown: Do not translate a branch name, testnet label, or roadmap into production readiness, decentralization, audit completion, or real-funds safety.

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. Do not translate a branch name, testnet label, or roadmap into production readiness, decentralization, audit completion, or real-funds safety.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. They answer different questions. A feature can be implemented and tested while absent from every running environment.

Important distinction: Merged, tested, and deployed are interchangeable status labels. They answer different questions. A feature can be implemented and tested while absent from every running environment.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Do not translate a branch name, testnet label, or roadmap into production readiness, decentralization, audit completion, or real-funds safety. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. They answer different questions. A feature can be implemented and tested while absent from every running environment.

Loading lesson visuals...

Learn the idea

Implemented means code exists at a named revision. Tested means a named test exercised a stated behavior at that revision. Integrated means components work together in a tested flow. Deployed means a dated environment is running that artifact. Proposed means the design is intended but not yet established by executable evidence. Deprecated means maintainers have marked a behavior or version for retirement or non-use. No concrete deprecated Ducat behavior is established by the captured evidence, so the label must remain unused until such evidence exists. Disputed means available sources make incompatible claims that have not been resolved by stronger dated evidence.

GUIDED EXPLANATION1/4 ideas inspected

Pin the claim

Record repository, commit, file or test, capture date, network, and configuration for every technical statement.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Merged, tested, and deployed are interchangeable status labels.”

They answer different questions. A feature can be implemented and tested while absent from every running environment.

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.