DA-01 · LESSON 05

Accounts, reserves, and UNIT debt

KEY DEFINITIONS

Terms used in this lesson

UNIT: Ducat’s dollar-pegged stablecoin, the asset a borrower can create against bitcoin collateral.
UTXO: Unspent transaction output: one discrete chunk of bitcoin that can be used as a transaction input.
Validator: Software or a participant that independently checks state transitions under a system's rules. The exact role depends on the protocol being discussed.
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.
Runestone: Transaction data interpreted by the Runes protocol to describe token creation or allocation.
OP_RETURN: A Bitcoin Script operation commonly used to create an unspendable output carrying a small amount of data.
Runes: A Bitcoin metaprotocol that assigns fungible-token meaning to transaction outputs through off-chain interpretation.
Identifier: Identifier: a value used to distinguish one request, object, or participant from another.
SDK: Software development kit: reusable code and tools for building applications against a system.
BTC: The common market ticker for bitcoin.

Issuance and reserve accounts are UTXO-based protocol objects whose availability and transitions are tracked by validators and coordinated by Guardians.

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
REQUESTAccounts, reserves, and UNIT debt
The Accounts, reserves, and UNIT debt 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, Accounts, reserves, and UNIT debt. The Accounts, reserves, and UNIT debt 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 an illustrative starting reserve of 1,500,000 UNIT and five accounts of 100,000 UNIT each. This differs from the required ten-account practice vector and is not a live re…

MECHANISM

The account issue builder spends the reserve UTXO, creates a successor reserve, and creates account outputs.

AFTER

The five accounts receive 500,000 UNIT in total and the successor reserve receives the remaining 1,000,000 UNIT. Starting reserve 1,500,000 equals account allocations 500,000…

Text equivalent: Starting from Use an illustrative starting reserve of 1,500,000 UNIT and five accounts of 100,000 UNIT each. This differs from the required ten-account practice vector and is not a live reserve claim. The mechanism begins when The account issue builder spends the reserve UTXO, creates a successor reserve, and creates account outputs. The resulting lesson is The five accounts receive 500,000 UNIT in total and the successor reserve receives the remaining 1,000,000 UNIT. Starting reserve 1,500,000 equals account allocations 500,000 plus successor reserve 1,000,000.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 4

Consume reserve capacity

The account issue builder spends the reserve UTXO, creates a successor reserve, and creates account outputs.

Complete path: 1. Consume reserve capacity: The account issue builder spends the reserve UTXO, creates a successor reserve, and creates account outputs. 2. Allocate UNIT with a runestone: The captured builder puts the successor reserve at output 0, account outputs at positions 1 onward, and a runestone in the last OP_RETURN output. Its edict distributes the configured issue amount and its pointer sends unallocated remainder to output 0. 3. Enforce builder limits: The captured builder requires a nonzero issue amount and between 1 and 2,000 account outputs. It parses the finished transaction back into the expected account-issue shape before use. 4. Reconcile debt and token change: Borrowing links UNIT issuance to increased vault debt; repayment links a UNIT burn to decreased debt.

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. Borrowing links UNIT issuance to increased vault debt; repayment links a UNIT burn to decreased debt.

CHANGED CONDITION

A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It is protocol issuance capacity controlled through Guardian rules. Borrower-held UNIT outputs and vault debt are related but different objects.

Important distinction: An account UTXO is the borrower's UNIT wallet balance. It is protocol issuance capacity controlled through Guardian rules. Borrower-held UNIT outputs and vault debt are related but different objects.

Text equivalent: The accepted path is enforced by The worked case executes the named inputs and checks in the displayed order. Borrowing links UNIT issuance to increased vault debt; repayment links a UNIT burn to decreased debt. If the required condition changes, A missing, malformed, stale, unauthorized, or inconsistent required input stops at its first named boundary. It is protocol issuance capacity controlled through Guardian rules. Borrower-held UNIT outputs and vault debt are related but different objects.

Loading lesson visuals...

Learn the idea

A UTXO is a Bitcoin transaction output that has not yet been spent. The UNIT reserve is a UTXO to which the indexer assigns the displayed reserve balance; this is distinct from the transient unallocated pool used while executing one runestone. An issuance account is a Guardian-controlled UTXO carrying a smaller allocation that can be used in a later borrow. A runestone is OP_RETURN data that tells a compatible Runes indexer how UNIT moves between output numbers. An edict is its Rune-ID, amount, and output-selector allocation instruction. A pointer is the output selector that receives the remainder left after edicts. RawAccountsIssue is the captured SDK parser's expected account-issue transaction shape. Vault debt is the amount owed by one vault. These are separate objects that must agree during issuance and repayment.

GUIDED EXPLANATION1/4 ideas inspected

Consume reserve capacity

The account issue builder spends the reserve UTXO, creates a successor reserve, and creates account outputs.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“An account UTXO is the borrower's UNIT wallet balance.”

It is protocol issuance capacity controlled through Guardian rules. Borrower-held UNIT outputs and vault debt are related but different objects.

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.