DUCAT’SBitcoin Guild
COMPLETE SITE MAP

Every lesson and learning tool

Browse the full Guild without hidden routes. Bitcoin foundations come first. Ducat appears later as a specialist application of Bitcoin mechanisms.

BA-00

Start here: How Bitcoin works

Follow one payment from a wallet to confirmations before choosing a deeper path.

  1. How Bitcoin worksFollow one payment from Alice's wallet to Bob, through independent node checks, a miner's candidate block, and confirmations.
  2. Transactions, outputs, locks, keys, and addressesBuild one payment from spendable outputs and follow how an address becomes a locking script, a key authorizes an input, and change becomes a new output.
  3. Blocks, mining, difficulty, and validationSee how a candidate block is assembled, how proof of work is found, how difficulty is encoded, and why full nodes still decide whether the block is valid.
  4. Full nodes, the blockchain, and reorgsConnect peer messages, mempool, block index, chainstate, most-work selection, confirmations, and temporary reorganizations into one full-node view.
BA-00P

Use Bitcoin safely: a practical first path

Practise choosing a wallet, receiving, sending, fees, backups, recovery, scams, and privacy with simulated funds before protocol theory.

  1. Choose a wallet by trade-offsCompare custody, source transparency, platform, backup model, hardware isolation, coin control, and support without treating one wallet as best for everyone.
  2. Receive a first paymentCreate and verify a fresh receiving instruction, distinguish an address from a private key, and monitor the payment from unconfirmed relay to chosen confirmation depth.
  3. Send with fee and changeReview destination, amount, selected outputs, fee rate, absolute fee, and change before signing a simulated Bitcoin payment.
  4. Handle a slow paymentDiagnose low fees, distinguish replace-by-fee from child-pays-for-parent, and decide when waiting is safer than changing the transaction.
  5. Back up and recoverProtect seed words, passphrase, wallet policy, and derivation information, then test recovery without exposing live secrets.
  6. Defend against scams and signing mistakesRecognize seed phishing, clipboard replacement, address substitution, fake support, malicious approvals, and irreversible-payment pressure.
  7. Use Bitcoin with deliberate privacyUnderstand address reuse, change identification, coin selection, network observers, and the privacy trade-offs of sharing wallet or exchange data.
  8. Buy and withdraw bitcoin safelyCompare exchange and peer-to-peer purchase risks, verify the withdrawal network and address, test with a small amount, and confirm self-custody before increasing exposure.
BA-01

Foundations of money and computation

Build the mental models needed before touching a transaction.

  1. What money doesMoney helps people compare value, exchange goods, settle debts, and carry purchasing power across time. Different forms of money make different trade-offs.
  2. Ledgers and double spendingA ledger records who can spend each scarce digital unit. A shared order prevents two conflicting payments from both becoming final.
  3. Bits, bytes, hex, and endiannessComputers store Bitcoin data as bits grouped into bytes. Hexadecimal is a compact way to display those bytes, while byte order determines how a number is read.
  4. Data structures and state machinesBitcoin tracks spendable transaction outputs instead of account balances. Every valid transaction consumes existing outputs and creates new ones.
  5. Networks and adversariesBitcoin nodes exchange information over an imperfect network. They must remain safe when messages arrive late, connections split, or peers lie.
  6. Open-source verificationAnyone can inspect the rules, run the software, and reproduce a result. Security comes from independent checks rather than trust in one operator.
  7. CompactSize and Bitcoin byte fieldsParse variable-length counts, fixed-width integers, hashes, scripts, and length-prefixed vectors without confusing display order with serialized order.
BA-02

Mathematics and cryptography

