I’ve been working on KUSD, an experimental decentralized USD stablecoin built on Kaspa using SilverScript/Toccata Covenants.
KUSD is overcollateralized with native KAS and does not depend on a centralized price oracle. The economic architecture is inspired by Frankencoin, an existing EVM-based protocol, but the implementation has been redesigned around Kaspa’s UTXO model.
The project is currently deployed and functional on Testnet 10. It is unaudited and not ready to secure assets of real value.
Why build this?
The goal is to explore whether Kaspa can support a decentralized stablecoin that:
- increases the utility of KAS as productive collateral;
- avoids dependence on institutionally issued stablecoins;
- does not rely on a privileged oracle operator;
- keeps critical financial invariants directly inside UTXO Covenants;
- can eventually be governed by its users and reserve providers.
Without a price oracle, the peg would primarily rely on market incentives and arbitrage through Kaspa DEXs. Minting conditions are defined by independent modules whose parameters are publicly visible and evaluated before activation.
How it works
The protocol follows this general hierarchy:
RootIssuance
└── Governance
└── MintingModule
└── Position
└── Challenge
└── Auction / Reserve backstop
There is one KUSD Asset ID shared by all approved MintingModules. Creating a new module therefore does not create a different stablecoin.
MintingModules
A MintingModule defines immutable economic conditions such as:
- liquidation price;
- minimum collateral;
- total minting limit;
- maximum debt per Position;
- risk premium;
- retained reserve contribution;
- initialization and expiration DAAs;
- challenge and Auction durations;
- challenger reward.
Multiple modules can coexist with different prices, limits, durations and risk parameters while issuing the same KUSD asset.
A proposal must pass its initialization period without sufficient KPS veto power before its module can be activated.
Opening a Position
A user locks KAS in an independent Position UTXO. The Position records its owner, debt, collateral conditions, maturity and associated Module.
The protocol checks that the debt remains within the Module’s collateralization constraint. The risk premium depends on the remaining lifetime of the Position. Part of the issued KUSD is assigned to the Position or transferred to the Reserve according to the configured parameters.
Every Position is independent. There is no global UTXO containing every borrower’s state.
Repayment and closing
The owner can repay the complete debt and close the Position before expiration.
The close transaction must atomically:
consume the Position
+ burn the required KUSD
+ return the locked KAS to its owner
A Position cannot release its collateral merely by creating an output with the same Covenant ID. Its state, value, owner, Asset ID, successor scripts and related contracts are explicitly verified.
Challenges and Auctions
A Position can enter a challenge process. After the warning period, activation is permissionless and creates an Auction.
The Auction uses a decreasing price over a distinct DAA duration. A bidder can settle it by providing enough KUSD to burn the complete debt and receive the collateral.
If no bidder appears after the minimum Auction period, the Equity Reserve can act as a backstop. The current design refuses settlements that would leave uncovered debt.
Equity Reserve and KPS
Users can deposit KUSD into the Equity Reserve and receive KPS shares.
The Reserve:
- absorbs defined protocol fees;
- receives retained reserve contributions;
- pays Savings interest;
- can cover an Auction when no external bidder settles it;
- gives KPS holders veto power over governed actions.
KPS is inspired by Frankencoin’s FPS, although its current economics and governance mechanics are not yet exact equivalents.
Savings
KUSD also includes an optional Savings mechanism. It is disabled at genesis and can be activated through governance.
Interest is not minted continuously or credited to an account every block. When a Savings account is refreshed or withdrawn, accrued interest is calculated using DAA time and transferred from the Equity Reserve. This prevents Savings from creating unbacked KUSD.
What has been tested?
The current TN10 deployment has exercised the complete principal paths:
- protocol genesis and unique KUSD Asset ID;
- creation and activation of a governed MintingModule;
- opening, repaying and closing a Position;
- Savings activation, deposit, interest refresh and withdrawal;
- challenge, Auction and Reserve backstop;
- Auction settlement using distinct owner, challenger and bidder wallets;
- transaction mass, storage mass and fee calculation;
- RPC-connected indexing of supply, debt and protocol UTXOs;
- fraudulent successor outputs, insufficient repayment, incorrect beneficiaries, incorrect KAS values and invalid cross-contract transitions.
The local consensus suite also covers numerical limits, fixed-point rounding, overflow-sensitive calculations and invalid transaction constructions.
Open design questions
The prototype works, but several areas need external review and discussion before any mainnet consideration.
Oracle-free price discovery
Each Module currently uses a fixed liquidation price instead of a live oracle.
Could a competitive ecosystem of time-limited Modules and DEX arbitrage maintain adequate market discipline? What incentives are required to prevent unsafe prices from being proposed or accepted? Would a decentralized oracle ultimately provide better guarantees?
Position adjustments
The current model creates independent Positions and does not provide Frankencoin-style adjustment or additional minting from an existing Position.
Should Positions support additional borrowing and collateral changes, or is it safer to create a new Position for each loan?
Purchasing expired Positions
Frankencoin provides mechanisms for buying Positions after expiration. The current KUSD lifecycle instead moves through its challenge and Auction model.
A closer equivalent may be desirable before mainnet, but it must be designed carefully for a UTXO environment.
Partial challenges
Challenges currently cover an entire Position. Frankencoin supports partial challenges.
A possible UTXO-native design would allow one active challenged fraction per Position and explicitly split debt, collateral and assigned Reserve balances into verified successor outputs. Supporting several concurrent fragments could considerably increase complexity and the risk of duplicated state.
Would one partial challenge at a time provide enough flexibility?
Parallel governance
Governance execution is currently serialized through a shared state UTXO. This makes ordering and supply accounting easier to verify but limits concurrent proposals.
A future design could place each proposal in an independent UTXO while keeping final execution serialized through RootIssuance. Is the additional complexity justified, or is serialized execution acceptable ?
Auction liveness and Reserve risk
The Reserve backstop resolves the case where an Auction receives no bidder, but it transfers collateral and market risk to KPS holders.
The economic parameters must ensure that the Reserve remains solvent during extreme market movements. The correct reward, Auction curve, retained reserve and backstop timing still require simulations and discussion.
Governance thresholds
The TN10 thresholds and delays are intentionally convenient for testing and are not mainnet recommendations.
The Savings veto threshold, proposal fee, initialization delay, voting weights and parameter ranges all need independent economic analysis. Governance capture and veto inactivity must also be considered.
DAA timing and races
Permissionless expiration avoids reliance on a privileged time attester, but state changes only when someone broadcasts the relevant transaction.
This creates possible mint/expire and avert/activate races around DAA boundaries. Consensus validation rejects conflicting histories, but the economic and UX consequences of latency and reorganizations require further testing.
Indexing and wallet integration
The protocol is UTXO-native and involves several related Covenant states. A reliable indexer is therefore essential for discovering Modules, Positions, Challenges, Auctions, Reserve balances, governance proposals, supply and debt.
The current indexer works for the tested lifecycle, but recovery, reorganization handling and independent indexer implementations should be reviewed.
Feedback wanted
I would particularly appreciate feedback from developers experienced with:
- Kaspa consensus, Toccata or SilverScript;
- Covenant security and cross-contract UTXO transitions;
- stablecoin economics;
- Dutch Auctions and liquidation systems;
- protocol reserves and recapitalization;
- governance design;
- indexers and reorganization handling;
- adversarial testing and formal verification.
The intention is not to claim that KUSD is ready for mainnet. The purpose of publishing it now is to make the design transparent, identify incorrect assumptions and discuss which differences from Frankencoin are sensible consequences of Kaspa’s architecture and which should be redesigned.
All criticism, security observations and alternative designs are welcome.