Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Ducat Protocol governs the issuance and redemption of UNIT Bitcoin-Collateralised Debt Positions (BCDPs).
Its governance token, DUCAT, is a Bitcoin-native asset issued as a Bitcoin Rune. Governance is enabled through a consensus mechanism based on ordinal inscriptions, enforced by a multi-party computation (MPC) network and verified by Ducat Validator nodes.
A truly decentralised economy has always required truly decentralised money, which, in turn, depends on decentralised, native collateral.
Today, the stablecoin market exists almost entirely on the Ethereum and Tron blockchain networks. Collateral typically takes the form of bank-custodied US Treasuries (USDT, USDC), a mix of Treasuries, Ethereum, and bridged BTC under highly centralised management (DAI), or CEX-custodied perpetual basis trading positions under similarly centralised control (Ethena and others).
All of these models share high exposure to centralised custodians and therefore unlimited regulatory liability, as well as varying degrees of internal control and principal–agent risk.
The Ducat Protocol leverages major advances in Bitcoin capability, enabling BTC-native, permissionless contracts for the first time. The time has finally come for a BTC-native, decentralised unit of stable account that combines Bitcoin’s censorship resistance with robust exogenous collateralisation and a responsible degree of capital efficiency.
Due to historical programmatic constraints, the BTC economy has existed in extreme isolation from the broader financial system. Just 1% of BTC is held in multi-signature bridges, and centralised exchanges hold around 10%. That means 89% of BTC has avoided proof-of-stake DeFi and any form of leverage, illustrating Bitcoin holders’ unique preference for self-custodial maximalism.
However, the current stablecoin market is dominated by highly centralised models. Tether, Circle, and Ethena rely on custodians, opaque collateral, and off-chain control, leaving them exposed to regulatory risk and censorship. MakerDAO initially offered a decentralised alternative but has since drifted toward centralisation through its collateral choices and governance structure. This leaves a clear gap in the market for a truly decentralised, self-custodied stablecoin — one that aligns with the ethos of Bitcoin itself.
An estimated 89% of BTC — roughly $1.9 trillion in market cap — remains completely unused and unleveraged. This presents a huge opportunity to offer BTC-native leverage to that capital base.
We know that BTC holders place extremely high value on self-custody. For this reason, we believe that traditional stablecoin collateralisation models, all of which reject self-custody, will prove incompatible with the preferences of many BTC users.
BTC cannot be bridged to other, more programmable chains without forfeiting self-custody. Historically, Bitcoin holders faced a binary trade-off: either integrate their BTC into the wider economy or maintain sovereign custody. That era is now behind us.
BTC is the only eligible collateral for borrowing. Since our product is built on Bitcoin Layer 1, this is a natural choice. In addition to being unseizable and provably decentralised, BTC outperforms all other cryptocurrencies across every relevant volatility and liquidity metric — including order book depth, market capitalisation, price stability, historical track record, institutional and regulatory acceptance, and brand recognition.
Based on our own experience and research, the only stablecoin product–market fit is USD-based. The US dollar accounts for over 99% of stablecoin market share. Moreover, the BTC economy does not need another attempt to reinvent the wheel by replicating the USD’s extensive real-world integrations with businesses and consumers. What it does need is a flexible, credible unit of stable account to facilitate the flow of funds between BTC-denominated assets and USD-denominated costs and liabilities.
DUCAT || UNIT is the first Bitcoin L1-native, decentralised stablecoin.
Ducat Protocol and its stablecoin, UNIT, form an overcollateralised primitive for Bitcoin-native DeFi, managed directly on Bitcoin via the DUCAT token.
Recent innovations in Bitcoin programmability have enabled BTC-Fi to begin closing the gap with EVM-based competitors. For the first time, this makes it possible to launch a stablecoin backed by native BTC. UNIT is 160% overcollateralised with BTC and governed by the DUCAT token.
Bitcoin Runes will be used to tokenise DUCAT, and governance will be managed through distributed consensus based on Ducat Node statistics from votes. For more details, see the governance section.
DUCAT
UNIT
HOW DUCAT WORKS
LIQUIDATIONS
TRUST ASSUMPTIONS
GOVERNANCE
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:
UNIT – A BTC-overcollateralised debt token soft-pegged to the USD.
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.
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.
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:
The protocol CRS – Regulates UNIT’s risk and collateralisation parameters
The guardian CRS – Determines who operates the nodes of the MPC network
The oracle CRS – Lists all accepted oracle solutions used by the protocol
Closely related to the CRSs described above, the following data records are stored and referenced on-chain:
Account Record: Defines an account that holds UNIT. Accounts are linked to the Mint Contract and used to issue UNIT within the protocol.
Exchange Record: Defines the public key and hostname for an exchange server.
Guardian Record: Defines the public key and hostname for a protocol guardian.
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.
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.
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:
DUCAT Account UTXOs – Used for issuing DUCAT runes
DUCAT Spending UTXOs – The primary governance token
UNIT Account UTXOs – Used for issuing UNIT runes
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.
The minting CRS – Governs the minting and issuance of UNIT, including the UNIT Etcher address
The master CRS – Aggregates all pointers into a single registry for protocol reference
Term Record: Specifies the values for a given term, as defined by the Protocol Contract.
Vault Record: Defines the configuration of a user’s vault. Vaults are linked to the Account Record used to create them.
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.
Master Contract: The final record, referencing all other contracts via their ordinal satoshi identifiers. It governs which contracts are considered canonical within the protocol.
UNIT Spending UTXOs – The primary stablecoin token
Vault Transactions – Lock BTC in exchange for UNIT
Contract Transactions – Define the variable terms of the protocol
Record Transactions – Store data referenced by contracts
Proposal Transactions – Propose changes to the contract
Voting Transactions – Use DUCAT to vote on open proposals
The network is secured by the MPC Network and by protocol specifications defined in the Master CRS. However, in the event that the network is compromised and invalid transactions are approved, Ducat Nodes act as decentralised validation mechanisms to preserve protocol integrity.
Tracking Valid UNIT: Ducat Nodes keep track of all valid UNIT. This means tokens that have been minted according to protocol rules set out in the Master CRS.
Maintaining Consensus: Ideally, the circulating UNIT supply and the balances recorded by Ducat Nodes should match exactly. If discrepancies arise due to a bug or compromise, nodes act as backstop validators to restore consistency.
Decentralised Validator: Ducat Nodes validate transactions against parameters defined through governance by DUCAT token holders.
Protocol-Specific Focus: Unlike general-purpose Ordinals or Runes indexers, Ducat Nodes focus solely on validating compliance with Ducat protocol rules. They do not assess market value.
User Control: We strongly recommend all users run their own Ducat Node and connect to it when managing their vaults.
Avoiding Manipulation: Running a personal node ensures users are not misled by compromised infrastructure or faulty data.
Track Valid UNIT and DUCAT: Verifies that all tokens are compliant with protocol rules.
Governance Support: Helps determine valid governance outcomes and tracks the latest Master Contract ID.
Although the protocol can operate without them, Ducat Nodes are vital for transparency, security, and decentralised control across the ecosystem.
The Ducat protocol is defined using the following on-chain contracts:
Oracle Contract: Governs the location of host records for the price exchanges.
Guardian Contract: Governs the terms for protocol guardians and the location of guardian records.
Mint Contract: Governs the minting and issuance of UNIT, and where UNIT is stored in reserve.
Protocol Contract: Defines all terms used in the Ducat protocol, along with the location of each term record.
In addition to the contracts above, the protocol uses several on-chain data records:
Account Record: Defines an account that holds UNIT. Accounts are linked to the Mint Contract and are used to issue UNIT within the protocol.
Exchange Record: Defines the public key and hostname for an exchange server.
Guardian Record: Defines the public key and hostname for a protocol guardian.
Term Record: Specifies the value for a given term, as defined by the Protocol Contract.
The final component is the Master Contract. This contract references all other contracts via their ordinal sat identifiers and governs which contracts are considered canonical within the protocol.
In a two-transaction process, the user returns some of their borrowed UNIT stablecoins to their vault. This reduction in debt lowers the Bitcoin price at which liquidation would be triggered, moving it further from the current price and giving the user a greater margin of safety.
The user initiates a transaction to repay their borrowed UNIT runes, sending them back to their vault UTXO as part of the transaction. The MPC network verifies the repayment amount and processes the return of UNIT runes. The transaction builder then constructs a PSBT that reduces the vault’s borrowed amount while maintaining the same BTC collateral. The output reflects the reduced debt and unchanged collateral in an updated vault UTXO.
In a second transaction, the new vault state is processed, paying the network fees for both transactions to ensure atomic execution. This generates an updated vault token reflecting the reduced borrowed amount and improved collateralisation ratio. The vault UTXO retains both the user update path and the guardian/oracle liquidation path, with the improved ratio reducing the likelihood of liquidation. An OP_RETURN output records the updated vault state, including the reduced borrowed amount and revised collateralisation ratio.
Together with the Open Vault function, these processes form a complete vault management system, allowing users to borrow against, repay, and maintain their BTC-collateralised positions while ensuring proper record-keeping and risk controls throughout.
All stablecoins issued by a Ducat vault must be backed by at least 160% Bitcoin collateral. However, due to limitations in Bitcoin’s current scripting capabilities, this level of collateralisation cannot be enforced purely within Bitcoin itself.
No transaction introspection: Bitcoin cannot inspect transaction details at execution time, making real-time collateral verification impossible at the base layer.
The Ducat protocol architecture can be broken down into the following diagram that show cases the steps that happen when a user attempts to borrow UNIT.
The MPC network acts as a distributed co-signer, designed to solve the liveness problem of a purely peer-to-peer network.
It validates transactions for vault operations, co-signs outputs alongside user signatures, manages Rune distributions between network and user UTXOs, verifies that collateral ratios remain above agreed thresholds, ensures the burning of repaid UNIT tokens, and enforces transaction ordering and compliance with protocol standards.
In the future, updates to Bitcoin such as OP_CHECKTEMPLATEVERIFY (CTV), OP_CHECKSIGFROMSTACK (CSFS), or OP_CAT could allow Ducat to operate without a guardian network. These changes would make it possible to enforce vault rules and transaction constraints directly in Bitcoin Script, removing the need for off-chain validation and threshold signatures. While these upgrades are not guaranteed, they illustrate a path toward a fully trust-minimised, peer-to-peer version of the protocol.
The user deposits Bitcoin and, in return, receives UNIT tokens, with the Bitcoin being locked as collateral in what the protocol defines as a newly created vault. The process takes place in two joint, concurrent transactions. First, the user receives their UNIT tokens. Second, their Bitcoin is moved into a vault, which creates an on-chain record of the vault’s creation.
The user requests an account UTXO from the MPC network. The network assigns a UNIT rune amount, verifies that the required amount of BTC is being deposited, checks the BTC/USD price at the time of the request, and calculates the necessary Bitcoin network fee.
Once these variables are confirmed, the transaction builder constructs a PSBT on the user’s behalf that includes the BTC deposit. The output of the transaction delivers UNIT tokens to the user, assigns the remaining runes to the MPC network’s account UTXO, and stores the user’s collateralised BTC in a designated output.
In a second transaction, the BTC from the previous transaction is deposited into the vault UTXO. This transaction also pays the fees for both transactions, ensuring atomic execution, and generates a vault token to record the vault’s creation for audit and record-keeping purposes.
The vault UTXO, where the BTC collateral is stored, has two spending paths that govern how the BTC can be accessed: one allows the user to update the vault, and the other allows the guardians and oracle to liquidate the vault if the collateralisation ratio falls below the liquidation threshold.
An OP_RETURN vault record tracks the evolution of the user’s borrowing activity and collateralisation history over time.
In a single transaction, the user removes some of their Bitcoin collateral from their vault while keeping the same amount of borrowed UNIT. This reduction in collateral increases the Bitcoin price at which liquidation would be triggered, moving it closer to the current price and reducing the user’s safety margin.
The user initiates a transaction to withdraw a portion of their BTC collateral from their vault UTXO. The MPC network verifies that the requested withdrawal maintains the required minimum collateralisation ratio for the existing borrowed UNIT position. The transaction builder then constructs a PSBT that separates the withdrawn BTC while retaining sufficient collateral in the vault. The outputs include the withdrawn BTC being returned to the user’s control and an updated vault UTXO with the reduced collateral amount.
In a second transaction, the new vault state is processed, paying the network fees for both transactions to ensure atomic execution. This generates an updated vault token reflecting the reduced collateral and new collateralisation ratio. The vault UTXO retains both the user update path and the guardian/oracle liquidation path, though with a smaller safety buffer due to the lower collateral level.
An OP_RETURN output records the updated vault state, including the decreased collateral and revised collateralisation ratio.
Upon request, the price oracle provides a price quote, which is a signed attestation of the BTC/USD exchange rate at a specified timestamp. If no timestamp is specified, the latest available price is used.
Each request must include a threshold price, which is the price level at which a threshold key may be revealed. The oracle uses this threshold price, along with other data, to compute a threshold key. This key is hashed using the HASH160 algorithm, and the resulting hash is returned alongside the price quote.
Price quotes are requested using the following URL format:
GET https://price-oracle-url/quote?th=<THRESHOLD_PRICE>&ts=<QUOTE_STAMP>
If a quote is requested with a specific timestamp, the oracle must check whether the BTC/USD price has crossed the threshold price between that timestamp and the current time.
If the threshold has been crossed, then the is_expired boolean must be set to true
Vault Record: Defines the configuration of a user’s vault. Vaults are linked to the Account Record used to create them.
Vault Token: A record held in the user’s wallet. It stores data that references (and helps locate) the corresponding vault record on-chain, along with any user-configurable settings for the vault.
Lack of complex arithmetic: Opcodes like OP_MUL and OP_DIV are not supported, as they were removed by Satoshi alongside other non-standard operations.
As a result, the logic required to track the relationship between locked BTC and issued UNIT must be enforced off-chain.
To overcome these limitations, Ducat uses a Multiparty Computation (MPC) system. It is operated by independent participants external to the protocol. Their responsibilities include:
Custodying a share of the FROST key: Each actor holds a portion of the key required to co-sign vault transactions.
Processing user requests: Ensuring that every transaction complies with protocol rules as defined in the Master Canonical Reference Set (CRS).
All BTC collateral is secured using a 2-of-2 multisig scheme:
Key 1: Held by the user
Key 2: Distributed across the FROST-based MPC network
Signer rotation: Participants can be replaced without affecting the validity of previously co-signed transactions
Resilience against malicious actors: Signing power is decentralised across multiple parties
Improved security: The threshold structure ensures that a high number of participants must collude for any compromise to occur
This system represents a significant improvement over traditional scripted multisigs, offering greater flexibility, security, and resilience.
If the threshold has not been crossed, then the is_expired boolean must be set to false, and the relevant fields (thold_key, expiry_price, expiry_stamp) must be set to null.
The price oracle must securely store an HMAC_SECRET key (used to generate threshold keys), and SIGN_SECRET key.
In a joint, concurrent two-transaction process, the user borrows additional UNIT stablecoins against their existing Bitcoin collateral. This increase in debt raises the Bitcoin price at which liquidation would be triggered.
The user initiates a transaction using their existing vault UTXO, requesting to borrow additional UNIT runes against their BTC collateral. The MPC network verifies the vault’s current collateralisation ratio and the requested borrow amount to ensure it maintains the required safety margin. The transaction builder then constructs a PSBT that updates the vault’s borrowed amount while keeping the BTC collateral locked. The outputs include the user receiving additional UNIT runes and an updated vault UTXO reflecting the new borrowed amount.
In a second transaction, the updated vault state is processed, paying the network fees for both transactions to ensure atomic execution. This generates an updated vault token that records the new borrowed amount and collateralisation ratio. As with the original vault, the UTXO maintains both the user update path and the guardian/oracle liquidation path.
An OP_RETURN output records the updated vault state, including the new borrowed amount and revised collateralisation ratio.
UNIT is designed to be a BTC-backed Collateralised Debt Position (CDP), programmed to be soft-pegged to the USD at 1.01 to 1.04 UNIT per USD before transaction costs, to finance responsible lending and leverage.
At its core, UNIT offers conservative on-chain leverage to borrowers, with a targeted collateralisation ratio of 135 to 160 percent at all times.
Initially, these UNIT-tokenised loans will carry zero percent interest, a one percent Issuance Fee, and a variable Liquidation Fee. DUCAT token holders will control these parameters, and introduce new ones, through the DUCAT governance process.
We chose a 135 to 160 percent collateralisation ratio for UNIT to balance BTC’s historical 10-minute volatility (roughly the time of a Bitcoin block) with capital efficiency.
Exogenous collateralisation is the only market-credible stablecoin risk structure. Every stablecoin and stablecoin-like derivative whose risk model has held up under stress is either exogenously overcollateralised (their collateral comes from a token with a much larger market cap that the stablecoin protocol has no or minimal influence over) or, in a few CDP cases, very heavily endogenously overcollateralised, with tight controls on debt origination.
Our stability mechanism relies on Liquidation Auctions to recapitalise distressed vaults.
This process will be executed in a decentralised manner, with liquidators incentivised by strong returns on invested capital.
Our priority is ensuring that all UNIT remains at least 135% collateralised by BTC at all times.
As long as UNIT is consistently collateralised well above 100%, even in periods of extreme market stress, market forces will maintain the peg.
Borrowers will be strongly motivated to repay their UNIT debts whenever UNIT trades at a discount to $1.
The user adds more Bitcoin to their existing vault as additional collateral, keeping their borrowed UNIT amount unchanged but improving their collateralisation ratio, which makes liquidation less likely. This is executed through a single transaction that updates the relevant vault record to reflect the increased Bitcoin collateral and its effect on the liquidation price.
The user initiates a transaction to add more BTC collateral to their existing vault UTXO. The MPC network verifies the incoming BTC amount and confirms the transaction. The transaction builder then constructs a PSBT that combines the new BTC with the existing vault collateral. The outputs include an updated vault UTXO with the increased collateral amount, while maintaining the same borrowed UNIT position.
In a second transaction, the updated vault state is processed, covering the network fees for both transactions to ensure atomic execution. This generates an updated vault token reflecting the new total collateral and improved collateralisation ratio. The vault UTXO continues to support both the user update path and the guardian/oracle liquidation path, with the increased collateral providing a greater safety buffer.
An OP_RETURN output records the new vault state, including the updated BTC collateral and revised collateralisation ratio.
The Ducat Protocol derives its security from the Bitcoin network but enforces its metaprotocol rules through a Multi-party Computation (MPC) network powered by the Flexible Round-Optimised Schnorr Threshold Scheme (FROST). This distributed node cluster functions as a scriptless multisig, producing a single aggregated signature which, combined with the user’s signature, secures Bitcoin collateral. This setup enables the issuance of UNIT debt while preserving Bitcoin’s decentralisation and security.
UNIT and Ducat operate as a meta-protocol, enforced by the MPC network and verifiable by anyone running a Ducat Node.
MPC Network: Functions similarly to Bitcoin miners by enforcing protocol rules.
Ducat Node: Acts like a Bitcoin node, enabling anyone to verify transactions and ensure protocol compliance.
Ducat aims to build a protocol that remains closely aligned with Bitcoin, using existing concepts to establish a stablecoin that is:
Liquidations are the key mechanism by which UNIT's supply is kept in balance with the amount of exogenous collateral (BTC), thereby preventing the accumulation of bad debt.
The Protocol’s liquidation process is fully decentralised, with no whitelisting, no preferred liquidators, and no off-chain intervention. Anyone can use their capital to repay undercollateralised UNIT positions in exchange for discounted BTC, all enforced natively on Bitcoin.
When a vault’s collateralisation ratio falls below the governance-specified Liquidation Threshold (currently set at 135%, but subject to change via governance), the vault is liquidated. This threshold is set significantly above 100% for three reasons:
To provide a buffer in the event of a sudden, sharp drop in BTC’s price.
To fund a Liquidation Tax, which finances the Protocol.
The validation layer, referred to as the Ducat Node, is a parser and indexer of UTXOs that tracks the movement of both DUCAT and UNIT tokens. Its role is to ensure that the tokens being interacted with are valid, compliant with ordinal theory, and generated according to the rules defined by the protocol, similar to how a Bitcoin node validates transactions.
DUCAT and UNIT do not require a validation layer to function, but they benefit significantly from one. The Ducat Node validates activity by parsing UTXO data in line with the reconstructed protocol rules, starting from an initial transaction ID. This validation process is independent of the Ordinal Protocol but fully compatible with it.
The Ducat Node scans the Bitcoin blockchain for transactions relevant to the Ducat Protocol. These fall into two main categories:
Ducat Protocol transactions: Identified by OP_8 in the OP_RETURN output
Rune Protocol transactions: Identified by OP_13 in the OP_RETURN output, filtered by rune_id for DUCAT and UNIT runes
Each vault within the DUCAT protocol includes a liquidation path as a spending script, which is locked using the hash from a price quote. The vault also records the quoted exchange price, threshold price, and timestamp in the vault return data field.
When a liquidator is interested in a vault, they use the return data to request a copy of the quote from the price oracle. The oracle checks whether the exchange price has crossed the threshold price, starting from the timestamp of the quote. If the threshold has been crossed, the oracle returns the secret key along with the price quote. Otherwise, the key remains secret and is returned as null.
Using the secret key, the liquidator can spend the underwater vault into their own vault, which must contain enough capital to re-collateralise the debt. This transaction is verified and co-signed by the guardian nodes before being broadcast to the network.
Vault Action
This document is provided solely for informational purposes. It does not constitute an offer to sell, or the solicitation of an offer to buy, any security or other financial instrument in any jurisdiction. Nothing contained herein should be interpreted as legal, tax, investment, accounting, regulatory, or other professional advice. Recipients are advised to consult their own advisors regarding any legal, financial, tax, or other matters relevant to their individual circumstances.
Certain statements in this document may constitute forward-looking statements. These statements are generally identifiable by terminology such as “may”, “will”, “should”, “expect”, “intend”, “plan”, “anticipate”, “believe”, “estimate”, “project”, “forecast”, or other similar expressions. All such statements reflect the current views of the authors with respect to future events and are subject to various risks, uncertainties, and assumptions. Actual results, performance, or achievements may differ materially from those expressed or implied by such forward-looking statements. No assurance is given that any of the plans, intentions, or expectations expressed or implied in this document will be realised.
Forward-looking statements are valid only as of the date they are made. Ducat expressly disclaims any obligation to update or revise any forward-looking statement, whether as a result of new information, future events, or otherwise, unless required by applicable law.
The Ducat Protocol and its associated systems, including the UNIT token and DUCAT governance token, remain under active development. Accordingly, the contents of this document, including all protocol specifications, features, and operational mechanics, are subject to change. Nothing in this document should be construed as representing the final design, functionality, or guarantees of the protocol.
UNIT is an experimental, overcollateralised algorithmic stablecoin soft-pegged to approximately one US dollar. Its stability depends on dynamic market forces, including UNIT supply, UNIT demand, and the overcollateralisation ratio of Bitcoin held in protocol vaults. There is no guarantee that UNIT will maintain its target peg under all or even most conditions.
Apart from emergency governance votes to freeze additional UNIT borrowing, governance decisions only affect newly created vaults. For instance, if the vault liquidation threshold is changed, that change only applies to new vaults or new incremental borrowing from existing vaults. All vaults remain subject to the terms of the Master Canonical Reference Sets (mCRS) under which they were instantiated, not the current mCRS.
The DUCAT token serves as the governance token for the following types of votes:
Modify vault borrow collateralisation threshold: Change the minimum collateralisation level required to mint additional UNIT from a vault (currently 160%).
Modify vault liquidation threshold: Change the collateralisation level at which a vault becomes eligible for liquidation (currently 135%).
The MPC network acts as a decentralised co-signer. It evaluates, reconstructs, and countersigns Partially Signed Bitcoin Transactions (PSBTs) submitted by users. The network ensures that all transactions comply with Ducat’s protocol rules, such as maintaining required collateralisation ratios and validating liquidation conditions.
Importantly, the MPC network does not custody user collateral. Instead, it functions as a verification and enforcement layer, ensuring that protocol operations remain consistent and secure.
Protocol data is auditable through Ducat vaults, with information embedded in transaction inputs and outputs. Each vault-related action includes an OP_RETURN output containing key data points:
UNIT balance
Oracle timestamp
Liquidation price
Threshold hash
Vault action
Protocol version
These data points allow derivation of essential vault metrics, including collateralisation ratios, issued debt, and ownership details. The Vault Token, held in the user’s wallet, references this on-chain data and supports seamless protocol upgrades, maintaining data integrity across protocol versions.
Liquidations are triggered when a vault’s collateralisation ratio drops below the governance-defined liquidation threshold. The OP_RETURN output contains a RIPEMD-160 hash, which, together with oracle data, determines the preimage needed to unlock the liquidation path.
Liquidation security relies on a multi-layered approach:
Oracle blindness: Oracles provide price data without tracking individual vaults, reducing the risk of targeted manipulation.
MPC oversight: The MPC network acts as a backstop, verifying oracle outputs and using internal price references to prevent malicious liquidations.
Decentralised indexing: Users can operate independent indexers to verify vault status and protocol adherence, enhancing transparency.
While the Ducat Protocol does not permit unilateral exits (users cannot bypass protocol rules to withdraw collateral), it maintains transparency through:
Decentralised governance: Protocol rules are governed by DUCAT token holders.
MPC network enforcement: Protocol compliance is maintained without centralised custodianship.
Independent indexers: Users can verify all on-chain activity, ensuring system-wide integrity.
The MPC network is not merely a technical component; it is the enforcement core of the protocol, ensuring transaction validity, collateral security, and strict adherence to governance-defined rules.
Secured by Bitcoin, backed by Bitcoin, and operating entirely within Bitcoin
This design involves several trade-offs, particularly in areas such as:
Asset management
Supply control
Liquidations
DUCAT relies on two core systems:
Oracles: Maintain the soft peg to the US dollar
MPC Network: Enforces protocol rules and validates transactions
These systems are supported by users running independent validators and reinforced by community consensus. Valid transactions are determined solely by data secured on the Bitcoin network.
Even in the event of a complete system compromise:
The network could restart independently with a new set of guardians
Invalid transactions could be ignored, restoring protocol integrity without external intervention
This structure ensures Ducat remains robust, transparent, and faithful to Bitcoin’s decentralised ethos.
To incentivise future buyers of the vault by offering them the residual positive Net Asset Value (NAV) as compensation for their cost of capital.
In a liquidation, the transaction originally signed by the user during their most recent interaction allows for the transfer of ownership of the vault’s assets to a Liquidator once two conditions are met: the vault undercollateralisation condition has been satisfied, and a Liquidator has submitted a valid transaction to repossess and recapitalise the defaulted vault.
A liquidation’s profitability is a function of four variables:
The vault’s collateralisation ratio at the time a Liquidator offers to recapitalise the vault
The liquidation tax rate
The liquidation tax rebate rate (a tax offset in which the Protocol shares profits with the Liquidator. This rate increases as the vault’s collateralisation level decreases)
The ease with which a Liquidator can buy UNIT at the lowest possible premium to $1, if they wish to exit the liquidated position
Our liquidation engine includes a rich profit-sharing mechanism for BTC Liquidators to incentivise participation in this novel process. On the flipside, Liquidators must also take on uncertain duration risk, as they are required to acquire UNIT elsewhere to fully close their positions. They will likely have to repurchase UNIT at a slight premium to $1, similar to how MakerDAO’s DAI stablecoin often trades above $1 when multiple vaults are being liquidated.
Transactions are parsed and validated according to Ducat Protocol rules and added to one of the following sub-indexes:
DUCAT Account UTXOs: Used for issuing DUCAT runes
DUCAT Spending UTXOs: The primary governance token
UNIT Account UTXOs: Used for issuing UNIT runes
UNIT Spending UTXOs: The primary stablecoin token
Vault transactions: Lock BTC in exchange for UNIT
Contract transactions: Define the variable terms of the protocol
Record transactions: Store data that is referenced by contracts
Proposal transactions: Propose changes to the contract
Voting transactions: Use DUCAT to vote on open proposals
Ordinal theory does not provide comprehensive validation beyond basic sat indexing. The Ducat Node fills this gap by maintaining a detailed, protocol-specific ledger that ensures:
Protocol compliance: Verifies that transactions follow all protocol rules
On-chain transparency: Allows anyone to audit the system independently
Decentralisation: Users can run their own Ducat Nodes to verify activity and reduce reliance on central infrastructure
The Ducat Node strengthens the integrity of the protocol by adding a layer of validation and transparency. It ensures that all protocol-related activity conforms to the Master Canonical Reference Sat (mCRS).
Vault User wants to perform an action on their vault. The user calculates the threshold price for their updated vault, then requests a price quote from an oracle.
Oracle receives a request for the latest BTC/USD exchange price and returns a signed price quote, including the requested threshold price and key hash.
Vault User constructs a vault update transaction using the data from the price quote. They also prepare a request to update the vault and send this information to a guardian, along with the price quote.
Guardian verifies the update terms, price quote, and transaction. If everything checks out, the guardian co-signs the transaction and broadcasts it to the network.
Vault Liquidation
Liquidator wants to liquidate a vault that has fallen below the threshold price. The liquidator uses the data in the vault to request the corresponding historical quote from the oracle.
Oracle receives the request and checks whether the exchange price has surpassed the threshold price. If it has, the oracle returns the secret key along with the original quote.
Liquidator constructs a vault liquidation transaction using the secret key and sends this to a guardian along with the price quote.
Guardian verifies the liquidation terms, price quote, and transaction. If valid, the guardian co-signs and broadcasts the transaction to the network.
If the Ducat Protocol fails to maintain equilibrium between UNIT supply and demand, or if the system suffers from unforeseen vulnerabilities, the value of UNIT may experience significant volatility or de-pegging. Additionally, DUCAT governance tokens may become worthless in part or in full.
The DUCAT token is not intended to be offered, sold, or distributed to any U.S. persons, or in any jurisdiction where such offer, sale, or distribution would be unlawful. The Protocol reserves the right to restrict participation in accordance with applicable laws and regulations.
Participation in the Ducat Protocol is entirely at your own risk. By engaging with the Protocol or any of its components, you acknowledge that you understand and accept the experimental nature of the system, and that you may incur substantial or total loss of value.
Modify borrow fee: Change the up-front borrow fee (currently 1%).
Modify liquidation tax: Change the tax rate applied to liquidated vault assets (currently 15%).
Allocate governance emissions: Authorise transfers of DUCAT from the Foundation wallet to specific wallets for governance-agreed priorities, such as an airdrop to users who met specific criteria.
Designate BTC price oracles: Define the primary source of truth for Bitcoin’s market price.
Designate backup oracles: Appoint fallback oracles in the event that the primary oracle’s data is no longer trusted.
Add or remove guardian(s): Adjust the set of validators in the guardian network.
Freeze borrowing: Immediately halt new UNIT issuance, for example, if a borrow-related exploit is discovered and needs urgent patching.
This last type of governance action must be executed rapidly upon reaching a 51% quorum, in contrast to the usual multi-day voting period.
The price oracle is a web server (or group of servers) that responds to requests for a price quote, which is a signed attestation of the Bitcoin to USD exchange rate at a specific point in time. Each quote includes a UTC timestamp and the corresponding exchange rate. Users can request a quote for the latest price or for a historical price by providing a specific timestamp.
Each request also includes a threshold price, which is supplied by the user. This threshold is used by the oracle to generate a unique secret key. The key is then hashed and returned to the user along with the price quote.
This protocol allows the price oracle to trigger stop-loss events within the DUCAT protocol without requiring any awareness of the protocol or its users. The event is triggered using a cryptographic hash embedded in Bitcoin Script, with the secret preimage revealed only when the threshold condition is met.
A vault in the Ducat Protocol is like a secure digital safe where users lock their Bitcoin (BTC) as collateral to mint UNIT, a Bitcoin-native stablecoin. It serves as the backbone of the system, where BTC is held to create new value while keeping the system overcollateralised and secure.
Here is how it works: when a user wants to mint UNIT, they deposit BTC into a vault. This is not just a simple deposit, it is a smart, rules-based agreement. The protocol checks whether the user has enough BTC, verifies the current BTC/USD price through oracles, and ensures all conditions are met, such as maintaining the minimum 160 percent collateralisation ratio. For example, if you lock $10,000 in BTC, you can mint up to 6,250 UNIT.
The vault has two critical functions:
User control: The user can update the vault by adding more BTC, borrowing more UNIT, repaying debt, or withdrawing BTC, as long as the vault remains safe.
Liquidation mechanism: If the value of BTC drops and the collateralisation ratio falls below the 135 percent liquidation threshold, the vault can be liquidated to protect the system. This ensures that UNIT is always backed by real BTC, even in volatile markets.
Importantly, the user always retains partial control. While the guardians (via the MPC network) ensure that the protocol’s rules are enforced, they never control your BTC.
Vaults are central to UNIT’s stability. They secure collateral, manage risk, and maintain a system that is both trustless and efficient.
Users request to open vaults by depositing BTC as collateral in exchange for UNIT tokens. The MPC network checks whether they have sufficient BTC, verifies the BTC/USD price, and calculates network fees.
The process occurs in two linked transactions:
First transaction: The user receives their UNIT tokens while their BTC is held as collateral.
Second transaction: The BTC is moved into a vault, creating a record of the vault’s creation.
The vault holding the BTC can be accessed in two ways:
When the user updates their vault via any of the authorised guardians.
When the vault is liquidated by the guardians due to the collateral value falling to the liquidation threshold.
All changes to the vault are recorded to track the user’s borrowing activity and collateral level.
The system references the minimum collateralisation Canonical Reference Satoshi to determine how much UNIT an individual vault can mint:
Maximum UNIT = (BTC collateral × BTC/USD price) ÷ Minimum Collateralisation Ratio
Where the Minimum Collateralisation Ratio (MCR) is 160 percent. The MCR is a key risk parameter defined in the Governance CRS and is subject to change through governance.
In other words, a vault with $10,000 of BTC could borrow a maximum of 6,250 UNIT.
Liquidations operate under different trust assumptions from other vault actions. Instead of requiring a 2-of-2 multisig, they rely on:
A single signature
The pre-image of a hash
Hash Generation
A hash is generated by sending a request to the price oracle. The oracle returns:
A quote for the current BTC/USD price
A liquidation price, based on risk parameters from the Master CRS
Only the oracle system has access to the threshold hash logic.
Neither the MPC Network nor the user ever sees the hash or its pre-image.
The oracle does not store any hashes or pre-images. It derives the pre-image only when:
A liquidator requests it, and
Oracle Blindness
The oracle cannot identify which specific vault it is serving.
It keeps no history of generated hashes or pre-images.
Separation of Roles
This layered approach ensures that liquidations remain secure, privacy-preserving, and resilient, even in the event of oracle failure or compromise.
User Agreement
Each time a user updates their vault, they agree to a new liquidation threshold. This threshold is enforced by the hash generated by the oracle. The user’s agreement is embedded in a transaction output that:
Requires the MPC Network’s signature to unlock
Requires the pre-image of the hash included in the OP_RETURN of the transaction
The market price has crossed the vault’s agreed liquidation threshold
The oracle is entirely separate from the MPC Network.
This separation acts as a fail-safe to prevent collusion or shared compromise.
MPC Network Backstop
If the oracle becomes compromised, the MPC Network can fall back on its own internal price references.
This allows it to reject any transactions that would otherwise threaten protocol integrity.
The price oracle must securely store an HMAC_SECRET key (used to generate threshold keys), and SIGN_SECRET key (used to sign responses):
// Used to generate a unique secret key for each price quote:
HMAC_SECRET = 32 (or more) randomly generated bytes.
// Used to provide a signature with each price quote:
SIGN_SECRET = 32 randomly generated bytes (on the secp256k1 curve).
// Compressed public key of the signing secret key.
ORACLE_PK = get_ecdsa_compressed_pubkey(SIGN_SECRET)// Some codeWhen the oracle receives a request, the thold_key and thold_hash can be generated using the following formula:
DOMAIN_LABEL = utf8_to_bytes("bitcoin/usd_price_quote")
QUOTE_PRICE = uint32_to_bytes(quote_price, size=4)
QUOTE_STAMP = uint32_to_bytes(quote_stamp, size=4)
THOLD_PRICE = uint32_to_bytes(thold_price, size=4)
THOLD_KEY = hmac256(HMAC_SECRET, DOMAIN_LABEL, ORACLE_PK, QUOTE_PRICE, QUOTE_STAMP, THOLD_PRICE)
THOLD_HASH = ripemd160(sha256(THOLD_KEY))When providing a response, the contents of the price quote must be hashed and signed using the following formula:
PREIMAGE = json_to_utf8_bytes({
expiry_price : number | null // Price of the first exchange record to cross threshold.
expiry_stamp : number | null // Timestamp of the first exchange record to cross threshold.
is_expired : boolean // If the threshold has been crossed.
oracle_pk : string // Public key belonging to the Price Oracle.
quote_price : number // The exchange price of the quote.
quote_stamp : number // The exchange timestamp of the quote.
req_stamp : number // Timestamp of the latest exchange record.
thold_hash : string // HASH160 hash of the threshold key.
thold_key : string | null // HMAC256 key controlling the stop-loss event.
thold_price : number // Threshold price that was provided with the request.
})
REQUEST_ID = sha256(PREIMAGE)
REQUEST_SIG = ecdsa_sign(SIGN_SECRET, PREIMAGE)
Imagine you’re following a real-world scenario where Alice uses her BTC as collateral and things don’t go as planned. Here’s what happens step by step:
1. Vault Setup
Alice deposits $800 of BTC into a vault.
She borrows 500 UNIT (the maximum allowed) and spends it outside of Ducat.
2. Market Drop
BTC’s value falls by 15.7% in one minute.
The vault’s BTC is now worth $674.40, which is too low to safely back 500 UNIT under the 135% collateralisation requirement.
3. Liquidation Tax
The protocol applies a 15% liquidation tax (about $101.16 of BTC) to the vault, which is escrowed.
After the tax, the vault holds $573.24 of BTC, still backing the 500 UNIT debt.
4. Liquidator Action
Bob, a Liquidator, steps in by adding $226.76 of BTC to bring the vault back to the required 160% collateralisation level.
In effect, Bob takes on Alice’s $500 debt and gains control of a vault holding $573.24 in BTC. This gives him a net asset value of $73.24.
5. Liquidation Rebate
In this example, Bob recapitalises the vault at a collateralisation level of 134.88%. Since the liquidation rebate does not begin until the vault falls below 124%, Bob does not receive any rebate from the protocol.
6. Bob’s Return
To withdraw the BTC from the vault, Bob must first repay the 500 UNIT debt by purchasing UNIT on the open market.
Assuming a UNIT/USD exchange rate of 1.00, the cost to acquire 500 UNIT is $500.
Bob’s profit from recovering the BTC (after taxes and rebate) is $73.24, as calculated in Step 4.
His total cost is $500 to acquire UNIT, plus $226.76 to recapitalise the vault, totalling $726.76.
7. Protocol’s Role
The protocol retains the liquidation tax revenue, after paying out any rebate.
In more distressed vaults, the protocol may share a larger portion or all of the liquidation tax with the Liquidator to offset higher risk.
This breakdown shows how a sudden market drop can trigger liquidations and create opportunities for Liquidators like Bob, while the protocol uses liquidation taxes and rebates to manage the risk of bad debt accumulation.
Ducat governance is controlled by holders of DUCAT tokens. The economic security of the Ducat network relies on a set of parameters that users manage through governance proposals. These parameters include:
Liquidation threshold [135%]: The collateralisation threshold at which a borrower’s BTC vault is liquidated.
Minimum Reserve Threshold Allocation [5,000 sats]: The minimum quantum of sats for a transaction.
Repossession tax rate [15%]: The tax rate levied on liquidated vaults.
Once a liquidation is completed, and before the vault can be collapsed and the BTC withdrawn by the Liquidator, the Liquidator must return the currently ‘estranged’ UNIT debt, which was incurred by the previous vault owner, to the vault. In other words, the Liquidator has acquired both the assets and the obligations of the vault.
To encourage the return of this estranged UNIT and allow the vault to be closed and the BTC withdrawn, Liquidators will be able to purchase UNIT on Bitcoin DEXs and Layer 2 networks. The Protocol will ensure that UNIT/BTC liquidity is available as needed.
Before a Liquidator can recover the BTC from a liquidated vault, they must first deposit enough BTC to recapitalise the vault to the minimum overcollateralisation ratio required at minting (currently 160%, subject to governance). Once this is done, the vault is transferred to the Liquidator, who now owns both the BTC and the outstanding UNIT debt. To fully close the vault and unlock the BTC, the Liquidator must then repay the UNIT debt by purchasing and returning an equivalent amount of UNIT to the vault. Only after this repayment is completed can the Liquidator collapse the vault and redeem the underlying BTC.
This ensures that all circulating UNIT remains fully backed by BTC at all times, and that bad debt does not accumulate in the system. Our liquidation engine includes a robust profit-sharing mechanism for BTC Liquidators, designed to incentivise participation through a novel trading model. On the flipside, Liquidators must also take on uncertain duration risk, as they are required to purchase UNIT elsewhere in order to fully close their positions.
Optimising the Liquidator experience to minimise this duration risk, while offering favourable risk–return dynamics and ensuring that bad debt is consistently cleared, will be an iterative process.
Bob earns a profit of $73.24 on a total investment of $726.76, giving him a return of approximately 10.1%.
Subsidy rate [0.6%]: The rate at which the liquidation subsidy grows per 1% below the collateralisation level in a liquidated vault.
Subsidy threshold [124%]: The vault collateralisation ratio at which the protocol begins to subsidise the liquidation process.
Vault minimum balance [10,000 sats]: The minimum amount of sats required to instantiate a vault.
Minimum borrow collateralisation threshold [160%]: The minimum collateral ratio required to mint UNIT from a vault.
Reserve accrual rate [50%]: The percentage of protocol profits that accrue to the Reserve, rather than to DUCAT tokenholders.
Treasury target size [10 BTC]: The target size of the BTC reserve used to insure against failed liquidations, periodically clear stranded vaults, and create protocol-owned UNIT liquidity.
All earnings above the level required to top up the Reserve will be governed at the discretion of DUCAT tokenholders.
These governance parameters are essential for protocol operation. Initial values are defined by the Ducat Foundation but can be modified at any time through a governance vote.
Because carrying out governance directly on Bitcoin is logistically difficult due to BTC’s reliance on basic m-of-n multisigs, Ducat instead uses a combination of the validation layer and Rune token counting on a given token proposal to determine the canonical contract location, as voted by DUCAT tokenholders.
In this example, the Protocol strongly encourages Liquidators to immediately recapitalise liquidated vaults. The “kink” in the curve marks the point where the Protocol begins sharing the vault’s liquidation tax revenue with the Liquidator to subsidise third-party liquidation. Although the Liquidator’s return remains positive across the curve (assuming the UNIT/USD exchange rate is 1.00), the Liquidator receives the highest reward when liquidating a vault at 134.99%.
The Liquidator’s profit function is:
[Vault_BTC × Vault_net_BTC_recovery_factor] − [Vault_Debt × UNIT_USD_rate]
The Liquidator’s return is this profit divided by the total cost to the Liquidator, expressed as:
([Vault_BTC × Vault_net_BTC_recovery_factor] − [Vault_Debt × UNIT_USD_rate]) ÷ ([Vault_Debt × UNIT_mint_min_collat_ratio × UNIT_USD_rate] − [Vault_BTC × Vault_net_BTC_recovery_factor])
Where:
Vault_BTC = The amount of underlying BTC collateral in the liquidated vault before recapitalisation by the Liquidator.
Vault_net_BTC_recovery_factor = The proportion of Vault_BTC recoverable by the Liquidator after the liquidation tax is deducted and any rebate is applied:
Vault_net_BTC_recovery_factor = 1 − Liquidation_tax + Liquidation_rebate
Liquidation_tax: 15%
Liquidation_rebate: A sliding function that activates when a vault’s collateralisation ratio falls below 135%, and increases progressively. The rebate reaches 100% of the liquidation tax when the collateralisation ratio falls to 102%.
Vault_Debt: The amount of UNIT outstanding in the vault. This must be repaid (by purchasing UNIT on the open market) before the Liquidator can collapse the vault and withdraw the BTC.
UNIT_USD_rate: The market price of UNIT in USD. A rate of 1.02 means the Liquidator must pay $1.02 to buy 1 UNIT.
UNIT_mint_min_collat_ratio: The minimum collateral ratio required to mint UNIT, currently 160%.