Understand the primitives without treating cryptography as magic.

  1. Modular arithmeticModular arithmetic wraps numbers around a fixed boundary, like hours on a clock. Bitcoin's signature mathematics uses this kind of arithmetic.
  2. Hash functions and SHA-256A hash turns any message into a fixed-size fingerprint. Bitcoin commonly uses the Secure Hash Algorithm 256, called SHA-256, to detect changes and make commitments.
  3. Hash160 and Merkle treesBitcoin combines two hash functions for some identifiers and arranges transaction hashes in a tree so one item can be proven part of a larger set.
  4. Elliptic-curve keysA private key is a secret number. Bitcoin multiplies it by a fixed curve point to create a public key, a one-way operation used to authorize spending.
  5. ECDSA signaturesThe Elliptic Curve Digital Signature Algorithm, called ECDSA, lets a private key authorize a message without revealing the key. Safe signing also depends on a unique secret nonce.
  6. Schnorr and BIP340Schnorr signatures use simpler algebra than Bitcoin's earlier signature system. Bitcoin Improvement Proposal 340 defines the exact Schnorr format used by Taproot.
  7. Tagged hashesA tagged hash adds a purpose label before hashing. This stops the same bytes from being mistaken for a message used by a different protocol rule.
  8. Threshold cryptographyThreshold signing divides authority among several participants. A required number can create one valid group signature without combining their secret shares.
  9. The Bitcoin cryptography mapConnect SHA-256, HASH256, HASH160, HMAC-SHA512, PBKDF2, secp256k1, ECDSA, Schnorr, tagged hashes, and Merkle commitments to the exact job each performs.
BA-03

History, economics, and game theory

Place Bitcoin in its cypherpunk, monetary, and institutional context.

  1. Digital cash before BitcoinEarlier digital cash projects solved pieces of the puzzle, including private payments and costly computation. None combined ownership, public ordering, and open validation in Bitcoin's way.
  2. The genesis and early networkBitcoin began with a public paper, public software, and a first block. The launch sequence matters because nobody received private control of the ledger rules.
  3. Scarcity and issuanceNew bitcoin enters circulation through block rewards that fall over time. Mining difficulty adjusts to production speed, and transaction fees increasingly pay miners.
  4. Austrian and competing monetary viewsDifferent schools disagree about money, debt, falling prices, and the role of institutions. The lesson separates testable claims from economic values.
  5. Incentive compatibilityBitcoin participants do not all want the same thing. The system works when following valid rules usually pays better than attacking or accepting invalid history.
  6. Adoption and network effectsA payment network becomes more useful when more people and businesses can use it, but reliability, cost, custody, law, and coordination can slow adoption.
  7. Fork historyA fork occurs when participants follow different histories or rule sets. Past disputes show how software rules, mining work, businesses, and individual validation interact.
  8. Critiques and falsifiable claimsA useful critique states a mechanism, measurable variables, a time horizon, and evidence that could prove it wrong. This lesson applies that discipline to Bitcoin debates.
BA-04

Keys, addresses, wallets, and custody

Control keys safely and understand every encoding layer.

  1. Private and public keysA private key is the secret that authorizes a spend. A public key lets others verify that authorization, while an address describes where a payment can be locked.
  2. Base58, Bech32, and Bech32mBitcoin addresses are human-readable encodings with a network marker and error-detecting checksum. Three formats exist because Bitcoin added new spending types over time.
  3. BIP39 mnemonics and passphrasesBitcoin Improvement Proposal 39 defines word-based wallet backups. Its optional passphrase creates a different wallet, so losing either the words or passphrase prevents recovery.
  4. HD derivationA hierarchical deterministic wallet creates many related keys from one root. Bitcoin Improvement Proposal 32 defines normal and hardened child-key paths with different exposure risks.
  5. Descriptors and miniscript policyA wallet descriptor is a precise recipe for finding keys and constructing spending conditions. Miniscript is a structured way to express some of those conditions safely.
  6. Watch-only and air-gapped workflowsA watch-only wallet can observe funds and build transactions without private keys. An offline signer can then review and authorize the exact transaction.
  7. PSBTA Partially Signed Bitcoin Transaction, called a PSBT, carries one unsigned transaction plus the metadata signers need to review, sign, combine, and finalize it.
  8. Multisig and threshold custodyA multisignature script asks Bitcoin to verify several visible signatures. Threshold signing instead lets several participants cooperate to produce one group signature.
  9. Backups and recoveryRecovery requires more than seed words. A complete plan preserves every passphrase, key path, spending policy, and quorum rule needed to recreate and test the wallet.
  10. Private keys, public keys, and key hashesInspect valid scalar bounds, compressed curve points, public-key hashes, authorization, and the difference between a key, address, script, and spendable output.
  11. WIF, Base58Check, Bech32, Bech32m, and checksumsEncode and decode private-key and destination text formats byte by byte, including network markers, witness versions, conversion alphabets, and checksum limits.
  12. HD wallet trees and extended-key anatomyDecode xpub and xprv fields, derive BIP44, BIP49, BIP84, and BIP86 branches, and identify what recovery metadata and public-key exposure imply.
