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 decentralisation. Ducat leverages the Taproot upgrade, using Tapscript script paths controlled by governance-approved inscriptions, to create secure, auditable primitives native to Bitcoin Layer 1. This is achieved without requiring an intermediating Layer 2 and approximates smart contract functionality while maintaining Bitcoin’s core trust assumptions.

As the Bitcoin-native economy grows dramatically, it needs a unit of account whose collateral is managed in a fully decentralised manner, without inheriting the security assumptions of any specific Layer 2.

The Ducat Protocol consists of 8 core components:

1. UNIT – A BTC-overcollateralised debt token soft-pegged to the USD.

2. Multi-Party Computation (MPC) Network – A decentralised network of nodes, known as “guardians” in the protocol, which securely evaluate, reconstruct, co-sign, and broadcast user-submitted Partially Signed Bitcoin Transactions (PSBTs), without accessing user secrets or controlling funds.

3. Transaction Builder (ClientSDK)- The Transaction Builder constructs Partially Signed Bitcoin Transactions (PSBTs) according to Ducat Protocol rules. It manages wallet signing and coordinates communication with the MPC Network.

4. Canonical Reference Satoshis (CRSs) – Satoshis inscribed with pointers (referred to as contracts) that record Ducat protocol consensus rules related to key parameters and governance mechanisms, such as the vault liquidation threshold. Ducat uses the following key CRSs:

   1. The protocol CRS – Regulates UNIT’s risk and collateralisation parameters

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

   3. The oracle CRS – Lists all accepted oracle solutions used by the protocol

   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 reference

5. Closely related to the CRSs described above, the following data records are 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 within 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: Specifies the values for a given term, as 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 them.

   6. Vault Token: A record custodied by the user’s wallet. It stores data that references (and helps locate) the corresponding vault record on-chain, along with any user-configurable vault settings.

   7. Master Contract: The final record, referencing all other contracts via their ordinal satoshi identifiers. It governs which contracts are considered canonical within the protocol.

6. Bitcoin Collateralised Debt Positions (BCDPs) – BTC assets escrowed, or ‘vaulted’, by users in accordance with the vault CRS in order to mint and 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. Ducat Nodes (Validation Layer) – A transaction-parsing software, similar to a Bitcoin Core node, that allows stakeholders to verify the validity of all protocol-related transactions and filter out non-compliant protocol interactions. The validation layer parses:

   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 stablecoin token

   5. Vault Transactions – Lock BTC in exchange for UNIT

   6. Contract Transactions – Define the variable terms of the protocol

   7. Record Transactions – Store data referenced by contracts

   8. Proposal Transactions – Propose changes to the contract

   9. Voting Transactions – Use DUCAT to vote on open proposals

The protocol and all its components will be open-sourced. An independent oracle will operate the price-signalling mechanism for the liquidation engine off-band, but in a verifiable way.