Budget that can't be drained at once
A treasury output requires each next spend to leave a minimum balance or stay under a cap, so no single transaction empties it.
App layer
A Kaspa covenant restricts how a coin can be spent next, beyond who is allowed to spend it. A vault with a recovery path, a budget that can't be drained in one transaction, an asset that needs its issuer's signature to move: all the same primitive with a different rule.
Status: Toccata activated covenant rules on mainnet. Wallet signing, tooling, and app receipts are the layer still being built on top.
A normal signature answers one question: is this spender authorized? A covenant answers a second one: does the next output preserve the rule? Consensus inspects the spending transaction itself and can require the following output to route funds a certain way, cap the value that moves, or carry state forward into the next UTXO.
That turns a piece of app logic into a rule the chain enforces directly, one you can check without trusting an operator. It does not remove wallet UX work, audits, liquidity, legal exposure, or oracle design. Those stay separate problems.
A covenant constrains how one UTXO moves next. On its own, that's not enough to stop someone from forging a lookalike UTXO with similar-looking rules but no real history. A covenant ID closes that gap: consensus tags a UTXO as belonging to a specific covenant family, so a fake with copied logic still fails the lineage check.
| Piece | Plain job | Consequence |
|---|---|---|
| Normal script | Checks who is allowed to spend. | Handles ownership and ordinary payments. |
| Covenant | Checks whether the next output preserves a rule. | Builds vaults, escrow paths, controlled assets, and state transitions. |
| Covenant ID | Tags a UTXO's covenant family across valid continuations. | Stops lookalike forgeries and makes membership indexable. |
For the broader upgrade frame, read Toccata Explained. Primary reference: KIP-20 covenant IDs.
A treasury output requires each next spend to leave a minimum balance or stay under a cap, so no single transaction empties it.
A vault splits normal withdrawal and emergency recovery into separate paths, each with its own conditions.
A ticket or pass requires an issuer or controller signature on the input before it can transfer or redeem.
A funding rule releases only after a value threshold is met, and refunds automatically if the threshold is missed.