BA-05

Transactions, UTXOs, and the mempool

Construct, inspect, price, and debug Bitcoin transactions.

  1. The UTXO modelA UTXO is a specific unspent transaction output; transactions consume whole outputs and create new ones.
  2. Inputs, outputs, and changeInputs reference prior outpoints and provide witnesses; outputs assign values to new locking conditions.
  3. Serialization and txidsVersion, vectors, scripts, sequence, witness, and locktime serialize deterministically; txid and wtxid commit to different data.
  4. Fees, weight, and vbytesFees equal inputs minus outputs, while feerates use virtual size derived from transaction weight.
  5. Coin selectionWallets trade off fees, privacy, change, consolidation, and future spending cost when selecting UTXOs.
  6. Mempool policy versus consensusNodes can reject relay or mining of a consensus-valid transaction under local policy without making it invalid forever.
  7. Confirmations and finalityConfirmations measure accumulated proof of work after inclusion; required depth depends on value, threat model, and protocol configuration.
  8. RBFReplace-by-fee uses sequence and mempool rules to replace an unconfirmed transaction with a higher-fee conflict.
  9. CPFP and package economicsA child can pay enough fee for miners to include a low-fee parent when the package feerate is attractive.
  10. TimelocksnLockTime, sequence, CLTV, and CSV constrain when transactions or spending paths become valid.
  11. Raw transaction inputs and outputsDecode outpoints, ScriptSig, sequence, amounts, ScriptPubKeys, CompactSize lengths, and locktime directly from serialized transaction bytes.
  12. Witnesses, wtxids, and block commitmentsTrace witness serialization, txid versus wtxid, the coinbase witness reserved value, and the witness commitment that binds SegWit data into a block.
  13. The complete mempool lifecycleFollow admission, relay, conflicts, RBF replacement, block connection, reorg reconsideration, expiry, size eviction, and local policy differences.
BA-06

Bitcoin Script

Execute locking conditions one opcode and stack item at a time.

  1. Stack-machine executionScript is a deliberately constrained stack language whose success depends on final truth and consensus limits.
  2. Pushes, arithmetic, and control flowData pushes, numeric encodings, conditionals, and verification opcodes compose spending policies.
  3. Signature checks and sighashesCHECKSIG validates a signature over a transaction digest selected by a sighash mode.
  4. P2PKH and P2SHLegacy templates separate address-friendly commitments from revealed spending scripts.
  5. Witness programsSegWit moves authorization data into witness structures and versions the program semantics.
  6. Multisig and policy compositionMultiple keys, timelocks, and hashlocks can form recovery, escrow, and channel policies.
  7. Script limits and malleabilityDisabled opcodes, resource limits, encoding rules, and malleability protections constrain safe composition.
  8. Script debuggingExperts trace every stack transition, identify the failing predicate, and distinguish malformed witnesses from false conditions.
  9. P2PK, P2PKH, P2MS, P2SH, and OP_RETURNCompare the exact assembly, serialized bytes, spend data, standard uses, and failure boundary for Bitcoin's classic Script templates.
  10. Native and nested SegWit scriptsConstruct P2WPKH, P2WSH, P2SH-P2WPKH, and P2SH-P2WSH outputs and follow each redeem, witness, hash, and signature check.
BA-07

SegWit, Taproot, and modern signing

