Overview

Bitcoin's primary design as a store of value and settlement layer has created an opportunity for complementary systems that provide price stability while preserving Bitcoin's security and decentralization. Ducat leverages the Taproot upgrade, enabling Tapscript script paths controlled by governance-agreed inscriptions, to create secure, auditable primitives native to the Bitcoin L1 (without needing an intermediating L2) which approximate smart contracts, while retaining Bitcoin’s trust assumptions.

As the Bitcoin-native economy, defined as L1-native protocols and L2s, grows dramatically, it needs a store of account whose collateral is managed in a fully decentralised manner, without inheriting the security assumptions of a specific Bitcoin L2.

The Ducat Protocol consists of 8 core components:

1. UNIT - The BTC-Overcollateralized debt token soft pegged to the USD

2. MPC Network - the decentralised network of nodes (referred to as “guardians” in our documentation), that will strictly, and blindly, evaluate, reconstruct, countersign, and broadcast the PSBTs which the user submits.

3. Transaction Builder, aka the ClientSDK - the Transaction Builder constructs the Partially Signed Bitcoin Transactions (PSBTs) according to Ducat protocol rules, manages wallet signing, and communicates with the MPC Network.

4. Canonical Reference Satoshis (CRSs) - Satoshis inscribed with pointers (referred to as contracts) which memorialize Ducat protocol consensus rules around the protocol’s key parameters and governance mechanisms (e.g., the vault liquidation threshold). Ducat has the following key CRSs:

   1. The protocol CRS - Regulates UNIT’s risk and collateralization parameters

   2. The guardian CRS - Determines who operates the nodes of the MPC network;

   3. The oracle CRS - Lists all accepted oracle solutions the protocol works with;

   4. The minting CRS - Governs the minting and issuance of UNIT, including the UNIT Etcher address;

   5. The master CRS - Aggregates all pointers into a single registry for protocol consumption

5. Highly related to CRSs above, the sets of data records stored and referenced on-chain:

   1. Account Record: Defines an account that holds UNIT. Accounts are linked to the Mint Contract and used to issue UNIT in the protocol.

   2. Exchange Record: Defines the public key and hostname for an exchange server.

   3. Guardian Record: Defines the public key and hostname for a protocol guardian.

   4. Term Record: Defines the values for a given term (defined by the Protocol contract).

   5. Vault Record: Defines the configuration of a user’s vault. Vaults are linked to the Account Record used to create it.

   6. Vault Token: This is a record that is custodied by the user’s wallet. It’s used to store data that references (and helps locate) the matching vault record on-chain, plus any user-configurable settings for the vault.

   7. The final record is the Master Contract. This contract references the other contracts via their ordinal sat identifier, and governs which contracts are considered canonical in the protocol.

6. Bitcoin Collateralised Debt Positions (BCDPs) - BTC assets, escrowed or ‘vaulted’ by users according to the vault CRS to mint & collateralise UNIT.

7. The Reserve - The Reserve is a protocol-owned bad debt reserve designed to safeguard the vault pool against scenarios where liquidation auctions garner insufficient interest, resulting in discounted collateral that falls short of covering the debt.

8. The Validation Layer - a transaction parsing software similar to a bitcoin core node that allows stakeholders to verify the validity of all transactions associated with the protocol that will parse out any non compliant protocol interactions. The validation layer will parse:

   1. DUCAT Account UTXOs: Used for issuing DUCAT runes.

   2. DUCAT Spending UTXOs: The primary governance token.

   3. UNIT Account UTXOs: Used for issuing UNIT runes.

   4. UNIT Spending UTXOs: The primary stable-coin token.

   5. Vault Transactions: Locks BTC in exchange for UNIT.

   6. Contract Transactions: Defines the variable terms of the protocol.

   7. Record Transactions: Stores data that is referenced by the contract.

   8. Proposal Transactions: Proposes changes to the contract.

   9. Voting Transactions: Uses DUCAT to vote for open proposals.+

The protocol and all its working components will be open-sourced, and we will have an independent, recognized third-party oracle provider operate the price signalling mechanism to the liquidation engine off band but verifiably.