kUSD — Covenant-Native Stablecoin Framework for Kaspa L1

A design and reference implementation (in progress) for a stablecoin that lives natively in Kaspa L1 covenants, enabled by the Toccata hard fork (mainnet-active 2026-06-30).

Status: design draft + unvalidated assumptions. Nothing here is deployed, audited, or safe. Silverscript itself is experimental and TN10-only. Do not use any of this with real value.

kUSD is a placeholder ticker, not a brand or a token announcement. There is no token sale. There is no launch date. This is protocol research.

The design in five lines

1. kUSD notes are L1 covenant tokens — KIP-20 lineage makes every note consensus-verified, no indexer trust (unlike inscription tokens). Transfers are per-UTXO and fully parallel.
2. Two peg legs with disjoint trust stacks. A PSM leg: 1:1 kUSD ↔ bridged-stable conversion via an L1 covenant — no oracle, tight peg, arbitrage loop measured in seconds at 10 BPS. A CDP leg: KAS-overcollateralized vaults with oracle-gated risk changes and DAA-score Dutch-auction liquidations — trust-minimized backing that survives total bridge failure.
3. The PSM has a governance ceiling that caps bridge-stack exposure. Redemption is never ceiling-blocked: governance can stop the PSM growing, never unwinding.
4. Bridged stables (bUSD) reach L1 via a settlement covenant verifying prover attestations of an L2 bridge contract's state (the Toccata based-ZK pattern), anchored to stables already live on Kaspa's EVM L2s.
5. Supply accounting is sharded covenant heads, so the global solvency invariant — every kUSD backed by vault debt or PSM reserves — is auditable by walking L1 covenant lineages. No RPC trust, no indexer, no L2 query.

Full design: SPEC.md (v0.2). The risk model comparing the two legs is §7b; the failure-quarantine argument for why the peg module belongs on L1 rather than the L1 token being a receipt of an L2 system is the core thesis.

Repository layout

SPEC.md              Protocol specification v0.2 (the authoritative document)
contracts/           Silverscript contracts (compiler-adjacent pseudocode — see warning below)
prover/              L1↔L2 settlement prover (stub, milestone M1)
keeper/              Liquidation + peg-arbitrage bots (stub, milestone M3)
sdk/                 Wallet/integration helpers (stub)
OPEN_QUESTIONS.md    Assumptions that must be validated against the Silverscript compiler
CONTRIBUTING.md      How to help, mapped to milestones

Contracts warning: the .silver files follow the published Silverscript declaration semantics (covenant macros, transition/verification modes, Auth/Cov binding) but have not been compiled — the language is pre-1.0 with breaking changes expected. They are precise design documents, not deployable code. Milestone M0 is exactly the work of making them real.

Milestones

#	Deliverable	Validates
M0	TN10 spike: token covenant + minimal vault + covenant-owned-custody idiom	Open questions 1–3, 8
M1	Settlement covenant + bUSD + prover PoC against one L2 testnet	Questions 9–10
M2	PSM end-to-end on testnet: the tight peg, live	The thesis
M3	CDP leg: vaults, liquidation auctions, keeper bot, crash chaos-tests	The band floor
M4	Sharded supply, governance covenant, ceiling policy	Ops
M5	Audit + mainnet-readiness review	Everything

Why this exists

Kaspa's ecosystem generated nine figures of trading volume the day KRC-20 launched while holding under $1M in DeFi TVL — the demand exists and the stable unit of account doesn't. Every serious payment use case (merchant rails, agent-to-agent payments, remittance) needs a dollar that moves at L1 speed with L1 verifiability. Post-Toccata, that's buildable without asking anyone's permission.

The design deliberately steals from what worked elsewhere: MakerDAO's PSM endgame (tight peg from 1:1 convertibility, capped), Liquity's redemption-bounded band (volatile collateral gives you a corridor, not a peg — the spec doesn't pretend otherwise), and pulls both down into UTXO-parallel covenants where liquidations don't fight a gas auction and solvency is a lineage walk.

Contributing

Read OPEN_QUESTIONS.md first — the highest-value contribution right now is invalidating an assumption early. After that, CONTRIBUTING.md maps skills to milestones. Design criticism is a first-class contribution: v0.2's PSM leg exists because someone correctly rebutted v0.1.

References

• Kaspa programmability docs: https://docs.kaspa.org/
• Silverscript (covenant language): kaspanet GitHub — silverscript (see DECL.md, TUTORIAL.md)
• KIP-17 (covenant spending constraints), KIP-20 (covenant IDs)
• Prior art: MakerDAO PSM, Liquity v1, DAI pre-PSM peg history

License

MIT — see LICENSE.