Understand the upgrades that made modern Bitcoin protocols practical.

  1. SegWit architectureSegWit separates witness data, fixes third-party malleability, changes weight accounting, and enables safer second-layer commitments.
  2. Taproot outputsP2TR commits to an internal key optionally tweaked by a script-tree root, presenting one compact output key on chain.
  3. Key-path spendingThe internal key holder can authorize a spend with a tweaked Schnorr signature without revealing alternative scripts.
  4. TapscriptScript-path spends reveal one leaf, its witness, and a control block while keeping unused branches private.
  5. Taptrees and control blocksMerkle paths prove that a revealed leaf was committed into the Taproot output key.
  6. Unspendable internal keysProtocols can use a provably unspendable internal key to require script-path enforcement rather than retaining a hidden bypass.
  7. MuSig and key aggregationInteractive multisignature schemes aggregate public keys and signatures while defending against rogue-key attacks.
  8. FROSTFlexible Round-Optimized Schnorr Threshold signing coordinates nonce commitments and signature shares from a threshold subset.
  9. Covenant proposalsCTV, APO, CAT-related designs, and other proposals trade expressiveness, analyzability, and deployment risk.
BA-08

Mining, blocks, and consensus

Follow a transaction from gossip to deeply buried block state.

  1. Block structureA block header commits to version, prior block, transaction Merkle root, time, target, and nonce.
  2. Proof of workMining searches header variations for a hash below the target, making history costly to extend and rewrite.
  3. Difficulty adjustmentBitcoin retargets periodically to keep average block production near ten minutes despite changing hash rate.
  4. Block validationFull nodes independently check proof of work, transactions, scripts, issuance, weight, and contextual consensus rules.
  5. Chain selection and reorgsNodes follow the valid chain with the most accumulated work and may disconnect blocks during reorganization.
  6. Coinbase and subsidyThe coinbase creates permitted subsidy and collects fees, with maturity rules before its outputs can be spent.
  7. Mining pools and templatesPools coordinate work and payouts; Stratum and template negotiation affect miner autonomy and centralization.
  8. Attacks and security budgetDouble-spends, selfish mining, censorship, pool concentration, and fee-market uncertainty require economic analysis.
  9. Raw block anatomy and blk.datDecode disk framing, the 80-byte header, CompactSize transaction count, coinbase, ordinary transactions, witness commitment, and neighbouring block links.
  10. Mining lifecycle and candidate blocksFollow mempool selection, ancestor packages, template construction, coinbase and witness commitments, target search, broadcast, and independent full-node validation.
  11. Block time, MedianTimePast, and future limitsValidate a candidate timestamp against the median of the previous eleven blocks and the receiving node's two-hour future-time limit.
  12. Version bits and soft-fork activationDecode the block-version marker and deployment bits, then follow period thresholds through DEFINED, STARTED, LOCKED_IN, ACTIVE, or FAILED.
  13. Block height and BIP34 coinbase commitmentsEncode the block height as the first minimally encoded Script number in the coinbase ScriptSig and keep it distinct from header fields.
  14. Soft forks, hard forks, and compatibilityRun one block through old and new rule sets to see subset restrictions, rule expansions, activation risk, and persistent chain splits.
BA-09

Nodes, networking, and Bitcoin Core

Operate and reason about the software enforcing the rules.

  1. Peer discovery and handshakesNodes discover peers, negotiate services, and exchange inventory without a central network registry.
  2. Transaction and block relayCompact blocks, headers-first synchronization, feefilters, and relay policies reduce bandwidth and latency.
  3. Initial block downloadA new node downloads and validates historical headers and blocks before reaching the current tip.
  4. UTXO set and chainstateBitcoin Core separates block storage, indexes, mempool state, and the active UTXO database.
  5. Pruning and assumeutxoResource-saving modes change storage or bootstrap work without replacing final validation guarantees.
  6. RPC and ZMQRPC controls a node while event interfaces support applications that need chain and mempool updates.
  7. Consensus changes and BIPsSoft forks tighten validity rules and require deployment coordination across users, miners, software, and markets.
  8. Code review and release processBitcoin Core changes undergo adversarial review, testing, backport discipline, and reproducible release work.
  9. Full node architectureConnect peers, message parsing, validation, mempool, block index, chainstate, wallet, RPC, ZMQ, indexes, pruning, and reorg handling in one system map.
  10. Bitcoin P2P message bytesParse network magic, command, payload length, checksum, and payload from a byte stream before applying command-specific limits and validation.
BA-10

Privacy, security, and threat modelling

Protect users against both cryptographic and operational failure.

  1. Common-input and change heuristicsChain surveillance infers ownership from transaction structure; heuristics are probabilistic, not consensus facts.
  2. CoinJoinCollaborative transactions break simple ownership heuristics but introduce coordination, amount, and operational considerations.
  3. PayJoin and silent paymentsReceiver-assisted construction and reusable scanning addresses reduce common transaction graph signals.
  4. Network privacyIP observation, timing, wallet queries, and address reuse can reveal links even when on-chain structure is careful.
  5. Hardware-wallet threat modelsSecure elements, firmware, host compromise, supply chains, and verification UX define actual signing security.
  6. Multisig operationsGeographic separation and policy redundancy help only when backups, quorum availability, and change verification are practiced.
  7. Protocol attack surfacesParsing, consensus divergence, nonce reuse, oracle manipulation, key compromise, and economic exploits require layered controls.
  8. Incident responsePreparation includes detection, communication, key rotation or migration, evidence preservation, and safe recovery procedures.
BA-11

Lightning, channels, DLCs, and layered systems

Understand off-chain enforcement and its on-chain escape hatches.

  1. Payment channelsPre-signed state updates let parties transact off chain while retaining an enforceable on-chain settlement path.
  2. Lightning commitmentsRevocable commitments, HTLCs, timelocks, and justice or replacement mechanisms manage unilateral closes.
  3. Routing and liquidityMulti-hop payments use onion routing and conditional transfers but depend on directional channel liquidity.
  4. Watchtowers and backupsOffline protection and channel-state recovery address different failure modes and have distinct trust assumptions.
  5. DLCsDiscreet Log Contracts use oracle attestations and adaptor signatures so outcomes settle without revealing the full contract logic on chain.
  6. Federations and sidechainsPegged systems trade different custody, consensus, and exit assumptions for additional functionality.
  7. Ark and shared UTXOsEmerging protocols explore coordinated UTXO ownership and efficient exits with new availability assumptions.
  8. Layer comparisonExperts compare custody, unilateral exit, data availability, capital efficiency, privacy, and failure recovery rather than relying on labels.
BA-12

Data protocols, Ordinals, Runes, and BitVM

Analyze protocols built from Bitcoin transaction semantics.

  1. OP_RETURN and data commitmentsOP_RETURN outputs carry provably unspendable data but do not themselves enforce later spending conditions.
  2. Ordinals and inscriptionsOrdinal theory assigns ordering conventions to satoshis while inscriptions use witness envelopes interpreted by off-chain indexers.
  3. RunesRunestones encode fungible token operations whose meaning is reconstructed by compatible indexers; cenotaph behavior supports upgrade semantics through burns.
  4. Indexer consensusMeta-protocol users depend on deterministic off-chain interpretation and must understand divergence and reorg handling.
  5. BitVMBitVM-style systems use commitments, challenge games, and Bitcoin-enforced disputes to verify computations without adding general execution to consensus.
  6. Client-side validationSome protocols keep rich state off chain while using Bitcoin commitments and proofs to constrain valid transitions.
  7. Policy and resource debatesData protocols affect fees, relay policy, UTXO growth, miner incentives, and social arguments about block-space use.
BA-13

Markets, financialization, and risk

Connect protocol mechanics to real financial systems without confusing forecasts with facts.

  1. Spot, forwards, and futuresMarket instruments differ in settlement, leverage, margin, counterparty exposure, and relationship to spot bitcoin.
  2. The basis tradeA cash-and-carry trade holds spot and shorts a premium future, earning convergence while bearing funding, custody, margin, and execution risks.
  3. ETFs and custodial productsExchange-traded products improve access but introduce custody, authorized participant, tracking, jurisdiction, and redemption structures.
  4. Liquidity and market microstructureOrder books, spreads, slippage, fragmentation, leverage, and liquidation cascades shape realized execution.
  5. Mining economicsRevenue depends on subsidy, fees, hash price, energy, hardware efficiency, uptime, financing, and difficulty.
  6. Treasury strategyHolding bitcoin changes liquidity, refinancing, accounting, governance, and drawdown risk rather than simply adding upside.
  7. Stablecoins and bitcoin-backed creditCredit systems add liquidation, oracle, governance, and maturity risks around otherwise bearer collateral.
  8. Scenario modellingForecasts must expose assumptions, ranges, sensitivities, and version history instead of presenting a single projected number as truth.
BA-14

Bitcoin protocol engineering

Move from understanding to building, testing, and reviewing.

  1. Raw transaction constructionEngineers serialize fields, compute sighashes, sign inputs, and inspect witnesses without relying solely on wallet abstractions.
  2. Regtest workflowsA private deterministic chain enables instant mining, reorgs, policy experiments, and repeatable failure tests.
  3. Functional and unit testingGood tests isolate consensus logic, RPC behavior, wallet state, serialization, and end-to-end node interactions.
  4. Fuzzing and property testsGenerated inputs uncover parser and state-machine edge cases while invariants catch broad classes of failure.
  5. Rust and TypeScript Bitcoin librariesLibrary abstractions accelerate work but must be checked against serialization, network, sighash, and script semantics.
  6. Reading Bitcoin CoreTrace behavior from RPC or P2P entry points through validation and state updates while respecting lock and ownership boundaries.
  7. BIP design and reviewProtocol proposals need precise motivation, compatibility, activation, test vectors, security analysis, and reference behavior.
  8. Responsible deploymentSignet, testnet, regtest, feature gates, monitoring, rollback constraints, and disclosure processes reduce real-funds risk.
DA-01

Ducat system architecture

Map every actor, state object, trust boundary, and Bitcoin commitment.

  1. What Ducat is designed to doDucat lets people borrow against bitcoin without first moving that collateral to another blockchain. UNIT is Ducat’s dollar-pegged stablecoin: one output of a wider system of vaults, risk checks, signatures, price data, and Bitcoin transactions.
  2. The end-to-end system lifecycleA user action moves through client construction, Bitcoin transactions, Guardian authorization, confirmation, validator reconstruction, and, when required, an oracle-triggered liquidation path.
  3. Actors and responsibilitiesVault owners, Guardians, validators, oracles, relays, liquidators, LPs, and operators have distinct powers, information, and failure modes.
  4. Vault stateA vault is represented by Bitcoin outputs plus protocol metadata, with each valid action consuming an earlier state and creating its successor.
  5. Accounts, reserves, and UNIT debtIssuance and reserve accounts are UTXO-based protocol objects whose availability and transitions are tracked by validators and coordinated by Guardians.
  6. The Bitcoin enforcement boundaryBitcoin enforces committed transaction and Script conditions, while richer Ducat state and economic rules are reconstructed and checked by protocol participants.
  7. External trust and availabilityGuardians, oracles, validators, relays, clients, and operators remain explicit honesty or liveness dependencies even where Bitcoin constrains the final spend.
  8. Protocol profiles and configurationNetwork parameters, Guardian keys, oracle keys, ratios, fees, and feature settings are versioned inputs to clients and validators.
  9. Current versus target architectureRepository code, deployed environments, security roadmaps, and public descriptions can differ; every claim must carry a date and status.
DA-02

UNIT and the Runes layer

Understand UNIT as one component of Ducat and trace how its token state relates to Bitcoin transactions and vault debt.

  1. What UNIT representsUNIT is Ducat's issued asset; its token movements and its relationship to bitcoin collateral must be distinguished from the BTC locked in vault outputs.
  2. Rune identity and issuanceRune identifiers and issuance rules establish which on-chain token is UNIT and how compatible indexers recognize its supply events.
  3. Runestones and edictsRune-compatible transaction data describes token allocations between outputs while Bitcoin consensus continues to validate only the underlying transaction.
  4. UNIT transfer semanticsA UNIT transfer assigns token balances to transaction outputs under Rune indexing rules without by itself changing a Ducat vault's collateral or debt.
  5. Cenotaphs and invalid messagesMalformed or deliberately unrecognized Rune messages can burn affected token balances, making parser compatibility and transaction construction safety essential.
  6. Indexer reconstruction and reorgsValidators and Rune-compatible indexers deterministically replay confirmed transactions and must reverse and reapply derived token state during Bitcoin reorganizations.
  7. UNIT state versus vault stateRune token allocations, vault UTXOs, collateral values, and debt records are related protocol views but are not one interchangeable state object.
  8. Issue and burn reconciliationBorrow and repay flows connect UNIT issuance or burning to vault debt transitions so validators can reconcile the token change with the collateralized action.
  9. Compatibility and failure boundariesWallet construction, indexer rules, network configuration, confirmation handling, and version compatibility determine whether every participant reconstructs the same UNIT state.
DA-03

Ducat vaults and transactions

Build and inspect every vault action end to end.

  1. Open a vaultThe client fetches protocol and oracle data, reserves issuance capacity, builds and signs PSBTs, and submits the request for Guardian validation and co-signing.
  2. Deposit and withdrawCollateral changes consume the current vault UTXO and create a successor while validation enforces allowed value and ratio transitions.
  3. Borrow and repayIssuance or burn activity is paired with a vault state update so UNIT changes reconcile with the vault differential.
  4. Two-transaction actionsOpen, borrow, and repay use an issue-or-burn transaction plus a vault transaction connected so package structure and fees matter.
  5. Single-transaction actionsDeposit, withdraw, repo, and trim update vault state without the separate issuance or burn pattern.
  6. PSBT manifests and signing inputsThe client prepares transaction context while signing code derives the precise sighash and Taproot context that each signer must authorize.
  7. Vault metadata versus enforcementOP_RETURN records help reconstruct state, but spend authorization comes from committed Script paths and signatures rather than metadata alone.
  8. Fees, signature checks, and control blocksDucat estimates transaction weight from inputs, outputs, witnesses, signatures, price commitments, and taptree depth.
  9. Confirmations and lifecycle stateValidator and client behavior must read environment-specific confirmation and state rules instead of teaching a timeless hard-coded number.
  10. CPFP for Ducat transaction pairsPackage feerate explains how a fee-paying vault child can make a zero-fee issue or burn parent mineable.
DA-04

Guardian, FROST, DKG, and custody

Understand what Guardians can sign, refuse, coordinate, and never learn.

  1. Guardian responsibilitiesGuardians receive signed requests, validate protocol rules and transaction structure, reserve issuance accounts, and contribute authorization when policy permits.
  2. FROST signing roundsGuardians exchange nonce commitments and signature shares so a threshold subset produces one BIP340-compatible group signature.
  3. Distributed key generationParticipant-local DKG creates shares without any coordinator learning the group secret or plaintext participant shares.
  4. Thresholds and quorumA t-of-n topology trades availability against compromise resistance; current tests and planned deployments must not be confused with one permanent quorum.
  5. Coordinator trust boundarySignature aggregation is public; safety depends on each honest Guardian independently rejecting invalid signing requests.
  6. TEE custodyAttested enclaves bind code measurements and short-lived sealing keys so shares are finalized, stored, and used inside confidential workloads.
  7. Signing policy bindingRequest IDs, action types, transaction hashes, signing inputs, group keys, and policy digests prevent replay and cross-round substitution.
  8. Guardian passphrasesWallet passphrases protect encrypted local wallet files; production Guardian key packages have separate enclave and operator custody controls.
  9. Failure, rotation, and migrationThe v1 custody design treats lost Guardians and rotations as a new DKG plus funds migration rather than reconstructing shares centrally.
  10. Production-readiness boundariesImplemented policy gates, test proofs, live cloud rehearsals, external audits, and real-funds enablement are separate milestones.
DA-05

Ducat oracle and liquidation

Trace price data into a Bitcoin-enforceable liquidation spend.

  1. How the Ducat oracle worksFollow one bitcoin price from a signed Chainlink report, through Ducat's precommitted liquidation threshold, to the exact Taproot witness that Bitcoin verifies.
  2. Blind price ladderThe oracle publishes pre-committed threshold events across collateral-rate buckets so it need not know which users selected which thresholds.
  3. BIP340 commitment hashWallet and oracle compute a tagged commitment over oracle key, network, base price, timestamp, and threshold price.
  4. Nostr transportReplaceable signed events distribute current snapshots, threshold contracts, and breach material; relays transport data but are not the trust anchor.
  5. Atomic snapshot promotionThe current snapshot is published only after its complete ladder succeeds, allowing clients to stay on the prior coherent snapshot after partial failure.
  6. Preimages and Hash160A breached threshold reveals secret material whose Hash160 matches the value committed into the vault's liquidation Script leaf.
  7. Liquidation Taproot leafThe revealed preimage satisfies the hashlock and a Guardian Schnorr signature satisfies CHECKSIG, making the oracle outcome consumable by Bitcoin Script.
  8. Why the Ducat oracle is Bitcoin-nativeChainlink supplies authenticated data, but Bitcoin-native enforcement comes from the committed hashlock and signature path inside the Bitcoin UTXO.
  9. Oracle freshness and failure modesStale prices, relay availability, signer rotation, incomplete ladders, configuration drift, and undeployed security fixes must fail closed or be surfaced.
  10. Liquidation cycleDetection, preimage release, candidate selection, Guardian validation, repo or trim construction, broadcast, confirmation, and resulting reserve flows form the liquidation lifecycle.
DA-06

Ducat economics, LPs, and revenue

Model incentives with explicit formulas and versioned assumptions.

  1. Collateral ratiosDebt, BTC collateral value, liquidation threshold, and minimum vault ratios determine available actions and risk distance.
  2. Liquidation taxProtocol calculations combine liquidation threshold and configured tax parameters; observed percentages must be derived from the active profile.
  3. Liquidator subsidyThe subsidy can rise as a vault falls below a configured ratio, subject to thresholds, increments, and reserve-rate floors.
  4. Repo and trim economicsFull and partial liquidation change collateral, debt, liquidator consideration, and reserve flows through different transaction shapes.
  5. The 8-9% claimAny quoted liquidation profit must be decomposed into active tax, subsidy, collateral ratio, execution costs, slippage, and price movement rather than memorized.
  6. LP revenue shareLP returns require a versioned formula for eligible revenue, allocation weights, utilization, capital, duration, and losses; absent commercial inputs remain unknown.
  7. Protocol revenueFees, spreads, issuance activity, liquidations, and reserve deployment form scenarios rather than guaranteed protocol revenue.
  8. Forecast constructionBase, downside, and upside cases expose volume, price, utilization, fee, adoption, churn, and expense assumptions with sensitivities.
  9. Basis-trade strategyIf Ducat reserves or LPs use a basis trade, the model must include collateral custody, futures margin, funding, roll, liquidation, venue, and convergence risk.
  10. Risk-adjusted communicationFounder-grade explanations separate accounting revenue, economic profit, token or LP distributions, liquidity, and tail risk.
DA-07

Ducat validation, operations, and governance

Operate the protocol and challenge its security story.

  1. Validator reconstructionValidators scan Bitcoin blocks, maintain UTXOs and protocol objects, validate UNIT transfers against vault differentials, and serve query APIs.
  2. Guardian-validator separationValidators reconstruct and check state while Guardians control signing; centralizing or confusing these roles changes the threat model.
  3. Client workflowThe SDK coordinates validator reads, oracle data, funding selection, PSBT construction, wallet signatures, Guardian requests, and broadcasts.
  4. Observability and watchtowersHealth checks cover chain tip, oracle freshness, ladder coverage, commitments, Guardian readiness, vault state, and transaction outcomes.
  5. Deployment environmentsRegtest, Mutinynet, testnet targets, staging names, and mainnet readiness must be identified by actual configuration and deployed artifact, not labels.
  6. Upgrade and compatibilityProtocol versions, taptree layout, oracle event formats, key packages, indexer rules, and client compatibility require coordinated migration.
  7. Governance powersExperts enumerate who can change configurations, rotate keys, deploy oracle workflows, update clients, pause operations, or migrate funds.
  8. Threat-model reviewOracle compromise, Guardian collusion, liveness loss, validator divergence, signing-policy bugs, fee spikes, reorgs, and economic attacks each need explicit mitigations.
  9. Audit and evidenceTests, conformance vectors, attestation receipts, reproducible builds, live rehearsals, and external review support different security claims.
  10. Public claims disciplineMarketing language must be traceable to current evidence and must not promote planned decentralization or undeployed fixes as live behavior.

Practice and reference

EX

Explorer and workbenches

Decode live chain objects and manipulate exact Bitcoin mechanisms.

GI

Editorial guide

Ownership, changes, corrections and course map.

PR

Your progress

Mastery, retention risk, weak spots and lab completion.